Problems with permissions (bug?)

Dear list,

I’m using rt 3.8.8 and facing problems in setting up permissions for a queue.

What I want is that users see the tickets they have requested in a certain queue only.
So user A cannot see tickets requested by user B and vice versa.

So I applied the following rights

→ Configuration → Queues → Group rights

Roles

Requestor:

  • CommentOnTicket
  • DeleteTicket
  • ForwardMessage
  • ModifyCustomField
  • ModifyTicket
  • OwnTicket
  • ReplyToTicket
  • SeeCustomField
  • ShowOutgoingEmail
  • ShowTicket
  • ShowTicketComments
  • StealTicket
  • TakeTicket
  • Watch
  • WatchAsAdminCc

User defined groups

1_rt_eval

  • SeeQueue
  • CreateTicket

2_rt_eval

  • SeeQueue
  • CreateTicket

This basically works, but when a user logs in he finds an empty RT at a glance page.
But searching for his email address gives the expected results.
So my only problem is that the Queue is not displayed in the Quicksearch.
After a lot of searching in the mailing list archives I got some hints.

I applied the following rights additionally:

System groups

Privileged:

  • SeeQueue
  • CreateTicket
  • ShowTicket

After login the Quicksearch is populated with that queue but all tickets are shown.
So I removed the ShowTicket right from Privileged (while the user is still logged in). After a reload of the RT at a glance page the user sees the queue in the quicksearch. Following the link shows the correct tickets (the ticket count is wrong but this doesn’t matter).

Everything fine so far, but when the user logs out and in again Quicksearch is empty again. This is fully reproducible.

Do I miss something here or is this a bug?

Thanks for any help!

Markus
T-Systems International GmbH
SDU Telco NPS
Vorgebirgsstr. 49
53119 Bonn
Tel: + 49 228 9841 3820
E-Mail: markus.kummer@t-systems.com

T-Systems International GmbH
Aufsichtsrat: René Obermann (Vorsitzender)
Geschäftsführung: Reinhard Clemens (Vorsitzender), Dr. Ferri Abolhassan, Olaf Heyden, Joachim Langmack, Dr. Matthias Schuster, Klaus Werner
Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644

Markus,

It seems you want the Requestor to basically create, own and modify their
own requested ticket? You granted some rights to Privileged and then granted
the same rights again to a couple groups. If they have the right as a
privileged user, then you do not need to grant the same rights again to a
group, since only privileged users can be in a group.
I would grant “SeeQueue” and “CreateTicket” to privileged users and then
grant what you want to the requestor. Apparently, the groups are
extraneous, so don’t bother with them. If you can make a distinction between
what kind of privileges are necessary between groups and certain roles, then
create the group and add members. Also, I HOPe you are not granting any
rights to individual users. WAY BAD! Too much maintenance if you have a lot
of users.

Hope this helps.

Kenn
LBNLOn Tue, May 11, 2010 at 9:47 AM, Markus.Kummer@t-systems.com wrote:

Dear list,

I’m using rt 3.8.8 and facing problems in setting up permissions for a
queue.

What I want is that users see the tickets they have requested in a certain
queue only.
So user A cannot see tickets requested by user B and vice versa.

So I applied the following rights

→ Configuration → Queues → Group rights

Roles

Requestor:

  • CommentOnTicket
  • DeleteTicket
  • ForwardMessage
  • ModifyCustomField
  • ModifyTicket
  • OwnTicket
  • ReplyToTicket
  • SeeCustomField
  • ShowOutgoingEmail
  • ShowTicket
  • ShowTicketComments
  • StealTicket
  • TakeTicket
  • Watch
  • WatchAsAdminCc

User defined groups

1_rt_eval

  • SeeQueue
  • CreateTicket

2_rt_eval

  • SeeQueue
  • CreateTicket

This basically works, but when a user logs in he finds an empty RT at a
glance page.
But searching for his email address gives the expected results.
So my only problem is that the Queue is not displayed in the Quicksearch.
After a lot of searching in the mailing list archives I got some hints.

I applied the following rights additionally:

System groups

Privileged:

  • SeeQueue
  • CreateTicket
  • ShowTicket

