Giuseppe,<br><br>Well, that's a descent sized list. Let's start with an understanding of privileges; System-Wide, Roles, and User-defined groups.<br><br>1) ANY privilege you give to "System-Wide Everyone" doesn't need to be granted again to ANYONE, ANYWHERE. Every user of the system <i>already has that privilege</i>.<br>
2) ANY privilege you give to "System-Wide Privileged" doesn't need to be
granted again to ANY OTHER ROLE or User-Defined GROUP, ANYWHERE. Every "Privileged" user of the system <i>already has
that privilege</i>.<br>3) ROLES can include "Unprivileged" as in Requestor or Cc's & AdminCc's AT THE TICKET LEVEL! I believe A Queue Watcher must be a Privileged User (anyone out there can correct me if I'm wrong on this. I've always assumed it to be so). I believe the Owner Role must also be privileged as it usually involves privileges that should ONLY be granted to a "Privileged" User. I look at ROLES as being a "Psuedo-type" group, in that it deals with a collection of users, but is more generis that a user-defined group.<br>
<br>ALL Privileges work hierarchily (is that a word?). What I mean to say is that if a privilege is granted GLOBALLY, then that right does <b>NOT</b> need to be granted again (for whatever group; System-wide or Role or User-defined group) at any Queue level. EVER!<br>
<br>The reason I mention this is because I see so many people out there that have difficult debugging their "Privilege" issues and I beleieve that is because they have compounded their "rights" situation with so much redundancy. If you grant a bunch of privileges all over the place, then you automatically have more places to look and control in order to "SEE" what's being allowed.<br>
<br>The best analogy I can come up with for that is "Pitching" in baseball. When a pitcher needs to find out what's wrong with his pitch, he should <i>change only 1 thing</i>. If he makes more than one adjust to his pitch and the ball goes where he wants it too, he won't know which adjustment made it work. He's complicated his "debugging" by including "too many variables". That's why I advocate keeping the administration of rights to a simple level. In other words, "Less is better".<br>
<br>Now, Let's try to understand just what some of these rights do. It hard to know what to let someone have as a right if you don't understand the depth and relationships of these rights. That's why I sent you that guide.<br>
<br>"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.<br>
"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.<br>
"ShowTicket" - Unless I grant this along with the two above, you may be able to see a Queue, a list of tickets in that Queue, but not see the details of a particular ticket.<br>"ShowTicketComments" is additional. If you <i>cannot</i> "See" a ticket, then you shouldn't be able to see the comments in a ticket. However, If I grant you "ShowTicket" but NOT "ShowTicketComments", then you will see some information, just not the comments. Does that make any sense? BP wanted to allow us to "compartmentalize" some ticket data from general ticket info.<br>
<br>In your situation, you want the Requestors to just see "their own"
tickets. Because a "Requestor" can be a "privileged" (I call these
people "inside the system" users) or "unprivileged" (I call these people
"outside the system" users. Someone who NEVER signs into RT, may not
even be an employee, etc.) BP created this role just for that reason.
Therefore, you can grant rights to this role without having to worry
about whether the user is privileged or not. It's a "psuedo" group of
users. NOT a "System-wide" user. That's why BP created roles as an
entity that can have privileges without the requirement of being
"privileged" and in a group (this is the group of users that are an
"exception" to the general rule of <i>only "privileged" users can be in a group and have rights granted to them</i>).<br>
<br>
Sooooo, grant the right "ShowTicket" to the "Requestor" role "Globally".
Now, if you want this type of right for Requestors ONLY (no one else
needs that right) for just a Queue, then we DO NOT grant that right
Globally, but break it down to "who needs what & where". If someone <i>other</i>
than the Requestor needs to see these tickets, let's get them defined. Is
this group so general that they are ALL "Privileged" users? Can they be
defined as needing this right Globally? Just 1 or a few Queues out of
many Queues? Here's where my rule of not giving away these rights
redundantly can come in handy.<br><br>Take a look at the examples I put in the guide I sent you (they are at the back) and see if they make any sense to you. My installation is for software support, so I keep some rights more exclusive to the Queue (each application has a Queue) level. Then send me a list of what you think you should do for your situation and I'll respond.<br>
<br>Kenn<br>LBNL<br> <br><br><div class="gmail_quote">On Mon, Jun 13, 2011 at 2:52 AM, Giuseppe Sollazzo <span dir="ltr"><<a href="mailto:gsollazz@sgul.ac.uk">gsollazz@sgul.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Kenneth,<br>
sorry if I reply back again - I've had a look at the document and I'm a bit puzzled by the behaviour of "RT at a glance".<br>
<br>
As I wrote before, what I'm trying to achieve is that a generic user (we import users via ldap) that logs in into the system can only see tickets for which they are requestors.<br>
<br>
I would like these users to be in a group and, as you say, to do so they need to be Privileged.<br>
<br>
My setting is very simple. We allow System-Everyone, System-Privileged and System-Unprivileged "CreateTicket" rights (I know this can be reduced to System-Everyone only, but let's keep things like this for a moment) on the queue "Support".<br>
In the global settings we allow System-Everyone, System-Privileged, System-Unprivileged and Roles-Requestor the "ShowTicket".<br>
<br>
I also have three groups: Sysadmin, PC Support, and Generic Users. Generic Users have no privileges defined on the queue Support. The user I have is called "auser".<br>
<br>
Now, what happens is what follows:<br>
- auser unprivileged, not member of any group -> upon logging in, they see only "My open tickets"<br>
- auser privileged, member of "Generic Users" -> upon logging in, they see the standard RT at a glance<br>
- auser privileged, not member of any group -> upon logging in, they see the standard RT at a glance<br>
<br>
But of course all of this could be fixed by changing the RT at a glance (although I'm still looking for a way to customize it).<br>
<br>
What worries me more is that as per configuration "auser" can't SeeQueue, and correctly the select menu near "New ticket in" is empty. However, if "Unowned tickets" is in their RT At a Glance (i.e. they are privileged) they will see and be able to read the ticket content even if "ShowTicket" is not granted.<br>
<br>
Any idea? If I've missed something from your guide, please point it out<br>
<br>
Many thanks,<div class="im"><br>
Giuseppe<br>
<br>
On 10/06/11 17:16, Kenneth Crocker wrote:<br>
</div><div><div></div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Giuseppe,<br>
<br>
I'm attaching a document I created that helps a user understand how<br>
privileges works, at least the way we use them. A User cannot be in a group<br>
unless they are Privileged. WE do NOT grant ANY rights to individual Users,<br>
only groups.<br>
<br>
Hope the document helps.<br>
<br>
Kenn<br>
LBNL<br>
<br>
On Fri, Jun 10, 2011 at 5:45 AM, Giuseppe Sollazzo<<a href="mailto:gsollazz@sgul.ac.uk" target="_blank">gsollazz@sgul.ac.uk</a>>wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Uhm...<br>
it seems not to behave like I would like to.<br>
<br>
Basically I have a privileged user U that is part of group "G".<br>
On queue Q group G has right to show/modify/reply, whereas the system<br>
privileged group does not have any right on the queue.<br>
Also, on queue Q role "Requestor" has right to show/modify/reply, whereas<br>
the system privileged group does not have any right on the queue.<br>
<br>
Still, U can see all tickets in queue Q, even those he's not a requestor<br>
for.<br>
<br>
So I'm still looking for a way to hide tickets for which a user in the<br>
group G is not a requestor for from the dashboard, if that's at all possible<br>
:)<br>
<br>
G<br>
<br>
<br>
<br>
<br>
On 10/06/11 12:06, Raed El-Hames wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Giuseppe,<br>
<br>
I will not give the Everyone group rights other than Create Ticket and<br>
ReplyToTicket (and this is only to get the email side of things working<br>
properly).I also would not give any rights to the Unprivileged group.<br>
<br>
For your purposes I would suggest you give the Requestor Role rights to<br>
ShowTicket/ModifyTicket/ReplyToTicket, and if your requestors are<br>
Unprivileged then their login will redirect them to the SelfService portal<br>
which is restricted.<br>
<br>
Hop<br>
</blockquote></blockquote></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
e that helps;<br>
Regards;<br>
Roy<br>
<br>
-----Original Message-----<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
From: <a href="mailto:rt-users-bounces@lists.bestpractical.com" target="_blank">rt-users-bounces@lists.bestpractical.com</a> [mailto:<a href="mailto:rt-users-" target="_blank">rt-users-</a><br>
<a href="mailto:bounces@lists.bestpractical.com" target="_blank">bounces@lists.bestpractical.com</a>] On Behalf Of Giuseppe Sollazzo<br>
Sent: 10 June 2011 10:43<br>
To: <a href="mailto:rt-users@lists.bestpractical.com" target="_blank">rt-users@lists.bestpractical.com</a><br>
Subject: [rt-users] limit ticket list display on requestor login<br>
<br>
Hi,<br>
I guess I'm not getting this right.<br>
<br>
I'd like that a user, upon login, were able to only see the tickets for<br>
which they are a requestor (in a given queue).<br>
<br>
Let's say I have a group G and a queue Q. If rights for G on Q are<br>
"Create tickets" and "View queue" obviously they see all tickets in the<br>
queue, whereas "Create tickets" alone does not allow them to see any<br>
ticket.<br>
<br>
To keep things tidy, I've also given the same rights to Everyone,<br>
Privileged, Unprivileged.<br>
<br>
Is what I want to do feasible with just permissions management?<br>
<br>
Thanks,<br>
Giuseppe<br>
<br>
--<br>
____________________________________<br>
<br>
Giuseppe Sollazzo<br>
Senior Systems Analyst<br>
Computing Services<br>
Information Services<br>
St. George's, University Of London<br>
Cranmer Terrace<br>
London SW17 0RE<br>
<br>
Email: <a href="mailto:gsollazz@sgul.ac.uk" target="_blank">gsollazz@sgul.ac.uk</a><br>
Direct Dial: <a href="tel:%2B44%2020%208725%205160" value="+442087255160" target="_blank">+44 20 8725 5160</a><br>
Fax: <a href="tel:%2B44%2020%208725%203583" value="+442087253583" target="_blank">+44 20 8725 3583</a><br>
<br>
<br>
</blockquote></blockquote>
--<br>
____________________________________<br>
<br>
Giuseppe Sollazzo<br>
Senior Systems Analyst<br>
Computing Services<br>
Information Services<br>
St. George's, University Of London<br>
Cranmer Terrace<br>
London SW17 0RE<br>
<br>
Email: <a href="mailto:gsollazz@sgul.ac.uk" target="_blank">gsollazz@sgul.ac.uk</a><br>
Direct Dial: <a href="tel:%2B44%2020%208725%205160" value="+442087255160" target="_blank">+44 20 8725 5160</a><br>
Fax: <a href="tel:%2B44%2020%208725%203583" value="+442087253583" target="_blank">+44 20 8725 3583</a><br>
<br>
<br>
<br>
</blockquote></blockquote>
<br>
<br></div></div>
-- <br><div><div></div><div class="h5">
____________________________________<br>
<br>
Giuseppe Sollazzo<br>
Senior Systems Analyst<br>
Computing Services<br>
Information Services<br>
St. George's, University Of London<br>
Cranmer Terrace<br>
London SW17 0RE<br>
<br>
Email: <a href="mailto:gsollazz@sgul.ac.uk" target="_blank">gsollazz@sgul.ac.uk</a><br>
Direct Dial: <a href="tel:%2B44%2020%208725%205160" value="+442087255160" target="_blank">+44 20 8725 5160</a><br>
Fax: <a href="tel:%2B44%2020%208725%203583" value="+442087253583" target="_blank">+44 20 8725 3583</a><br>
<br>
<br>
</div></div></blockquote></div><br>