View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002305 | HTML & PERL | Feature Request - Interface | public | 2015-07-18 20:15 | 2016-02-23 13:32 |
| Reporter | Hinoe | Assigned To | DerIdiot | ||
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Summary | 0002305: Tag list and tag admin area filter improvements | ||||
| Description | Regarding the tag list's following filters: show abstract show parentless show unused show unverified And the tag admin area's following filters: show parentless show unused show unverified I'd like these filters to instead be in the "show-only / hide / ignore" format, as e.g. the description in both cases. Additionally, please add the abstract filter to the tag admin area the same way. Above is the main request. Below is some side stuff that would be nice but not quite as important. For the system choice in the tag list, tag admin area, and tag-entity admin area (as in, tag admin area with mode=tagentities), I'd like the systems to be all set to checkboxes (to allow for any combination) instead of the current "one or all" format; no checkboxes set should mean the same as all checkboxes set. Tree paths on the parent column and per-system actions could then show every selected system one in order from top to bottom inside the same row, similarly to how the shows a character is a cast member of are shown in the creator pages for seiyuu. Specifically for the errors in the tag-entity admin area, I'd like the current filter to be changed to the following format: a "show-only / hide / ignore" format for errors, and a checkbox for each error type (with all and none meaning the same thing). The current "ignore" option would map to "ignore", while each current error type would map to "show-only" with one checkbox marked. The "parent blocked" error in the tag (not entity) admin area could be handled the same way, but with each system as a checkbox; that would require implementing the previous paragraph first. | ||||
| Tags | No tags attached. | ||||
|
|
i don't see the point. parentless and unused are more or less error states and are at most a handful each. and what's the point in showing only abstract or verified? |
|
|
I don't remember the specifics very well, but I'll try to explain the basic idea from what I do recall. The "main point" of the request, the filter changes, were the exact tools I needed to simplify some of the maintenance work, of the mass change sort, that the tag admin interface allows for; these changes would mean that the same results can be achieved faster, with less work, and with a much lower risk of mistakes. One such case is where there are a bunch of upwards of 50 unverified tags that should be verified among a similarly-sized bunch of verified tags; having to select them manually is a royal pain the ass and odds are you're going to make a mistake doing it even if you check it all five times, and the idea of being able to do it by pressing just a few buttons is pretty sweet. Since the changes would be done for the tag admin area, it would also make sense to carry them over to the regular display; also, I recall times in which I wanted those filters in the regular display as well, though I don't quite recall the details of that. This item is the one that I really care about and would "fight" to see implemented; it saves me tons of time and effort and decreases the odds of mistakes enormously. For the second point, setting systems as checkboxes, I think this isn't all, but at least part of it has to do with the fact that certain tags need to be consistent between two systems, in particular chartb and creatortb, and other tags are currently consistent between the two but should not be; high-level maintenance for that shit is incredibly annoying and that would definitely lessen the pain of fixing it. It's a somewhat relevant item, and I care more about it than about the last one, but it's far from being as relevant as the first point; its relevance lies mostly in how it decreases the odds of making weird mistakes. For the final point, about the errors, I believe it's mostly to simplify the fixing process. This item isn't terribly important; I won't mind it in the slightest if you choose to ignore it. I guess that's more or less it. Sorry about the gaps in my facts; it's been a few months since I've done heavy work in the sort of maintenance these items apply to, so my memory of it all is kind of spotty. There's a fair lot of this work still pending, too... |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-07-18 20:15 | Hinoe | New Issue | |
| 2016-02-14 03:54 | DerIdiot | Note Added: 0003660 | |
| 2016-02-14 03:54 | DerIdiot | Assigned To | => DerIdiot |
| 2016-02-14 03:54 | DerIdiot | Status | new => feedback |
| 2016-02-15 03:16 | Hinoe | Note Added: 0003666 | |
| 2016-02-15 03:16 | Hinoe | Status | feedback => assigned |
| 2016-02-22 22:45 | DerIdiot | Status | assigned => resolved |
| 2016-02-22 22:45 | DerIdiot | Resolution | open => fixed |
