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