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
