Sub Queues

Hi all,

I’m trying to create a more hierarchical queing system for RT and was
wondering how I can create sub queues.

Regards,
Kevin

Kevin Moran wrote:

Hi all,

I’m trying to create a more hierarchical queing system for RT and was
wondering how I can create sub queues.

I don’t think that it’s reasonable effort.
Hierarchial structures slow down system a lot. For eg current user’s
rights subsytem or Ticket’s EffectiveIds or Attachment’s structure.

So here is collision between perfomance and flexibility.

We have allready this structure on CFs level.
For eg for queue bugs we have custom field ‘module’ with values:
‘Documentation’, ‘xxx lib’, ‘web site’…

Each user uses own search bookmarks.

We are going to create own UI for different workers and thats all.

Ruslan U. Zakirov wrote:

Kevin Moran wrote:

Hi all,

I’m trying to create a more hierarchical queing system for RT and was
wondering how I can create sub queues.

I don’t think that it’s reasonable effort.
Hierarchial structures slow down system a lot. For eg current user’s
rights subsytem or Ticket’s EffectiveIds or Attachment’s structure.

So here is collision between perfomance and flexibility.

We have allready this structure on CFs level.
For eg for queue bugs we have custom field ‘module’ with values:
‘Documentation’, ‘xxx lib’, ‘web site’…

This would allow one to bring together similar queues, but what about
dissimilar queues, e.g.
Project {Docs, Dev, Support, etc.}
Putting all these into one queue ‘Project’, would be a complete mess, surely?

I assume the idea is rather to have umpteen queues all at the same level, such
as: ProjX_Docs, ProjX_Dev, ProjX_Support, …
But this would get pretty unwieldy with more than a few different projects.

Does anyone out there have any examples that would clarify how to set up /
maintain a multi-project system?

Thanks,
Cerion

Cerion Armour-Brown wrote:

Ruslan U. Zakirov wrote:

Kevin Moran wrote:

Hi all,

I’m trying to create a more hierarchical queing system for RT and was
wondering how I can create sub queues.

I don’t think that it’s reasonable effort.
Hierarchial structures slow down system a lot. For eg current user’s
rights subsytem or Ticket’s EffectiveIds or Attachment’s structure.

So here is collision between perfomance and flexibility.

We have allready this structure on CFs level.
For eg for queue bugs we have custom field ‘module’ with values:
‘Documentation’, ‘xxx lib’, ‘web site’…

This would allow one to bring together similar queues, but what about
dissimilar queues, e.g.
Project {Docs, Dev, Support, etc.}
Putting all these into one queue ‘Project’, would be a complete mess, surely?

I assume the idea is rather to have umpteen queues all at the same level, such
as: ProjX_Docs, ProjX_Dev, ProjX_Support, …
But this would get pretty unwieldy with more than a few different projects.

Does anyone out there have any examples that would clarify how to set up /
maintain a multi-project system?

If projects so different that you need different queues for customers
support, then just split it in different RT instance.

We have multi-project system with multi-lang/level support, but we have
one instance.

Queues: support%, bugs, tasks…

  • custom per project stat page
  • CFs: project…
  • scrips which do some workflow automation.

I think it’s fine enought.
For eg Bugzilla use same CF style for different projs and everything fine.

Does anyone out there have any examples that would clarify how to set up /
maintain a multi-project system?

It is generally a bad idea to have queues, which are essentially
permanent objects, for a specific project. (If you listen to the
worshipers of project management theory, a project by definition is
time limited.) Tickets have a time related state (open or closed),
while queues just are (to be a little metaphysical about it).

Within the RT scheme, it is probably best to take advantage of ticket
links. Create a ticket for the project. Then create child or depends
on tickets for the different components of the project. You can even
go to the extreme of creating children tickets of the different
components for specific work packages, activities or tasks. You can
use custom fields to categorize your tickets in a queue to make
searching easier.

HTH,
Michael

Michael S. Liebman m-liebman@northwestern.edu
http://msl521.freeshell.org/
“I have vision and the rest of the world wears bifocals.”
-Paul Newman in “Butch Cassidy & the Sundance Kid”

I seeeee… hmm, I’m now realising ignorance was bliss!

Does anyone out there have any examples that would clarify how to set up
/ maintain a multi-project system?

It is generally a bad idea to have queues, which are essentially
permanent objects, for a specific project. (If you listen to the
worshipers of project management theory, a project by definition is
time limited.) Tickets have a time related state (open or closed),
while queues just are (to be a little metaphysical about it).
metaphysical is good - we like metaphysical!

