Allowing a 'group' of customers to see certain tickets in a queue

Jeremy_Doran · April 24, 2003, 12:06am

In our support setup, a ‘customer’ is defined as a company, which can
have multiple points of contact (ie, multiple users each with their own
email addresses)

We already have RT3 working so that the requestor of the ticket can only
see the tickets they requested. What we now need to have is the ability
for a user who is from the same company (‘customer’ for us) to be able
to see the tickets that another user from the same ‘customer’ sent in.

To break it down to a simple example.

User_A is user_a@company1.com
User_B is user_b@company1.com
User_C is c_user@another_company.com

User_A sends in a ticket - #1
User_C sends in a ticket - #2
User_B sends in a ticket - #3

Both User_A and User_B should be able to see ticket #1 and ticket #3 but
not ticket #2.

User_C should be able to see ticket #2, but not tickets #1 and #3.

Is this possible to do with RT3, and if so, how does one do it?

Thanks,
Jeremy Doran fox-rt_users@vulpes.net

James_Goss · April 28, 2003, 4:38pm

I would really like to see this as well. There is no
clean way to do it - though someone once sent me a
patch they had whipped up to achieve similar
functionality. Some other things to do:

Create a separate queue for each user then give
them rights to see all tickets in that queue
- I don’t like this but may consider it when I
  apply a previous change someone else provided a while
  ago to remove the Configuration tab from the menu of
  privileged users.
- I don’t want customers to even be able to see
  the config or other customer names, etc.
Write a custom scrip to keep track of which users
are part of which groups, then when a request comes
from a user in a given group, assign other members of
that group to the ticket as requestors as well.
- I haven’t done this since I don’t know how
  custom scrips are written in 3.0 and am not a major
  perl guy to figure out how to do it on my own.

Jim— Jeremy Doran fox-rt_users@vulpes.net wrote:

In our support setup, a ‘customer’ is defined as a
company, which can
have multiple points of contact (ie, multiple users
each with their own
email addresses)

We already have RT3 working so that the requestor of
the ticket can only
see the tickets they requested. What we now need to
have is the ability
for a user who is from the same company (‘customer’
for us) to be able
to see the tickets that another user from the same
‘customer’ sent in.

To break it down to a simple example.

User_A is user_a@company1.com
User_B is user_b@company1.com
User_C is c_user@another_company.com

User_A sends in a ticket - #1
User_C sends in a ticket - #2
User_B sends in a ticket - #3

Both User_A and User_B should be able to see ticket
#1 and ticket #3 but
not ticket #2.

User_C should be able to see ticket #2, but not
tickets #1 and #3.

Is this possible to do with RT3, and if so, how does
one do it?

Thanks,

Jeremy Doran fox-rt_users@vulpes.net

rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at
http://fsck.com/rtfm

Jeremy_Doran · May 9, 2003, 5:50pm

I would really like to see this as well. There is no
clean way to do it - though someone once sent me a
patch they had whipped up to achieve similar
functionality. Some other things to do:

Create a separate queue for each user then give
them rights to see all tickets in that queue

I don’t like this but may consider it when I
apply a previous change someone else provided a while
ago to remove the Configuration tab from the menu of
privileged users.

I don’t want customers to even be able to see
the config or other customer names, etc.

Since this is for our main support queue, splitting out that queue into
lots of little queues would be a major PITA.

Write a custom scrip to keep track of which users
are part of which groups, then when a request comes
from a user in a given group, assign other members of
that group to the ticket as requestors as well.

I haven’t done this since I don’t know how
custom scrips are written in 3.0 and am not a major
perl guy to figure out how to do it on my own.

I guess that is the current fall-back option, but I really dislike this
for the reason that User_B from company1.com might be User_A’s manager,
and only wish to look at the queue to get a status of tickets, and not
want to get bombarded with the entire conversation about that ticket.

When I looked at RT3 a little more closely this past week, I did notice
the concept of “Personal Groups” and users being able to delegate rights
to members of that group. Unfortunately, either I’m missing something or
I cannot get this to do what I described before.

It would be exceedingly cool if I could put User_B into a personal group
for User_A, and have User_B automagically able to see User_A’s tickets.
But, if I grant User_A ShowTickets, then they are able to see all the
tickets - even the ones that are not their own, which is certainly not
what we want.

So, am I missing something here with Personal Groups, and if so, can I
use them to do what I described?

Thanks,> — Jeremy Doran fox-rt_users@vulpes.net wrote:

In our support setup, a ‘customer’ is defined as a
company, which can
have multiple points of contact (ie, multiple users
each with their own
email addresses)

We already have RT3 working so that the requestor of
the ticket can only
see the tickets they requested. What we now need to
have is the ability
for a user who is from the same company (‘customer’
for us) to be able
to see the tickets that another user from the same
‘customer’ sent in.

To break it down to a simple example.

User_A is user_a@company1.com
User_B is user_b@company1.com
User_C is c_user@another_company.com

