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