Within the RT scheme, it is probably best to take advantage of ticket
links. Create a ticket for the project. Then create child or depends
on tickets for the different components of the project. You can even
go to the extreme of creating children tickets of the different
components for specific work packages, activities or tasks. You can
use custom fields to categorize your tickets in a queue to make
searching easier.
HTH,
Michael

This is enlightening! - as was Zakirov’s mail
However (there’s always an however :), I fail to see the big advantage of
having the ‘parent’ tickets at the head of the queue, given:

  1. I think I’ll need CFs to differentiate the projects ticket types
  • so this seems like duplication of effort.
  1. its not possible to search on 'parent ticket = ’ ???
    Or am I still missing something?

I had a go at setting up rt, as Zakirov and yourself suggested:
various queues -> all project tickets, differentiated with CFs
… And was a little frustrated at having to repeat the CF setup for all
queues.
Is there no way to copy CFs from other queues?

Much appreciated,
Cerion

This is enlightening! - as was Zakirov’s mail
However (there’s always an however :), I fail to see the big advantage of
having the ‘parent’ tickets at the head of the queue, given:

The big advantage is a recorded definition of relationships between a
project and it’s activities.

  1. I think I’ll need CFs to differentiate the projects ticket types
  • so this seems like duplication of effort.

That’s only a searching convinience. “I’m a tech writer, find me all
documentation activities.” You could also accomplish it by making sure
a string like “DOCS:” is in the subject of every documentation
activity. TMTOWTDI.

  1. its not possible to search on 'parent ticket = ’ ???
    Or am I still missing something?

Why search for parent ticket == at all? Just search for the parent ticket and have a look in the links section of the ticket display. The links there are actually tags so click away from there to get to the children.

I had a go at setting up rt, as Zakirov and yourself suggested:
various queues -> all project tickets, differentiated with CFs
… And was a little frustrated at having to repeat the CF setup for all
queues.
Is there no way to copy CFs from other queues?

You could do global CFs if all of your queues are for project
management. Then again, if you have enough queues that it is
aggravating you, maybe you have too many queues?

Michael
Michael S. Liebman m-liebman@northwestern.edu
http://msl521.freeshell.org/
“I have vision and the rest of the world wears bifocals.”
-Paul Newman in “Butch Cassidy & the Sundance Kid”

This is enlightening! - as was Zakirov’s mail
However (there’s always an however :), I fail to see the big advantage of
having the ‘parent’ tickets at the head of the queue, given:

The big advantage is a recorded definition of relationships between a
project and it’s activities.

  1. I think I’ll need CFs to differentiate the projects ticket types
  • so this seems like duplication of effort.

That’s only a searching convinience. “I’m a tech writer, find me all
documentation activities.” You could also accomplish it by making sure
a string like “DOCS:” is in the subject of every documentation
activity. TMTOWTDI.

  1. its not possible to search on 'parent ticket = ’ ???
    Or am I still missing something?

Why search for parent ticket == at all? Just search for the parent ticket
and have a look in the links section of the ticket display. The links there
are actually tags so click away from there to get to the children.

Hmm. I can see the usefulness, particularly because CF’s in a queue wouldn’t
be good past one level, e.g.
Bug queue

  • ProjX -> Module_a, Module_b
  • ProjY -> Module_r, Module_s
    So we could make a CF for ‘Projects’, but not ‘Modules’ (we could, but v.
    messy)
    Hence group with parent tickets instead.

But only a searching convenience?!
As you say, you could get to the tickets via the parent, but that precludes
any other searching on those tickets.
How could I then say:
“Find all open bugs under project_x, module_a, under my ownership”
?

thanks again,
Cerion

I accidentally replied directly… oops. Anyway:

The possibilities of Sub Queues are quite powerful, particularly when you start considering what the implications are for templates, permissions, and scrips.

I’ve been eyeballing the idea of using RT to track case data on financial transactions (long story), but there is no way to properly organize or delegate the resulting tickets without the use of sub-queues.

I haven’t thought too hard about how to make this work, as I don’t have the time.

Cheers,
Jason AlonsoOn Thu, Feb 12, 2004 at 05:38:18PM +0100, Cerion Armour-Brown wrote:

On Wednesday 11 February 2004 20:34, Michael S. Liebman wrote:

On Tue, Feb 10, 2004 at 03:26:29PM +0100, Cerion Armour-Brown wrote:

This is enlightening! - as was Zakirov’s mail
However (there’s always an however :), I fail to see the big advantage of
having the ‘parent’ tickets at the head of the queue, given:

The big advantage is a recorded definition of relationships between a
project and it’s activities.

  1. I think I’ll need CFs to differentiate the projects ticket types
  • so this seems like duplication of effort.

