Matthew, Depending on how each ticket is normally assigned per Queue, you could do something like this:
For each Queue involved; 1) Create a CF that is a "Work-Type" or "Work-Category". Each Type/Category is the kind of work that one person *usually* works on. 2) Create a scrip for that Queue that chooses the new Ticket owner based on that CF "Work-Type/Category". Several Types/Categories could point to the same person. 3) Create a scrip that notifies the new owner for that Queue or make it Global. $) The code could be copied and used for other Queues by changing the array of Type to Owners. This way, if a ticket gets moved over to a Queue, the scrip will try and assign an owner and if there is no match, default to "Nobody". We have distinct groups "XXX-Support" for each Queue and only the members in that group can own tickets. Each Group could easily be the basis for the CF. Just a thought. Kenn LBNL On Fri, Mar 4, 2011 at 1:50 PM, Kenneth Marshall <k...@rice.edu> wrote: > On Fri, Mar 04, 2011 at 04:43:46PM -0500, Mathew Snyder wrote: > > Right now our configuration limits who can own tickets in each queue. > > It used to be a flatter configuration in which anyone could own a > > ticket in any queue. This was cumbersome for more than one reason. It > > meant every user was listed in the drop down for every queue. It also > > made tracking work difficult because anyone could take a ticket from > > you while actually doing work or provide conflicting information. > > Knowing this, when someone moves a ticket to a queue which they don't > > have StealTicket or TakeTicket (which implies OwnTicket) rights on it > > is automatically assigned to Nobody, which makes sense. > > > > This leads to a minor concern with my bosses, though. They don't like > > that if they want to assign a ticket to a specific user when moving > > between queues that they have to perform two operations: move the > > ticket then wait for the user list to refresh with the new, authorized > > users and then assign the ticket. They want this to be a single action > > event: Tell RT which queue to send the ticket to and to whom it should > > be assigned when it's moved. This also makes sense. But, as stated, > > one has to wait for the list to be populated with the actual users > > that can own the ticket in the new queue before assigning it to them. > > > > My proposed solution which I'd like some input on (or other possible > > solutions that users have found to work) is to create a custom field > > with every privileged user. One would select the user to whom the > > ticket will be assigned and then a scrip will evaluate the field and > > make the assignment. If someone selects a user that doesn't have > > permission to own a ticket in the destination queue it would > > presumably default to Nobody. Ideally, the field would be able to be > > populated with existing users each time the page is written > > eliminating the need to manually update it whenever a new user is > > created or an old one is eliminated, but that's secondary to the > > problem at hand. > > > > So, what say the masses? Is this a viable solution or has anyone come > > up with something a bit more elegant? > > > > -Mathew > > > > That sounds okay to me. Would it be possible to set the permissions > on the custom field to only be viewable/settable by the "bosses"? > > Cheers, > Ken >