User_A sends in a ticket - #1
User_C sends in a ticket - #2
User_B sends in a ticket - #3

Both User_A and User_B should be able to see ticket
#1 and ticket #3 but
not ticket #2.

User_C should be able to see ticket #2, but not
tickets #1 and #3.

Is this possible to do with RT3, and if so, how does
one do it?

Jeremy Doran fox-rt_users@vulpes.net

Oliver_Marx · March 25, 2004, 4:57pm

We have a problem with RT:

So we did the Google dance and found a perfect description of the
problem:

http://lists.fsck.com/pipermail/rt-users/2003-May/013875.html

Is there a solution? Is it the personal groups?
We tried reading the help pages…without luck…

Thx for your time and help.

\Oliver

Oliver_Marx · March 26, 2004, 10:50am

Dear List,

We have the following problem:

User_A is user_a@company1.com
User_B is user_b@company1.com
User_C is c_user@another_company.com

User_A sends in a ticket - #1
User_C sends in a ticket - #2
User_B sends in a ticket - #3

Both User_A and User_B should be able to see ticket
#1 and ticket #3 but not ticket #2.

User_C should be able to see ticket #2, but not
tickets #1 and #3.

Is this possible to do with RT3, and if so, how does one do it?

\Oliver

Ruslan_U_Zakirov · March 26, 2004, 11:08am

Oliver Marx wrote:

Dear List,

We have the following problem:

User_A is user_a@company1.com
User_B is user_b@company1.com
User_C is c_user@another_company.com

User_A sends in a ticket - #1
User_C sends in a ticket - #2
User_B sends in a ticket - #3

Both User_A and User_B should be able to see ticket
#1 and ticket #3 but not ticket #2.

User_C should be able to see ticket #2, but not
tickets #1 and #3.

Yes this is possible. ACL scheme give you ability to implement it, but
may be different solutions. I can imagine one:
1)
Write small script which automaticaly create groups by user’s domains,
something like:
Create group ‘company1_com’
Select users where emailaddress =~ /^[1]+@company1.com$/
For each user from select
add user into group ‘company1_com’.

Write scrip which on create add such “domain” group as ticket cc
watcher. choose “domain” group by requestor domain.

Grand wished rights to cc watchers role. Vualya. Magic. This work.

May be personal groups. I don’t use it. And don’t know features a lot.

^@ ↩︎

Paulo_Matos · March 26, 2004, 5:04pm

We have the following problem:

User_A is user_a@company1.com
User_B is user_b@company1.com
User_C is c_user@another_company.com

User_A sends in a ticket - #1
User_C sends in a ticket - #2
User_B sends in a ticket - #3

Both User_A and User_B should be able to see ticket
#1 and ticket #3 but not ticket #2.

User_C should be able to see ticket #2, but not
tickets #1 and #3.

Is this possible to do with RT3, and if so, how does one do it?

Let’s assume the following:

You have 3 queues: 1 general, 1 for company1 and 1 for company2

Create groups: ‘company1’ and ‘company2’
Assign users to corresponding group
Then on Queuel config level give group permissions ‘SeeQueue’ to the
corresponding group (i.e. queue ‘company1’ → group ‘company1’ →
SeeQueue)

Of course that requests have to reach the right queue.

Does this strategy solve your problem?

Paulo Matos

Oliver_Marx · March 26, 2004, 7:41pm

We have the following problem:

User_A is user_a@company1.com
User_B is user_b@company1.com
User_C is c_user@another_company.com

User_A sends in a ticket - #1
User_C sends in a ticket - #2
User_B sends in a ticket - #3

Both User_A and User_B should be able to see ticket
#1 and ticket #3 but not ticket #2.

User_C should be able to see ticket #2, but not
tickets #1 and #3.

s this possible to do with RT3, and if so, how does one do it?

Let’s assume the following:

You have 3 queues: 1 general, 1 for company1 and 1 for company2

Create groups: ‘company1’ and ‘company2’
Assign users to corresponding group
Then on Queuel config level give group permissions ‘SeeQueue’ to the
corresponding group (i.e. queue ‘company1’ → group ‘company1’ →
SeeQueue)

Of course that requests have to reach the right queue.

Does this strategy solve your problem?

We have more than 100 customers. That would give us alot of queues.
And that does not seem to be in the spirit of RT3.

Today we have:

Sales
Project
Invoice
Support

It would be nice if it some how would be possible to grant a
group_view_right and connect tickets to a group.

We would be willing to co-sponsor such a feature.

\Oliver

Alan_Barrett · March 27, 2004, 11:28am

User_A is user_a@company1.com
User_B is user_b@company1.com
User_C is c_user@another_company.com

User_A sends in a ticket - #1
User_C sends in a ticket - #2
User_B sends in a ticket - #3

Both User_A and User_B should be able to see ticket
#1 and ticket #3 but not ticket #2.

User_C should be able to see ticket #2, but not
tickets #1 and #3.