That’s only a searching convinience. “I’m a tech writer, find me all
documentation activities.” You could also accomplish it by making sure
a string like “DOCS:” is in the subject of every documentation
activity. TMTOWTDI.

  1. its not possible to search on 'parent ticket = ’ ???
    Or am I still missing something?

Why search for parent ticket == at all? Just search for the parent ticket
and have a look in the links section of the ticket display. The links there
are actually tags so click away from there to get to the children.

Hmm. I can see the usefulness, particularly because CF’s in a queue wouldn’t
be good past one level, e.g.
Bug queue

  • ProjX -> Module_a, Module_b
  • ProjY -> Module_r, Module_s
    So we could make a CF for ‘Projects’, but not ‘Modules’ (we could, but v.
    messy)
    Hence group with parent tickets instead.

But only a searching convenience?!
As you say, you could get to the tickets via the parent, but that precludes
any other searching on those tickets.
How could I then say:
“Find all open bugs under project_x, module_a, under my ownership”
?

thanks again,
Cerion


rt-users mailing list
rt-users@lists.bestpractical.com
http://lists.bestpractical.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

I can’t promise anything, but I’d really love to see a clear spec from
folks interested in subqueues for how they’d work and what they’d do.

Jesse

I wouldn’t call this a “clear spec” but we’d like to have sub-queue’s based on departments. Currently we have created queues such as

Benefits-Health
Benefits-Savings
Benefits-PTO
HR-Administer Workforce
HR-Executive Compensation
HR-Global Workforce

Etc…

It would be nice to have these in sub-queues. This would not only clean up the looks of the “Home” page but would make it a bit easier to grant permissions to a group of queues. The downside though is that sub-groups would probably be the next request to facilitate trickle down permissions. (Unless sub-groups have been added since RT 3.0.0 which is what we’re still at…) Separate instances of RT is not viable since there is a lot of inter-departmental collaboration going on.

Ray

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Just wanted to throw in a “me too”.

I was astonished that there is such a multitude (and in the beginning
confusing) of possibilities how to manage users (e.g. set permissions
globally or per queue or per user, group users, group groups of users etc.)
but that there is no way to group queues.

I have the problem, that I want to define the same custom fields on a lot of
queues but not all. Now I can either go through all these queues one by one
or add all customs fields globally and tell people to ignore them on some
queues. Bu that’s not nice.

Cheers,
Stephan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFAK+ly0TAeRPnvmyERApdqAJ9DU91vJF2MO8gETs0i2l8RWSnJ+ACeO1wj
IvVVL1MgPQSwJlfd9CDd9AM=
=bZVX
-----END PGP SIGNATURE-----

I can’t promise anything, but I’d really love to see a clear spec from
folks interested in subqueues for how they’d work and what they’d do.

Queue “Groups” would be very cool. It’d be nice to assign user/group
rights to an entire “Queue Group” or “sub-queue set”.

Brian.
“If you do boring, stupid monotonous work, chances are you’ll end up boring,
stupid and monotonous.”

Hello,

–Am Freitag, 13. Februar 2004 9:23 Uhr +0000 schrieb Brian Scanlan
brian.scanlan@redbrick.dcu.ie:

Queue “Groups” would be very cool. It’d be nice to assign user/group
rights to an entire “Queue Group” or “sub-queue set”.

yes, allthough all these nice additional features make right granting less
transparent.

I have done something different which was helpful for me nd is "somewhat"
complemantary to “queue groups”.

I wanted to assign different “admins” and “dispatchers” to some queues and
found that I needed “right groups” for that (admins shall admin custom
keywords of a queue and ACLs, what AdminCCs should not), dispatcher should
only be able to target a queue with tickets.

Since “right groups” are roles, I found out how to implement additional
Queue-Roles (besides AdminCc and Cc) and make them visible and configurable
by the web-interface.

If there is enough interest, I would polish this up some day, and make a
patch/feature proposal.

Dirk.

I can’t promise anything, but I’d really love to see a clear spec from
folks interested in subqueues for how they’d work and what they’d do.

Queue “Groups” would be very cool. It’d be nice to assign user/group
rights to an entire “Queue Group” or “sub-queue set”.

That could save some time. I avoid some of the grunge work by
putting all the users in groups and only assigning group
permissions on the queues and in cases where there the
admincc’s match an existing system email group (which is
often the case here) I create a dummy user with the list
as the email address for the entry in watchers. There is
a side effect of this that people get email copies of their
own changes, but my users seem to prefer it that way.

Les Mikesell
les@futuresource.com

Hmm. I can see the usefulness, particularly because CF’s in a queue wouldn’t
be good past one level, e.g.
Bug queue

  • ProjX -> Module_a, Module_b
  • ProjY -> Module_r, Module_s
    So we could make a CF for ‘Projects’, but not ‘Modules’ (we could, but v.
    messy)
    Hence group with parent tickets instead.

