[rt-users] limit ticket list display on requestor login

Giuseppe Sollazzo gsollazz at sgul.ac.uk
Thu Jun 16 04:39:09 EDT 2011


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<gsollazz at 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: gsollazz at 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: gsollazz at sgul.ac.uk
Direct Dial: +44 20 8725 5160
Fax: +44 20 8725 3583





More information about the rt-users mailing list