[rt-users] Allowing users to set only themselves as owners

Henry, Laura lhenry at bcgov.net
Fri Aug 12 15:26:52 EDT 2011

Kenn –

That was my problem – too generous with permissions! I’ve got it now.

Thanks for your help!

Laura C. Henry, MLS
Assistant Systems Librarian
Beaufort County Library
311 Scott Street, Beaufort, SC 29902
Phone 843.255.6444   lhenry at bcgov.net
For Learning ♦ For Leisure ♦ For Life

From: rt-users-bounces at lists.bestpractical.com [mailto:rt-users-bounces at lists.bestpractical.com] On Behalf Of Kenneth Crocker
Sent: Friday, August 12, 2011 12:46 PM
To: rt-users at lists.bestpractical.com
Subject: Re: [rt-users] Allowing users to set only themselves as owners


What you are talking is possible, but it would be thru Permissions on a Queue-by-Queue basis. Once someone has a right globally, you are pretty limited in the ability to restrict access anywhere else. However, if you grant "OwnTicket" to a particular group for a particular Queue, then only they will have the right to own a ticket in that Queue and will only see those members of that group in the drop-down list.

here's where it catches people; most newer RT folks like to grants a lot of rights to users and at the global level. They also do NOT like to be restrictive in the way they design the Queue throughput. If you have all tickets going to the same Queue and then try to do this, it won't work. You'll have to come up with a flow that puts certain tickets into the specific Queue that only that specific group deals with as "first responders". They can't all do it from the same Queue.

This can be done by writing a scrip that accepts tickets, either initially (this would be a global scrip), or in the general Queue and it evaluates some Custom Field (like area of responsibility or type of work or type of something that identifies it) and then based on thos conditions, move the ticket in to one of those specific Queues that has a group of limited members allowed to own a ticket.

That's the best idea I can come up with at the moment.

Hope it helps.

On Fri, Aug 12, 2011 at 9:16 AM, Henry, Laura <lhenry at bcgov.net<mailto:lhenry at bcgov.net>> wrote:
I manage tech requests in our five-branch library system. At each of our five branches, we have a “first responder” who fixes local technical issues, and if the first responder can’t handle the issue, it gets escalated to me.

Right now I have RT set up so that any of the first responders or I can be an owner of a ticket. When a user clicks the dropdown box of possible owners, the list includes all first responders and me. Is there a way to restrict the choice for any given first responder to only “self” or me? For example, when Jane at South Branch puts in a trouble ticket, the list of possible owners would include only Jane or Laura. Meanwhile, Steve at West Branch would see the list of possible owners as Steve or Laura. This will cut down on people accidentally (or “accidentally”) setting the owner to someone at another branch. I hope this all makes sense!

Anyway… I’ve looked at Tools-Configuration-Users-Global- User Rights and Group Rights and all the Queue Configuration fields, as well as the wiki, searched the RT book on Google Books (Only parts of the book are available there, but I don’t own it), and searched the mailing list archives for various permutations of “restrict ownership to self only” and similar. I can’t seem to find anything that looks like what I want. Can anyone point me in the right direction? Is this even possible?


Laura C. Henry, MLS
Assistant Systems Librarian
Beaufort County Library
311 Scott Street, Beaufort, SC 29902
Phone 843.255.6444<tel:843.255.6444>   lhenry at bcgov.net<mailto:lhenry at bcgov.net>
For Learning ♦ For Leisure ♦ For Life

RT Training Sessions (http://bestpractical.com/services/training.html)
*  Chicago, IL, USA — September 26 & 27, 2011
*  San Francisco, CA, USA — October 18 & 19, 2011
*  Washington DC, USA — October 31 & November 1, 2011
*  Melbourne VIC, Australia — November 28 & 29, 2011
*  Barcelona, Spain — November 28 & 29, 2011

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20110812/0469434c/attachment.htm>

More information about the rt-users mailing list