But only a searching convenience?!

Ok. I misunderstood what kind of CF you were going to create. A CF
that defines the type of work package (e.g., docs, testing,
refactoring) would probably be just a searching convienience. One that
defines the parent would be necessary for searching currently if you
go to multiple depths.

As you say, you could get to the tickets via the parent, but that precludes
any other searching on those tickets.
How could I then say:
“Find all open bugs under project_x, module_a, under my ownership”

I think we are talking about two different things. I would set up
queues differently for project management and issue tracking. My issue
tracking queues have CFs defined for application and module. My
project tracking queues rely on links.

Michael
Michael S. Liebman m-liebman@northwestern.edu
http://msl521.freeshell.org/
“I have vision and the rest of the world wears bifocals.”
-Paul Newman in “Butch Cassidy & the Sundance Kid”

I can’t promise anything, but I’d really love to see a clear spec from
folks interested in subqueues for how they’d work and what they’d do.

Not that we are voting, but I’m -1 for subqueues and +1 for enhancing
the linking facility. I don’t think yet another heirachy is a good
idea. Things are complex enough. Also, linking gives you greater
flexibility and versatility in your relationships between “things.”

Michael
Michael S. Liebman m-liebman@northwestern.edu
http://msl521.freeshell.org/
“I have vision and the rest of the world wears bifocals.”
-Paul Newman in “Butch Cassidy & the Sundance Kid”

[snip]

Ok. I misunderstood what kind of CF you were going to create. A CF
that defines the type of work package (e.g., docs, testing,
refactoring) would probably be just a searching convienience. One that
defines the parent would be necessary for searching currently if you
go to multiple depths.
[snip]
I think we are talking about two different things. I would set up
queues differently for project management and issue tracking. My issue
tracking queues have CFs defined for application and module. My
project tracking queues rely on links.

I see - so how do you manage multiple levels in your issue tracking?
Or do you simply find it’s not necessary?
To answer Jesse Vincent, I’d need to know if I want sub-queues, which I’m not
certain I do! Simple logic says they’d be good, but perhaps this is flawed -
I’d like to know how people manage without them!
My trouble is I’ve never used a system like this… perhaps what I really need
is a project management course :wink:

In the meantime, however… would anyone out there mind giving some examples
of their own RT setup?

I’m sure they’d be many and varied - RT is marvelously tweakable! - however, I
think this would really help me get to grips with the possibilities (and many
others, looking at some of the questions on this list)
Maybe worth then taking the most graphical examples of these and bundling them
with RT?

Oh, one more thing - how hard would it be to add the code for ‘search by
parent’?

Cheers,
Cerion

But no means “complete specs”, but my $.02 on “subqueues”.

On a couple of the ticketing systems I’ve worked on, the queues are aligned to the organizational groups that use them. These groups tended to perform “subtasks” that seem to correspond to subqueues. It’s not a matter of hierarchy or ease/efficiency of implementation, but more of a problem of better alignment to how people actually use these systems.

I’d like to point out that the subqueues are important to members of the group that use the queue. A Sales queue might be a good example: You’ve got qualified leads, unqualified leads, possible orders from current customers, callbacks, etc. If they are organized as such, one can assign someone to “do callbacks” and expect that they will know what Tickets you’re talking about. To almost everyone else in the organization there’s just 50 tickets in the sales queue.

I’ve been viewing these subqueues as being implemented with a keyword (custom field) in a queue; so as to not impact any of the reports and ACLs.

I’m guessing that the only major impact is in the “home page” quicksearch display. There is a minor impact in the basics display to move it to another queue (needs to attach the keyword). I’m leaning towards only showing subqueues to members of certain groups, and not allowing email creation in these groups (internal groups only).

Alright, maybe thats $.04 worth!

Bill George
RT Plumbing and Heating
Vonage

Stephan Uhlmann wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Just wanted to throw in a “me too”.

I was astonished that there is such a multitude (and in the beginning
confusing) of possibilities how to manage users (e.g. set permissions
globally or per queue or per user, group users, group groups of users etc.)
but that there is no way to group queues.

I have the problem, that I want to define the same custom fields on a lot of
queues but not all. Now I can either go through all these queues one by one
or add all customs fields globally and tell people to ignore them on some
queues. Bu that’s not nice.
I don’t vote for sub queues or queues grouping, but think that it would
be very useful to iplement in core waht Dirk Pape done with scrips.

He has patch that allow to disable global scrips on queue level, CF-s
need it too.

RT has Scrips, CFs and Templates on global level.
This objects should have next features:
1) Disable on queue level(Scrips, CFs)
2) Override on queue level(Templates)

		Best regards.