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

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.

Hope that helps;
Regards;
Roy

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 :slight_smile:

GOn 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.

Hope that helps;
Regards;
Roy

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-
bounces@lists.bestpractical.com] On Behalf Of Giuseppe Sollazzo
Sent: 10 June 2011 10:43
To: rt-users@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@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@sgul.ac.uk
Direct Dial: +44 20 8725 5160
Fax: +44 20 8725 3583

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 :slight_smile:

Sounds like you have some global rights getting in the way.

-kevin

Hi Kevin,
that was my first thought - however in “global group rights” all
checkboxes in general/staff/admin rights are unticked for System, Roles,
and for the given user group.

Or is it maybe how I shoudl manage this, by adding “show ticket” to the
global one?

Just in case I have explained myself improperly, what I’m trying to
achieve is that users in the G group are shown in the dashboard a list
of tickets in the queue Q for which they are requestors; such list
should exclude tickets in the same queue for which they are not requestors.

Thanks,
GOn 10/06/11 14:03, Kevin Falcone wrote:

On Fri, Jun 10, 2011 at 01:45:55PM +0100, Giuseppe Sollazzo 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 :slight_smile:

Sounds like you have some global rights getting in the way.

-kevin

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.

Hope that helps;
Regards;
Roy

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-
bounces@lists.bestpractical.com] On Behalf Of Giuseppe Sollazzo
Sent: 10 June 2011 10:43
To: rt-users@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@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@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@sgul.ac.uk
Direct Dial: +44 20 8725 5160
Fax: +44 20 8725 3583

The fist question Giuseppe , is user U privileged or not?

If not then by default he should have been redirected to SelfService/index.html, which again by default should only display
/SelfService/Elements/MyRequests

If he is privileged (then I would ask why? – because according to what you need below he does not need to be privileged), if he has to be privileged then you may have to do some coding … I do think there is a limitation in RT , you should need to give the “SeeQueue” permission to be able to see it in the dropdown ? I would have thought the “CreateTicket” permission should be enough.

As I suggested make user U unprivileged is the easiest solution.

Good luck
Roy

Hi Raed,
thanks a lot as that explains it. This user is Privileged. Removing the
privilege everything works as expected.

What puzzles me is the relationship between system groups and user
defined groups. I would have expected to have the possibility of
limiting permissions to Privileged users in a group rather then having
them as Unprivileged.
But never mind :slight_smile:

Now the problem I have is that all my imported users are Privileged, and
reimporting them does not seem to change this (even with
$LDAPUpdateUsers=1).

Do you reckon there’s a way to bulk update users and make them Unprivileged?

Thanks,
GiuseppeOn 10/06/11 14:50, Raed El-Hames wrote:

The fist question Giuseppe , is user U privileged or not?

If not then by default he should have been redirected to SelfService/index.html, which again by default should only display
/SelfService/Elements/MyRequests

If he is privileged (then I would ask why? – because according to what you need below he does not need to be privileged), if he has to be privileged then you may have to do some coding … I do think there is a limitation in RT , you should need to give the “SeeQueue” permission to be able to see it in the dropdown ? I would have thought the “CreateTicket” permission should be enough.

As I suggested make user U unprivileged is the easiest solution.

Good luck
Roy

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-
bounces@lists.bestpractical.com] On Behalf Of Giuseppe Sollazzo
Sent: 10 June 2011 14:15
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] limit ticket list display on requestor login

Hi Kevin,
that was my first thought - however in “global group rights” all
checkboxes in general/staff/admin rights are unticked for System, Roles,
and for the given user group.

Or is it maybe how I shoudl manage this, by adding “show ticket” to the
global one?

Just in case I have explained myself improperly, what I’m trying to
achieve is that users in the G group are shown in the dashboard a list
of tickets in the queue Q for which they are requestors; such list
should exclude tickets in the same queue for which they are not
requestors.

Thanks,
G

On 10/06/11 14:03, Kevin Falcone wrote:

On Fri, Jun 10, 2011 at 01:45:55PM +0100, Giuseppe Sollazzo 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 :slight_smile:
Sounds like you have some global rights getting in the way.

-kevin

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.

Hope that helps;
Regards;
Roy

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-
bounces@lists.bestpractical.com] On Behalf Of Giuseppe Sollazzo
Sent: 10 June 2011 10:43
To: rt-users@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@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@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@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@sgul.ac.uk
Direct Dial: +44 20 8725 5160
Fax: +44 20 8725 3583

Sorry Giuseppe I don’t have much knowledge of the LDAP plugin.
Under normal circumstances (ie RT auth), I would write script to go through the users need changing and set Privileged to 0
foreach $MyUserId (@my_users_to_change) {
my $u=RT::User->new(RT::SystemUser);
my ($id, $msg) = $u->Load("$MyUserId");
if ($id) {
$u->SetPrivileged(0);
}
}

Regards;
Roy

Hi Raed,
thanks for your very kind help.

I was hoping for the capability of running bulk operations on users to
be added to the user interface at some point :slight_smile:

GOn 10/06/11 16:12, Raed El-Hames wrote:

Sorry Giuseppe I don’t have much knowledge of the LDAP plugin.
Under normal circumstances (ie RT auth), I would write script to go through the users need changing and set Privileged to 0
foreach $MyUserId (@my_users_to_change) {
my $u=RT::User->new(RT::SystemUser);
my ($id, $msg) = $u->Load("$MyUserId");
if ($id) {
$u->SetPrivileged(0);
}
}

