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

[Kenneth Crocker]

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 <ktm at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20110304/05726e4b/attachment.htm>