Giuseppe, Thanks a bunch. Now that I KNOW how to spell it, I'll never need to use it again. LOL!
Kenn LBNL On Thu, Jun 16, 2011 at 1:39 AM, Giuseppe Sollazzo <gsoll...@sgul.ac.uk>wrote: > Hi Kenneth, > thanks for the clarification - much appreciated. > > The way privileges work is more similar to CSS than Data Base permissions, > I would say. Which makes perfect sense in this kind of context, as it > simplifies greatly the work of admins. > > We are a much smaller institution than you are I guess, so our Queues are > limited in number luckily. Still the hierarchical approach makes it very > easy. > > I think this e-mail conversation would make a perfect example for beginners > on the wiki. > > And btw, all native British English speakers agree on your spelling of > 'Hierarchical' :-P > > Many thanks, > Giuseppe > > > On 15/06/11 18:08, Kenneth Crocker wrote: > >> Giuseppe, >> >> You said, "Basically, the way I interpret this means that if I want my >> users >> to be able to create tickets via the web interface, I need to provide them >> with both "CreateTicket" and "SeeQueue". >> As a side effect, privileged users couldn't be prevented from seeing a >> list >> of other people's tickets (albeit not in details) in that queue if I want >> them to be able to create tickets in that same queue. >> >> Is my interpretation of what you write correct? It seems it's missing the >> effect of "ShowTicket", which allows the grantee to see the list of >> tickets." >> >> Yes, that is correct. You CAN, however, modify your configuration >> (/opt/rt3/etc/RT_SiteConfig.pm) to autocreate as "UnPrivileged". >> >> The changes you made looked good, by the way. >> >> It's important to understand that *PRIVILEGES CANNOT BE PROHIBITED, ONLY >> GRANTED*. That means that if I grant a right GLOBALLY, then anything I do >> for that right at any lower level is *ignored*. *I've already granted that >> right GLOBALLY*. Rights are HIERARCHICAL (I *REALLY* need to find out how >> to >> spell that word correctly ;-). >> >> To further understand privileges, let me give you this example: >> >> I have over 100 Queues, so I don't want everyone to have such a huge >> "drop-down" list, so I grant "SeeQueue" to a User-defined group named >> "XXXX-Users" (where XXXX is the Queue name) at the Queue level. >> >> Also, I don't want just anyone to be able to create tickets in this >> particular Queue so I grant "CreateTicket" to the same Group at the Queue >> level. I do NOT grant "Create Ticket" ANYWHERE Globally because that would >> * >> override* what I wanted at the Queue level FOR THAT RIGHT and allow others >> to be able to create tickets in this particular Queue, regardless of what >> I >> granted at the Queue level. >> >> I want my Requestors to see only their ticket, so I grant "ShowTicket" to >> the Requestor role at the Queue level. >> >> Also, I want those same users (XXXX-Users) to be able to update a specific >> Custom Field (called "Need-By Date") in these tickets so under >> Config->Custom Fields->(select CF)->Group Rights I grant "SeeCustomField" >> and "ModifyCustomField" to that group. >> >> Now, anyone in that group can see this Queue (on the WebUI), create a >> ticket >> (either on the WebUI or Email), See basic metadata in this ticket (except >> comments because I didn't grant that right) AND be able to see AND update >> the value in the CF "Need-By Date". >> >> I actually have some Custom Fields that I update with values (using >> scrips) >> that I use for other functions (like searches and Dashboards, etc) and NO >> ONE in the system, except a "SuperUser" can see those CF's or Modify them >> in >> ANY ticket. >> >> This is the kind of flexibility BP has designed into RT. I've always said >> that everything has a cost. Well, the cost of flexibility is complexity. >> Some stuff in RT CAN be tough to grasp at first. But once you SEE it, it >> makes perfect sense. >> >> I hope this helps. Let me know if I can be of further assistence. >> >> Kenn >> LBNL >> >> >> On Wed, Jun 15, 2011 at 1:56 AM, Giuseppe Sollazzo<gsoll...@sgul.ac.uk >> >wrote: >> >> Hi Kenneth, >>> that helped a lot, thanks. >>> >>> Pitching is a good idea, although us Europeans don't get baseball too >>> much >>> ;-) >>> >>> I managed to get things working as suggested by you: >>> Global - Roles Requestor: ShowTicket >>> Queue X - System Everyone: CreateTicket SeeQueue >>> >>> with this I get exactly what I'm after: users can see their own tickets >>> only, unless they are given more permissions. >>> >>> >>> However, just a clarification. At some point you write: >>> >>> "CreateTicket" - This right has NOTHING to do with seeing it, modifying >>> >>>> it, >>>> etc. It just means that RT will let someone "CREATE" it. That's it. >>>> However, >>>> because you might want to know who created it as well as who wants the >>>> work >>>> done, RT keeps track of the "creator" AND the "Requestor". They are not >>>> always the same. I could easily grant "CreateTicket" to everyone and if >>>> I >>>> didn't grant "ShowTicket" to anyone, no one would see it except the user >>>> with "SuperUser" rights. >>>> "SeeQueue" - This means you can see a Queue (all if granted Globally) in >>>> the >>>> "Drop-down" list of Queues when wanting to create/look at a ticket. If I >>>> grant "SeeQueue" and do not grant "CreateTicket" you will see there are >>>> xx >>>> numbers of ticket in a Queue but not be able to create a ticket there. >>>> >>>> Basically, the way I interpret this means that if I want my users to be >>> able to create tickets via the web interface, I need to provide them with >>> both "CreateTicket" and "SeeQueue". >>> As a side effect, privileged users couldn't be prevented from seeing a >>> list >>> of other people's tickets (albeit not in details) in that queue if I want >>> them to be able to create tickets in that same queue. >>> >>> Is my interpretation of what you write correct? It seems it's missing the >>> effect of "ShowTicket", which allows the grantee to see the list of >>> tickets. >>> >>> A couple of improvements that would be great to have in future are >>> - bulk update of users (e.g. I imported all users as privileged, it turns >>> out I wanted them unprivileged, I wish I could do it from within the >>> interface rather than by scripting). >>> - customising RT at a glance made simpler - I know you can create >>> dashboards, still it seems not that flexible? >>> >>> >>> Thanks again for your kind help and accurate explanation. >>> >>> Best regards, >>> >>> Giuseppe >>> >>> >>> >>> >>> >>> -- >>> ____________________________________ >>> >>> Giuseppe Sollazzo >>> Senior Systems Analyst >>> Computing Services >>> Information Services >>> St. George's, University Of London >>> Cranmer Terrace >>> London SW17 0RE >>> >>> Email: gsoll...@sgul.ac.uk >>> Direct Dial: +44 20 8725 5160 >>> Fax: +44 20 8725 3583 >>> >>> >>> >>> > > -- > ____________________________________ > > Giuseppe Sollazzo > Senior Systems Analyst > Computing Services > Information Services > St. George's, University Of London > Cranmer Terrace > London SW17 0RE > > Email: gsoll...@sgul.ac.uk > Direct Dial: +44 20 8725 5160 > Fax: +44 20 8725 3583 > > >