Thanks for that Ken, Could you enlighten me as far as the permissions, what should not be global and moved to the queue instead?
We wont have more then about 8-10 admins so... Regards, Nelson Pereira -----Original Message----- From: Kenneth Crocker [mailto:[EMAIL PROTECTED] Sent: Friday, April 11, 2008 1:15 PM To: Nelson Pereira Cc: Kenneth Marshall; [email protected] Subject: Re: [rt-users] Need help on an approval queue (coding customaction) Nelson, Thanks for the spreadsheet. IT helps a great deal when it comes to debugging. It looks like you grant your AdminCc role a lot of "global" rights. If/when you have a lot of queues, this will prove troublesome , i.e. a AdminCc will have rights on queues you may not want that person to mess with. We have 75 queues and we don't let any AdminCc have some of those rights (create, own, modify) globally because that would give them the ability to interfere (even accidentally, like replying to an email and accidentally putting in the wrong ticket id - ends up in a queue he isn't responsible for) on tickets where he isn't wanted. So most of theose rights we grant to that role on a queue-by-queue basis. We already ran into those problems. Also, you seem to have granted some rights to individual users. Not really a good idea unless you never expect to have very many users (like never more than 10). If some of those users are also in some of those roles that have global rights, then you have compounded the difficulty in debugging due to redundant privileges. YOu make take away the right in one instance but it will remain because of the OTHER instance. So, I would advise you to analyze the usage situation in your setup and re-apply those rights accordingly. Remember, once a right is granted globally to a role or system group, it hardly ever needs to granted again at a lower level. Now to what I think the problem is. Understanding rights is hard enough, but with Approvals, the conditions under which they apply are not consistent, at least that is my experiance as well as others I've seen in the list. This is what we did, We took away the ability to create tickets thru email from all queues except one. That became our "Approvals" queue. We have an AdminCc and user-defined group for that queue and they can own and modify the tickets in that queue. If the problem is easily resolved by them, they do it. If it requires work by someone else, THEY and only THEY move the ticket to the appropriate queue along with their comments. The receiving queue has IT's own AdminCc and group that have rights to JUST that queue and they work on the ticket until resolved, etc. We like this workflow for several reasons: 1) The granting and exercise of privileges is more consistent. 2) All tickets get one ID number and that's it. That way ALL comments, modifications etc. stay with the ticket and it makes following the audit trail much easier (as opposed to seeing one ticket number be approved and another being worked on). The history stays with the ticket. 3) We force the review of all tickets instead of having them arrive, helter-skelter into any queue (maybe even the wrong queue) so work doesn't get mismanaged. All tickets are prioritized compared to ALL work, not just the work in one queue. We haven't had one problem with permissions or correspondence or anything relating to approvals with this method. That's all I can tell you. Some Like the RT method and have gotten it to work. I guess that's why they make different flavors of ice cream (mine is TIn-roof sundae ;-). Hope this helps. Kenn LBNL On 4/11/2008 7:55 AM, Nelson Pereira wrote: > Here is my Permissions list setup in Excel for every queue/group/role > etc... > This way I can track everything.... > > Regards, > > Nelson Pereira > > -----Original Message----- > From: Kenneth Marshall [mailto:[EMAIL PROTECTED] > Sent: Friday, April 11, 2008 10:54 AM > To: Nelson Pereira > Subject: Re: [rt-users] Need help on an approval queue (coding > customaction) > > On Fri, Apr 11, 2008 at 10:47:52AM -0400, Nelson Pereira wrote: >> Also, what is an Actor as far as RT is concerned? >> > The person/user who make the update or change. > > Ken > > > ------------------------------------------------------------------------ > > _______________________________________________ > http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users > > Community help: http://wiki.bestpractical.com > Commercial support: [EMAIL PROTECTED] > > > Discover RT's hidden secrets with RT Essentials from O'Reilly Media. > Buy a copy at http://rtbook.bestpractical.com _______________________________________________ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
