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
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
Matthew,
Depending on how each ticket is normally assigned per Queue, you could do
something like this:
For each Queue involved;
- 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.
- 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.
- 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
LBNLOn Fri, Mar 4, 2011 at 1:50 PM, Kenneth Marshall ktm@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
Hello Mathew,
More elegant way to deal with this is to use AJAX in Modify.html. It
should change Owner selectbox when different Queue selected.
There is similar situation with squelching recipients in RT. Depending
on type of update (reply/comment) list of recipients is different. RT
3.8 does nothing when the type field is changed. RT 4.0 refreshes page
so list of recipients is refreshed as well. It’s not AJAX, but works.
Similar technique can be used in RT 3.8/4.x.On Sat, Mar 5, 2011 at 12:43 AM, Mathew Snyder mathew.snyder@gmail.com 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
Best regards, Ruslan.