[rt-users] Possible solution for assigning tickets to users

[Kenneth Marshall]

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