After login the Quicksearch is populated with that queue but all tickets
are shown.
So I removed the ShowTicket right from Privileged (while the user is still
logged in). After a reload of the RT at a glance page the user sees the
queue in the quicksearch. Following the link shows the correct tickets (the
ticket count is wrong but this doesn’t matter).

Everything fine so far, but when the user logs out and in again Quicksearch
is empty again. This is fully reproducible.

Do I miss something here or is this a bug?

Thanks for any help!

Markus

T-Systems International GmbH
SDU Telco NPS
Vorgebirgsstr. 49
53119 Bonn
Tel: + 49 228 9841 3820
E-Mail: markus.kummer@t-systems.com

T-Systems International GmbH
Aufsichtsrat: René Obermann (Vorsitzender)
Geschäftsführung: Reinhard Clemens (Vorsitzender), Dr. Ferri Abolhassan,
Olaf Heyden, Joachim Langmack, Dr. Matthias Schuster, Klaus Werner
Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der
Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Dear list,

I’m using rt 3.8.8 and facing problems in setting up permissions for a queue.

What I want is that users see the tickets they have requested in a certain queue only.
So user A cannot see tickets requested by user B and vice versa.

So I applied the following rights

→ Configuration → Queues → Group rights

Roles

Requestor:

  • CommentOnTicket

Do you really want requestors to comment and see comments?

  • DeleteTicket
  • ForwardMessage
  • ModifyCustomField
  • ModifyTicket
  • OwnTicket

Requestor can own a ticket? Wierd.

  • ReplyToTicket
  • SeeCustomField
  • ShowOutgoingEmail
  • ShowTicket
  • ShowTicketComments
  • StealTicket
  • TakeTicket

This is wierd as well as OwnTicket.

  • Watch
  • WatchAsAdminCc

This is something wierd too.

User defined groups

1_rt_eval

  • SeeQueue
  • CreateTicket

2_rt_eval

  • SeeQueue
  • CreateTicket

This basically works, but when a user logs in he finds an empty RT at a glance page.
But searching for his email address gives the expected results.
So my only problem is that the Queue is not displayed in the Quicksearch.
After a lot of searching in the mailing list archives I got some hints.

I applied the following rights additionally:

System groups

Privileged:

  • SeeQueue
  • CreateTicket
  • ShowTicket

After login the Quicksearch is populated with that queue but all tickets are shown.
So I removed the ShowTicket right from Privileged (while the user is still logged in). After a reload of the RT at a glance page the user sees the queue in the quicksearch. Following the link shows the correct tickets (the ticket count is wrong but this doesn’t matter).

Everything fine so far, but when the user logs out and in again Quicksearch is empty again. This is fully reproducible.

Do I miss something here or is this a bug?

Sounds like it, but to be sure clean all sessions in the DB.

Thanks for any help!

Best regards, Ruslan.

Hi Ken ,hi Ruslan,

thank you for your advice.

I know that my rights config seems to be unlogical, so let me explain why I started like this.

At the moment we have two departments working on incident reports in two queues. Both departments cannot see the other departments queue. Sometimes Dep. A needs to give a ticket to dep. B. In this case we follow a special workflow to realize that (Scrips).
Dep. A change the status of a ticket in their queue to “ext” and write a reply. This procedure creates a “child” ticket in the Queue of dep B. Then Dep B works on that ticket. Some activities in the dep B queue cause a syncronization with the ticket in the queue of dep A. After the ticket is “resolved” in dep B the status of the parent ticket in queue of dep A is set to “fixed” and the workflow ends.
This workflow causes a lot of confusion for the users. They forget to write a reply after changing the status to “ext” and so on.
To make it more simple we want to merge the two queues and find another way to seperate the tickets of the two departments.

What I posted before was the “first try”. The intention is that the two departments get exactly one requestor for each queue. So they have to log in as those requestors to see all their tickets. If dep A wants to give a ticket to dep B it just change the requestor to the one of dep B.

In the second step I want to give rights to the owners of the tickets too. Then the “requestor of dep B” changes the owner to the one who has to work on that ticket. So if an owner logs in he sees all the tickets he has to work on.

Maybe this is the wrong way but I don’t know what else to do.

Ken wrote:

You granted some rights to Privileged and then granted the same rights again to a couple groups.
The rights for Privileged I just applied because it was adviced in a post to see the Queue in Quicksearch. Actually I don’t want rights for privileged users.