I also have this desire. And I do not want to use a separate queue
per customer. At present, I use the work-around described at
URL:http://marc.free.net.ph/message/20031007.091742.fa8f2674.html, but
it doesn’t work very well, requires an extra RT user with a password
that is shared between multiple users at the same customer site, and
requires tedious editing of scrips every time a new such group is added.

It would be nice if it some how would be possible to grant a
group_view_right and connect tickets to a group.

Yes, and it would be nice if it didn’t need scrips.

Imagine that it was possible to grant rights to “Users in same group as
Requestor” and “Users in same group as CC”, in much the same way as one
currently grants rights to “Requestor” and “CC”. To prevent the “Everyone”
group from being considered for such rights, each group could have a flag
saying whether or not such rights would apply to this group.

Then you’d do this:

Create a group for “customer-1”, and set the “allow rights for
users in same group” flag on this group.
Add “user-a@customer-1” and “user-b@customer-1” to the “customer-1”
group.
Grant rights like See Queue, View Ticket, Update Ticket, to
“Requestor” as usual. Also grant those rights (or perhaps only
the view rights, not the update rights) to “Users in same group as
Requestor”.

For efficiency, the implementation would probably have to keep a cache
of all user-pairs that have the in-same-group property.

–apb (Alan Barrett)

Todd_Chapman · March 28, 2004, 1:37am

Just create a scrip that when a ticket is created, find out what
UserDefined group the requestor belongs to and adds that
group as a Cc watcher. Then give the Cc system group the
rights you desire. Easy!On Sat, Mar 27, 2004 at 01:28:50PM +0200, Alan Barrett wrote:

On Fri, 26 Mar 2004, Oliver Marx wrote:

User_A is user_a@company1.com
User_B is user_b@company1.com
User_C is c_user@another_company.com

User_A sends in a ticket - #1
User_C sends in a ticket - #2
User_B sends in a ticket - #3

Both User_A and User_B should be able to see ticket
#1 and ticket #3 but not ticket #2.

User_C should be able to see ticket #2, but not
tickets #1 and #3.

I also have this desire. And I do not want to use a separate queue
per customer. At present, I use the work-around described at
URL:http://marc.free.net.ph/message/20031007.091742.fa8f2674.html, but
it doesn’t work very well, requires an extra RT user with a password
that is shared between multiple users at the same customer site, and
requires tedious editing of scrips every time a new such group is added.

It would be nice if it some how would be possible to grant a
group_view_right and connect tickets to a group.

Yes, and it would be nice if it didn’t need scrips.

Imagine that it was possible to grant rights to “Users in same group as
Requestor” and “Users in same group as CC”, in much the same way as one
currently grants rights to “Requestor” and “CC”. To prevent the “Everyone”
group from being considered for such rights, each group could have a flag
saying whether or not such rights would apply to this group.

Then you’d do this:

Create a group for “customer-1”, and set the “allow rights for
users in same group” flag on this group.

Add “user-a@customer-1” and “user-b@customer-1” to the “customer-1”
group.

Grant rights like See Queue, View Ticket, Update Ticket, to
“Requestor” as usual. Also grant those rights (or perhaps only
the view rights, not the update rights) to “Users in same group as
Requestor”.

For efficiency, the implementation would probably have to keep a cache
of all user-pairs that have the in-same-group property.

–apb (Alan Barrett)

rt-users mailing list
rt-users@lists.bestpractical.com
The rt-users Archives

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Alan_Barrett · March 29, 2004, 2:01pm

Just create a scrip that when a ticket is created, find out what
UserDefined group the requestor belongs to and adds that group as a Cc
watcher. Then give the Cc system group the rights you desire. Easy!

How do you add a group as a CC? I thought that only users could be CCs.
The web interface for adding watchers to a ticket (open the ticket,
click “people”) wants an email address.

–apb (Alan Barrett)

Todd_Chapman · March 29, 2004, 3:16pm

Click people.
Use the find group search box to find a group.
Add group as Cc.
Smack forhead.On Mon, Mar 29, 2004 at 04:01:21PM +0200, Alan Barrett wrote:

On Sat, 27 Mar 2004, Todd Chapman wrote:

Just create a scrip that when a ticket is created, find out what
UserDefined group the requestor belongs to and adds that group as a Cc
watcher. Then give the Cc system group the rights you desire. Easy!

How do you add a group as a CC? I thought that only users could be CCs.
The web interface for adding watchers to a ticket (open the ticket,
click “people”) wants an email address.

–apb (Alan Barrett)

rt-users mailing list
rt-users@lists.bestpractical.com
The rt-users Archives

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Sebastien_Person · March 31, 2004, 7:58am

Just create a scrip that when a ticket is created, find out what
UserDefined group the requestor belongs to and adds that
group as a Cc watcher. Then give the Cc system group the
rights you desire. Easy!

Does all the users in the specified will receive all correspondences ?
Does the meaning of the CC group is the same as the CC tag used in
mail applications ? or it is only a generic group and we could
assign whatever rights we choose … To make it clear, is there a
default or minimal right for the CC group ?