Hi, Our RT installation has recently had a large influx of new queues and groups, and I'd like to delegate some of the day-to-day maintenance of things to certain people within those groups so that I'm not doing data entry for everyone.
For each logical group of folks, I've created an "Admins" group, for example: "Engineering RT Admins", "Humanities RT Admins" and so on. In global rights, I've given that group access to "Show Admin Menu", "View Scrips" and "View Scrip Templates" and "Allow writing Perl code in templates, scrips, etc". For each engineering queue, I've given that group full control - all boxes are checked in the queue configuration under "group rights" for that queue, primarily so they can modify their scrips and templates. For each engineering group, I've given that group full control as well, so that they can add and remove members as needed. My question has a few parts: 1. Are there any other "global" rights that I should be assigning these folks? Are there any dangers/pitfalls to consider in this kind of configuration? 2. Is there any way to trim down the "Admin" menu so that it only shows things that the person has access to? 3. On the admin pages that list groups and queues, the system paginates as though the user can see all 100 or so queues and groups, but they have to go to page 3 to get see their queues/groups; pages 1 and 2 show up in the pager, but have no content, as the users don't have access to queues/groups displayed on those pages. Can this be cleaned up so that the system only paginates for the queues and groups that the user has access to? 4. Is it possible to give someone the ability to edit a queue's scrips and templates without also allowing them to edit everything else about the queue? Changing queue names breaks our sendmail configuration, so I'd like to prevent them from doing that if at all possible. 5. Is there anything else I should be tracking while delegating this sort of access to other folks? -- Tim Gustafson t...@ucsc.edu 831-459-5354 Baskin Engineering, Room 313A