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: [EMAIL PROTECTED] > > > Discover RT's hidden secrets with RT Essentials from O'Reilly Media. > Buy a copy at http://rtbook.bestpractical.com > --
pgpi5VinQCwvG.pgp
Description: PGP signature
_______________________________________________ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
