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

Thu Jun 16 11:32:39 EDT 2011

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 <gsollazz at 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<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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20110616/121aadec/attachment.htm>