Hi all,
I would like to bounce an idea to this list:
A tree view mode for search results. Obviously, this would be a large
change, especially if it is done in a generic way. A generic framework
would be able to create structures on any combination of
inter-relations, but the main use case I can see is to make dependent
tickets more manageable.
Consider this example
#1 Buy beer
#3 [+] Go camping (0/5)
#2 Buy junk food
Now, I click on the plus in front of #2:
#1 Buy beer
#3 [-] Go camping (0/5)
#4 Pack tent
#5 Pack sleeping bag
#6 [+] Call friends (0/2)
#2 Buy junk food
#6 would have a 2 sub-tickets of its own, Alice & Bob. After calling
Alice and packing my tent, I would see this:
#1 Buy beer
#3 [-] Go camping (2/5)
#5 Pack sleeping bag
#6 [+] Call friends (1/2)
#2 Buy junk food
The obvious benefit is that you are a lot more aware of what is going
on with nested ticket dependencies.
There are a few considerations which relate to this:
-
How to handle circular dependencies? How to break them?
-
Should finished tickets in this structure be shown or hidden?
Ideally, this would be an option, with the shown tickets using RT’s
ticket-inactive CSS style. -
Should clicking a [+] expand all or just the current sub-tree? Or
should it remember the open/closed status of all tree nodes and restore
to whatever was there before? -
Should the n in the (n/m) display show open or finished ticket count?
Again, this would ideally be an option or, even better, all data would
be accessible via Display Columns of Search.html .
The largest problem I see is 1); RT supports graphs whereas my suggested
scheme is a tree. The trade-off between usability, displayability (made
up a word, yay!) and coding effort on the one hand and data handling
capabilities on the other hand is, imo, a good one in this case, though.
If this feature suggesion is deemed worthy, what would be the
approximate time-frame of this seeing the light of day?
Thanks,
Richard