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

[Kenneth Crocker]

Giuseppe,

Well, that's a descent sized list. Let's start with an understanding of
privileges; System-Wide, Roles, and User-defined groups.

1) ANY privilege you give to "System-Wide Everyone" doesn't need to be
granted again to ANYONE, ANYWHERE. Every user of the system *already has
that privilege*.
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 *already has that privilege*.
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.

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 *NOT* need to
be granted again (for whatever group; System-wide or Role or User-defined
group) at any Queue level. EVER!

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.

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 *change
only 1 thing*. 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".

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.

"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.
"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.
"ShowTicketComments" is additional. If you *cannot* "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.

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 *only "privileged" users can be in a
group and have rights granted to them*).

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 *other* 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.

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.

Kenn
LBNL


On Mon, Jun 13, 2011 at 2:52 AM, Giuseppe Sollazzo <gsollazz at sgul.ac.uk>wrote:

> Hi Kenneth,
> 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".
>
> 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.
>
> I would like these users to be in a group and, as you say, to do so they
> need to be Privileged.
>
> 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".
> In the global settings we allow System-Everyone, System-Privileged,
> System-Unprivileged and Roles-Requestor the "ShowTicket".
>
> 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".
>
> Now, what happens is what follows:
> - auser unprivileged, not member of any group -> upon logging in, they see
> only "My open tickets"
> - auser privileged, member of "Generic Users" -> upon logging in, they see
> the standard RT at a glance
> - auser privileged, not member of any group -> upon logging in, they see
> the standard RT at a glance
>
> 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).
>
> 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.
>
> Any idea? If I've missed something from your guide, please point it out
>
> Many thanks,
>
> Giuseppe
>
> On 10/06/11 17:16, Kenneth Crocker wrote:
>
>> Giuseppe,
>>
>> I'm attaching a document I created that helps a user understand how
>> privileges works, at least the way we use them. A User cannot be in a
>> group
>> unless they are Privileged. WE do NOT grant ANY rights to individual
>> Users,
>> only groups.
>>
>> Hope the document helps.
>>
>> Kenn
>> LBNL
>>
>> On Fri, Jun 10, 2011 at 5:45 AM, Giuseppe Sollazzo<gsollazz at sgul.ac.uk
>> >wrote:
>>
>>  Uhm...
>>> it seems not to behave like I would like to.
>>>
>>> Basically I have a privileged user U that is part of group "G".
>>> On queue Q group G has right to show/modify/reply, whereas the system
>>> privileged group does not have any right on the queue.
>>> Also, on queue Q role "Requestor" has right to show/modify/reply, whereas
>>> the system privileged group does not have any right on the queue.
>>>
>>> Still, U can see all tickets in queue Q, even those he's not a requestor
>>> for.
>>>
>>> So I'm still looking for a way to hide tickets for which a user in the
>>> group G is not a requestor for from the dashboard, if that's at all
>>> possible
>>> :)
>>>
>>> G
>>>
>>>
>>>
>>>
>>> On 10/06/11 12:06, Raed El-Hames wrote:
>>>
>>>  Giuseppe,
>>>>
>>>> I will not give the Everyone group rights other than Create Ticket and
>>>> ReplyToTicket (and this is only to get the email side of things working
>>>> properly).I also would not give any rights to the Unprivileged group.
>>>>
>>>> For your purposes I would suggest you give the Requestor Role rights to
>>>> ShowTicket/ModifyTicket/ReplyToTicket, and if your requestors are
>>>> Unprivileged then their login will redirect them to the SelfService
>>>> portal
>>>> which is restricted.
>>>>
>>>> Hop
>>>>
>>>
>  e that helps;
>>>> Regards;
>>>> Roy
>>>>
>>>>  -----Original Message-----
>>>>
>>>>> From: rt-users-bounces at lists.bestpractical.com [mailto:rt-users-
>>>>> bounces at lists.bestpractical.com] On Behalf Of Giuseppe Sollazzo
>>>>> Sent: 10 June 2011 10:43
>>>>> To: rt-users at lists.bestpractical.com
>>>>> Subject: [rt-users] limit ticket list display on requestor login
>>>>>
>>>>> Hi,
>>>>> I guess I'm not getting this right.
>>>>>
>>>>> I'd like that a user, upon login, were able to only see the tickets for
>>>>> which they are a requestor (in a given queue).
>>>>>
>>>>> Let's say I have a group G and a queue Q. If rights for G on Q are
>>>>> "Create tickets" and "View queue" obviously they see all tickets in the
>>>>> queue, whereas "Create tickets" alone does not allow them to see any
>>>>> ticket.
>>>>>
>>>>> To keep things tidy, I've also given the same rights to Everyone,
>>>>> Privileged, Unprivileged.
>>>>>
>>>>> Is what I want to do feasible with just permissions management?
>>>>>
>>>>> Thanks,
>>>>> 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
>>>
>>>
>>>
>>>
>
> --
> ____________________________________
>
> 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/20110613/b3f1f9d2/attachment.htm>