Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Request Tracker: Users

Feature suggestion: Tree view of tickets

 

 

Request Tracker users RSS feed   Index | Next | Previous | View Threaded


richih.mailinglist at gmail

Sep 22, 2008, 4:07 AM

Post #1 of 5 (1447 views)
Permalink
Feature suggestion: Tree view of tickets

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:

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


Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com


jesse at bestpractical

Sep 22, 2008, 6:10 AM

Post #2 of 5 (1392 views)
Permalink
Re: Feature suggestion: Tree view of tickets [In reply to]

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
>
>
> Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
> Buy a copy at http://rtbook.bestpractical.com
>

--


Matt.Brown at pearson

Sep 22, 2008, 7:19 AM

Post #3 of 5 (1368 views)
Permalink
Re: Feature suggestion: Tree view of tickets [In reply to]

I would love to see this functionality as well. In the meantime, I
created a query that will display the child tickets below the parent
ticket, but at this point it only shows the child ticket number, not the
title/status/etc. It's also not collapsible. It's a minor step toward
a tree-view, and likely as far as I can get using just a query.

In Edit Query - Advanced screen, this is in the top box:

( Queue = 'Projects:Matt' ) AND ( Status != 'resolved' AND Status
!= 'rejected' ) AND Priority < 4

And this is in the bottom box:

' <b><a
href="/rt/Ticket/Display.html?id=__id__">__id__</a></b>/TITLE:Ticket',
'<b><a
href="/rt/Ticket/Display.html?id=__id__">__Subject__</a></b>/TITLE:Subje
ct',
'__Status__',
'__QueueName__',
'__OwnerName__',
'__Priority__',
'__NEWLINE__',
'',
'<b><small><a
href="/rt/Ticket/Display.html?id=__id__">__Children__</b></small></a>/TI
TLE:Children',
'<small>__Requestors__</small>',
'<small>__DueRelative__</small>',
'__-__',
'<small>__CreatedRelative__</small>',
'<i><small><a
href="/rt/Ticket/Display.html?id=__LastUpdate__">__LastUpdatedRelative__
</i></small></a>'


I'm sure that there's some line breaks that came through on email.
Remember that each line starts with a ' and you should be able to
re-construct it.

Again, it's not pretty, but it does the job until someone with more
know-how than me updates the Tree-View module/plug-in.

Hope this helps.

Matt

-----Original Message-----
From: rt-users-bounces [at] lists
[mailto:rt-users-bounces [at] lists] On Behalf Of Jesse
Vincent
Sent: Monday, September 22, 2008 8:11 AM
To: Richard Hartmann
Cc: RT Users
Subject: Re: [rt-users] Feature suggestion: Tree view of tickets




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
>
>
> Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
> Buy a copy at http://rtbook.bestpractical.com
>

--
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales [at] bestpractical


Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com


richih.mailinglist at gmail

Sep 22, 2008, 8:09 AM

Post #4 of 5 (1384 views)
Permalink
Re: Feature suggestion: Tree view of tickets [In reply to]

On Mon, Sep 22, 2008 at 16:19, Brown, Matt A. <Matt.Brown [at] pearson> wrote:

> In the meantime, I
> created a query that will display the child tickets below the parent
> ticket,

I tried replacing __Children__ with __DependedOnBy__, but that refuses
to work, i.e. display anything. Also, this can't display deeper levels,
but I am aware this is probably outside the scope of this hack.


Thanks,
Richard
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales [at] bestpractical


Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com


richih.mailinglist at gmail

Sep 22, 2008, 8:14 AM

Post #5 of 5 (1386 views)
Permalink
Re: Feature suggestion: Tree view of tickets [In reply to]

On Mon, Sep 22, 2008 at 15:10, Jesse Vincent <jesse [at] bestpractical> wrote:

> 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.

I will try to get time assigned & poke this, but don't hold your breath.
Will report if there is anything, but if anyone else wants to do so as
well, they are more than welcome to.


Richard


PS: Wouldn't it make sense to merge this into RT trunk? It seems like an
extremely useful option, to me.
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales [at] bestpractical


Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Request Tracker users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.