Re: [rt-users] Possible solution for assigning tickets to users
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.sny...@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.
[rt-users] Possible solution for assigning tickets to users
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
Re: [rt-users] Possible solution for assigning tickets to users
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
Re: [rt-users] Possible solution for assigning tickets to users
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 k...@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
