Ticket #8441 (closed enhancement: duplicate)
Opened 3 years ago
Last modified 3 years ago
Component Structure
| Reported by: | coreycothrum@… | Owned by: | |
|---|---|---|---|
| Priority: | low | Milestone: | |
| Component: | ticket system | Version: | 0.11.4 |
| Severity: | normal | Keywords: | |
| Cc: | |||
| Release Notes: | |||
| API Changes: | |||
Description
This ticket suggest a method of improved organization when sorting tickets by component.
The current way the component system is set up, it only lends itself to broad categories. I'd like to see more structure, allowing components to become 'subcomponents'.
An example would be something like:
web
web.internal
web.external
web.external.ftp
web.external.http
... ect ...
Having fine grained components could lead to better ticket organization. A more concrete example can be seen in this trac environment... both admin/console and admin/web are listed as components.
Now, I realize that there is nothing stopping someone from adding these names to the list. The real problem lies in the way we can query them.
With the custom query menu, you can only select "is" and "is not" for the component filter. I'd like to add a "begins with" to this. This would allow me to select the "web" component, but still see all it's children components. If I'd like to see something more specific, I could select "web.external".
thanks,
Corey
Attachments
Change History
comment:1 follow-up: ↓ 2 Changed 3 years ago by ebray
comment:2 in reply to: ↑ 1 Changed 3 years ago by rblank
- Resolution set to duplicate
- Status changed from new to closed
Replying to ebray:
... though it does raise the point that startswith/endswith filters for enum fields could be added to the custom query page. This could be a reasonable use case for not just limiting them to "is"/"is not".
And this in turn has been requested several times for other purposes, e.g. #5979, #5526. So yes, definitely a duplicate.
comment:3 Changed 3 years ago by anonymous
Sorry for the dup guys, I didn't see those previous tickets. I'm happy with the implementation in #5979 .



This is mostly a duplicate of #548, though it does raise the point that startswith/endswith filters for enum fields could be added to the custom query page. This could be a reasonable use case for not just limiting them to "is"/"is not".