Ruslan wrote:

Sounds like it, but to be sure clean all sessions in the DB.
Same behaviour after cleaning all sessions.

Best regards,

Markus
T-Systems International GmbH
SDU Telco NPS
Vorgebirgsstr. 49
53119 Bonn
Tel: + 49 228 9841 3820
E-Mail: markus.kummer@t-systems.com

T-Systems International GmbH
Aufsichtsrat: René Obermann (Vorsitzender)
Geschäftsführung: Reinhard Clemens (Vorsitzender), Dr. Ferri Abolhassan, Olaf Heyden, Joachim Langmack, Dr. Matthias Schuster, Klaus Werner
Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644Von: ruslan.zakirov@gmail.com [mailto:ruslan.zakirov@gmail.com] Im Auftrag von Ruslan Zakirov
Gesendet: Dienstag, 11. Mai 2010 21:18
An: Kummer, Markus
Cc: rt-users@lists.bestpractical.com
Betreff: Re: [rt-users] Problems with permissions (bug?)

Dear list,

I’m using rt 3.8.8 and facing problems in setting up permissions for a queue.

What I want is that users see the tickets they have requested in a certain queue only.
So user A cannot see tickets requested by user B and vice versa.

So I applied the following rights

→ Configuration → Queues → Group rights

Roles

Requestor:

  • CommentOnTicket

Do you really want requestors to comment and see comments?

  • DeleteTicket
  • ForwardMessage
  • ModifyCustomField
  • ModifyTicket
  • OwnTicket

Requestor can own a ticket? Wierd.

  • ReplyToTicket
  • SeeCustomField
  • ShowOutgoingEmail
  • ShowTicket
  • ShowTicketComments
  • StealTicket
  • TakeTicket

This is wierd as well as OwnTicket.

  • Watch
  • WatchAsAdminCc

This is something wierd too.

User defined groups

1_rt_eval

  • SeeQueue
  • CreateTicket

2_rt_eval

  • SeeQueue
  • CreateTicket

This basically works, but when a user logs in he finds an empty RT at a glance page.
But searching for his email address gives the expected results.
So my only problem is that the Queue is not displayed in the Quicksearch.
After a lot of searching in the mailing list archives I got some hints.

I applied the following rights additionally:

System groups

Privileged:

  • SeeQueue
  • CreateTicket
  • ShowTicket

After login the Quicksearch is populated with that queue but all tickets are shown.
So I removed the ShowTicket right from Privileged (while the user is still logged in). After a reload of the RT at a glance page the user sees the queue in the quicksearch. Following the link shows the correct tickets (the ticket count is wrong but this doesn’t matter).

Everything fine so far, but when the user logs out and in again Quicksearch is empty again. This is fully reproducible.

Do I miss something here or is this a bug?

Sounds like it, but to be sure clean all sessions in the DB.

Thanks for any help!

Best regards, Ruslan.

Markus,

Not wanting to sound critical or anything, it sounds like you’re going the
long way around the barn on this workflow.

First, why do you want two different groups working on basically the same
ticket?

Second, if these two groups must work in sync with each other on the same
ticket, why create a child? why not a “dependsOn” or “ReferrsTo” ticket.

Third, if people are forgetting to write replies, why not send a
notification template based on the same condition you use when you create
that “other” ticket?

Forth, if these two groups do NOT have to work on the same ticket at the
same time
, but follow a consecutive ownership type flow, then just change
the Queue after one group is finished with their work and while doing that,
change the owner to “Nobody” and the status and anything else you need when
you change the Queue?

Anyway, to be able to really assist, I would need to understand your
workflow; the why’s and wherefores. There’s always more than one way to skin
the cat.

Hope this helps.

Kenn
LBNLOn Wed, May 12, 2010 at 2:38 AM, Markus.Kummer@t-systems.com wrote:

Hi Ken ,hi Ruslan,

thank you for your advice.

I know that my rights config seems to be unlogical, so let me explain why I
started like this.

