[rt-users] Feature suggestion: Tree view of tickets

[Jesse Vincent]

On Mon 22.Sep'08 at 13:07:02 +0200, Richard Hartmann wrote:
> 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.
> 

http://search.cpan.org/dist/RT-View-Tree/ 

This was a one-off I built for a customer. It hasn't been touched in 3 years and likely needs some tweaking, but might be worth trying.

> 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:
> 
> 1) How to handle circular dependencies? How to break them?
> 
> 2) 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.
> 
> 3) 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?
> 
> 4) 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
> _______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
> 
> Community help: http://wiki.bestpractical.com
> Commercial support: sales at bestpractical.com
> 
> 
> Discover RT's hidden secrets with RT Essentials from O'Reilly Media. 
> Buy a copy at http://rtbook.bestpractical.com
> 

-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20080922/5a7e60bc/attachment.sig>