Regards;
Roy

-----Original Message-----
From: Giuseppe Sollazzo [mailto:gsollazz@sgul.ac.uk]
Sent: 10 June 2011 15:33
To: Raed El-Hames
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] limit ticket list display on requestor login

Hi Raed,
thanks a lot as that explains it. This user is Privileged. Removing the
privilege everything works as expected.

What puzzles me is the relationship between system groups and user
defined groups. I would have expected to have the possibility of
limiting permissions to Privileged users in a group rather then having
them as Unprivileged.
But never mind :slight_smile:

Now the problem I have is that all my imported users are Privileged, and
reimporting them does not seem to change this (even with
$LDAPUpdateUsers=1).

Do you reckon there’s a way to bulk update users and make them
Unprivileged?

Thanks,
Giuseppe

On 10/06/11 14:50, Raed El-Hames wrote:

The fist question Giuseppe , is user U privileged or not?

If not then by default he should have been redirected to
SelfService/index.html, which again by default should only display
/SelfService/Elements/MyRequests

If he is privileged (then I would ask why? – because according to what
you need below he does not need to be privileged), if he has to be
privileged then you may have to do some coding … I do think there is a
limitation in RT , you should need to give the “SeeQueue” permission to be
able to see it in the dropdown ? I would have thought the "CreateTicket"
permission should be enough.
As I suggested make user U unprivileged is the easiest solution.

Good luck
Roy

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-
bounces@lists.bestpractical.com] On Behalf Of Giuseppe Sollazzo
Sent: 10 June 2011 14:15
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] limit ticket list display on requestor login

Hi Kevin,
that was my first thought - however in “global group rights” all
checkboxes in general/staff/admin rights are unticked for System,
Roles,

and for the given user group.

Or is it maybe how I shoudl manage this, by adding “show ticket” to the
global one?

Just in case I have explained myself improperly, what I’m trying to
achieve is that users in the G group are shown in the dashboard a list
of tickets in the queue Q for which they are requestors; such list
should exclude tickets in the same queue for which they are not
requestors.

Thanks,
G

On 10/06/11 14:03, Kevin Falcone wrote:

On Fri, Jun 10, 2011 at 01:45:55PM +0100, Giuseppe Sollazzo 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 :slight_smile:
Sounds like you have some global rights getting in the way.

-kevin

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.

Hope that helps;
Regards;
Roy

-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-
bounces@lists.bestpractical.com] On Behalf Of Giuseppe Sollazzo
Sent: 10 June 2011 10:43
To: rt-users@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@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@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@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@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@sgul.ac.uk
Direct Dial: +44 20 8725 5160
Fax: +44 20 8725 3583

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
LBNLOn Mon, Jun 13, 2011 at 2:52 AM, Giuseppe Sollazzo gsollazz@sgul.ac.ukwrote:

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@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
:slight_smile:

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@lists.bestpractical.com [mailto:rt-users-
bounces@lists.bestpractical.com] On Behalf Of Giuseppe Sollazzo
Sent: 10 June 2011 10:43
To: rt-users@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@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@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@sgul.ac.uk
Direct Dial: +44 20 8725 5160
Fax: +44 20 8725 3583

Hi Kenneth,
that helped a lot, thanks.

Pitching is a good idea, although us Europeans don’t get baseball too
much :wink:

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

  • customising RT at a glance made simpler - I know you can create
    dashboards, still it seems not that flexible?

As a SuperUser, Configuration -> Global -> RT at a Glance

-kevin

Yes, Kevin, I know that.
What I mean with “flexible” is the capability of customising “RT at a
Glance” on a per-group basis.

GiuseppeOn 15/06/11 16:29, Kevin Falcone wrote:

On Wed, Jun 15, 2011 at 09:56:02AM +0100, Giuseppe Sollazzo wrote:

  • customising RT at a glance made simpler - I know you can create
    dashboards, still it seems not that flexible?
    As a SuperUser, Configuration -> Global -> RT at a Glance

-kevin

Giuseppe Sollazzo
Senior Systems Analyst
Computing Services
Information Services
St. George’s, University Of London
Cranmer Terrace
London SW17 0RE

Email: gsollazz@sgul.ac.uk
Direct Dial: +44 20 8725 5160
Fax: +44 20 8725 3583

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
LBNLOn Wed, Jun 15, 2011 at 1:56 AM, Giuseppe Sollazzo gsollazz@sgul.ac.ukwrote:

Hi Kenneth,
that helped a lot, thanks.

Pitching is a good idea, although us Europeans don’t get baseball too much
:wink:

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

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’ :stuck_out_tongue:

Many thanks,
GiuseppeOn 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 Sollazzogsollazz@sgul.ac.ukwrote:

Hi Kenneth,
that helped a lot, thanks.

Pitching is a good idea, although us Europeans don’t get baseball too much
:wink:

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

Giuseppe,

Thanks a bunch. Now that I KNOW how to spell it, I’ll never need to use it
again. LOL!

Kenn
LBNLOn Thu, Jun 16, 2011 at 1:39 AM, Giuseppe Sollazzo gsollazz@sgul.ac.ukwrote:

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’ :stuck_out_tongue:

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@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
:wink:

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