At the moment we have two departments working on incident reports in two
queues. Both departments cannot see the other departments queue. Sometimes
Dep. A needs to give a ticket to dep. B. In this case we follow a special
workflow to realize that (Scrips).
Dep. A change the status of a ticket in their queue to “ext” and write a
reply. This procedure creates a “child” ticket in the Queue of dep B. Then
Dep B works on that ticket. Some activities in the dep B queue cause a
syncronization with the ticket in the queue of dep A. After the ticket is
“resolved” in dep B the status of the parent ticket in queue of dep A is set
to “fixed” and the workflow ends.
This workflow causes a lot of confusion for the users. They forget to write
a reply after changing the status to “ext” and so on.
To make it more simple we want to merge the two queues and find another way
to seperate the tickets of the two departments.

What I posted before was the “first try”. The intention is that the two
departments get exactly one requestor for each queue. So they have to log in
as those requestors to see all their tickets. If dep A wants to give a
ticket to dep B it just change the requestor to the one of dep B.

In the second step I want to give rights to the owners of the tickets too.
Then the “requestor of dep B” changes the owner to the one who has to work
on that ticket. So if an owner logs in he sees all the tickets he has to
work on.

Maybe this is the wrong way but I don’t know what else to do.

Ken wrote:

You granted some rights to Privileged and then granted the same rights
again to a couple groups.
The rights for Privileged I just applied because it was adviced in a post
to see the Queue in Quicksearch. Actually I don’t want rights for privileged
users.

Ruslan wrote:

Sounds like it, but to be sure clean all sessions in the DB.
Same behaviour after cleaning all sessions.

Best regards,

Markus

T-Systems International GmbH
SDU Telco NPS
Vorgebirgsstr. 49
53119 Bonn
Tel: + 49 228 9841 3820
E-Mail: markus.kummer@t-systems.com

T-Systems International GmbH
Aufsichtsrat: René Obermann (Vorsitzender)
Geschäftsführung: Reinhard Clemens (Vorsitzender), Dr. Ferri Abolhassan,
Olaf Heyden, Joachim Langmack, Dr. Matthias Schuster, Klaus Werner
Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der
Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644

-----Ursprüngliche Nachricht-----
Von: ruslan.zakirov@gmail.com [mailto:ruslan.zakirov@gmail.com] Im Auftrag
von Ruslan Zakirov
Gesendet: Dienstag, 11. Mai 2010 21:18
An: Kummer, Markus
Cc: rt-users@lists.bestpractical.com
Betreff: Re: [rt-users] Problems with permissions (bug?)

On Tue, May 11, 2010 at 8:47 PM, Markus.Kummer@t-systems.com wrote:

Dear list,

I’m using rt 3.8.8 and facing problems in setting up permissions for a
queue.

What I want is that users see the tickets they have requested in a
certain queue only.
So user A cannot see tickets requested by user B and vice versa.

So I applied the following rights

→ Configuration → Queues → Group rights

Roles

Requestor:

  • CommentOnTicket

Do you really want requestors to comment and see comments?

  • DeleteTicket
  • ForwardMessage
  • ModifyCustomField
  • ModifyTicket
  • OwnTicket

Requestor can own a ticket? Wierd.

  • ReplyToTicket
  • SeeCustomField
  • ShowOutgoingEmail
  • ShowTicket
  • ShowTicketComments
  • StealTicket
  • TakeTicket

This is wierd as well as OwnTicket.

  • Watch
  • WatchAsAdminCc

This is something wierd too.

User defined groups

1_rt_eval

  • SeeQueue
  • CreateTicket

2_rt_eval

  • SeeQueue
  • CreateTicket

This basically works, but when a user logs in he finds an empty RT at a
glance page.
But searching for his email address gives the expected results.
So my only problem is that the Queue is not displayed in the Quicksearch.
After a lot of searching in the mailing list archives I got some hints.

I applied the following rights additionally:

System groups

Privileged:

  • SeeQueue
  • CreateTicket
  • ShowTicket

After login the Quicksearch is populated with that queue but all tickets
are shown.
So I removed the ShowTicket right from Privileged (while the user is
still logged in). After a reload of the RT at a glance page the user sees
the queue in the quicksearch. Following the link shows the correct tickets
(the ticket count is wrong but this doesn’t matter).

Everything fine so far, but when the user logs out and in again
Quicksearch is empty again. This is fully reproducible.

Do I miss something here or is this a bug?

Sounds like it, but to be sure clean all sessions in the DB.

Thanks for any help!


Best regards, Ruslan.

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com