Having multiple users logically linked together by "organization"

I’m hoping that someone else out there might have the same requirements as I
do and has found a way to satisfy them.

I’d like to have things set up such that multiple users can all be logically
linked together by their company/organization. In doing so, I’d like all
tickets created by one user who is a member of a particular organization to
be viewable by all other members of that organization.

If that’s not clear enough, here is a for-instance:

Let’s say I have two clients - Client A and Client B. I have 4 users set up
in RT:

Users bob and john are employees of Client A
Users joe and tom are employees of Client B

If user bob creates a ticket, I’d like for john to be able to see that
ticket when he logs in, but joe and tom cannot. If user joe creates a
ticket, tom can see it, but bob and john cannot.

I’m positive that there is a way to do this, since I haven’t found anything
that RT can’t do yet. I can think of one way which is writing a scrip that
adds all users that have the same organization value as the requestor to the
CC list of a ticket and then granting correct permissions to CCs, but that
just seems dirty and cumbersome.

Thanks a bunch.

Jonathan Reeder

Configure one queue per organization with proper access rights
for a corresponding group. Put the users in the appropriate groups.
Done.

-ToddOn Thu, Jan 20, 2005 at 12:43:14PM -0600, Jonathan Reeder wrote:

I’m hoping that someone else out there might have the same requirements as I
do and has found a way to satisfy them.

I’d like to have things set up such that multiple users can all be logically
linked together by their company/organization. In doing so, I’d like all
tickets created by one user who is a member of a particular organization to
be viewable by all other members of that organization.

If that’s not clear enough, here is a for-instance:

Let’s say I have two clients - Client A and Client B. I have 4 users set up
in RT:

Users bob and john are employees of Client A
Users joe and tom are employees of Client B

If user bob creates a ticket, I’d like for john to be able to see that
ticket when he logs in, but joe and tom cannot. If user joe creates a
ticket, tom can see it, but bob and john cannot.

I’m positive that there is a way to do this, since I haven’t found anything
that RT can’t do yet. I can think of one way which is writing a scrip that
adds all users that have the same organization value as the requestor to the
CC list of a ticket and then granting correct permissions to CCs, but that
just seems dirty and cumbersome.

Thanks a bunch.

Jonathan Reeder


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

RT Administrator and Developer training is coming to your town soon! (Boston, San Francisco, Austin, Sydney) Contact training@bestpractical.com for details.

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

Jonathan,

Jonathan Reeder wrote:

I’m hoping that someone else out there might have the same
requirements as I do and has found a way to satisfy them.

yes.

create one staff group for your staff

per client create this:

one queue
one group

put the client employees in the client group and give your staff group
and the client group the desired rights on the
client’s queue.

HTH,

Jan

I’d like to have things set up such that multiple users can all be
logically linked together by their company/organization. In doing so,
I’d like all tickets created by one user who is a member of a
particular organization to be viewable by all other members of that
organization.

If that’s not clear enough, here is a for-instance:

Let’s say I have two clients - Client A and Client B. I have 4 users
set up in RT:

Users bob and john are employees of Client A
Users joe and tom are employees of Client B

If user bob creates a ticket, I’d like for john to be able to see that
ticket when he logs in, but joe and tom cannot. If user joe creates a
ticket, tom can see it, but bob and john cannot.

I’m positive that there is a way to do this, since I haven’t found
anything that RT can’t do yet. I can think of one way which is
writing a scrip that adds all users that have the same organization
value as the requestor to the CC list of a ticket and then granting
correct permissions to CCs, but that just seems dirty and cumbersome.

Thanks a bunch.

Jonathan Reeder



http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

RT Administrator and Developer training is coming to your town soon! (Boston, San Francisco, Austin, Sydney) Contact training@bestpractical.com for details.

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

Jan Algermissen
Consultant & Programmer
http://jalgermissen.com

Flexible solution is not available now and wouldn’t be for some time. I
think “some” will end, if someone sponsor this because it’s not easy to
implement.

You want share rights that requestor has to group A if requestor is
member of the group A. Or in other words: you want to say all people in
group ‘G’ get the same rights on ticket ‘T’ in queue ‘Q’ as requestor
role gives to user if any user from group ‘G’ is requestor of the ticket
’T’. Then you create group ‘ClientA_Employees’ and 'ClientA_Employees’
give them such right on queue ‘ClientTickets’, gives ‘SeeTicket’ to
requestor role on the queue and all are happy and “they lived for a
long-long time”, but it’s not implemented :slight_smile:

So I’ll put it into WishList on wiki.

You can do next thing to simulate similar behaviour like I described above:
Create groups ClientA, ClientB…
Write scrip that OnCreate takes requestor, then finds its group, get all
members of that group and adds them as requestors(or as Cc) to ticket.

What do you think guys?

Yeah, people becomes requestors of the tickets that they didn’t request.

Then you should add WebUI feature that allow people to
unsubscribe(“remove me from requestors(Cc)”) in one click.

Enough?

Jonathan Reeder wrote:

Wow that sounds perfect to me. I think in the meantime I’m going to create
the scrip like you described.

BTW, thanks to everyone who replied to this query, I’ve gotten some helpful
tips.

Jonathan ReederFrom: Ruslan U. Zakirov [mailto:Ruslan.Zakirov@acronis.com]
Sent: Friday, January 21, 2005 3:01 PM
To: Jonathan Reeder
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Having multiple users logically linked together
by “organization”

Flexible solution is not available now and wouldn’t be for some time. I
think “some” will end, if someone sponsor this because it’s not easy to
implement.

You want share rights that requestor has to group A if requestor is
member of the group A. Or in other words: you want to say all people in
group ‘G’ get the same rights on ticket ‘T’ in queue ‘Q’ as requestor
role gives to user if any user from group ‘G’ is requestor of the ticket
’T’. Then you create group ‘ClientA_Employees’ and 'ClientA_Employees’
give them such right on queue ‘ClientTickets’, gives ‘SeeTicket’ to
requestor role on the queue and all are happy and “they lived for a
long-long time”, but it’s not implemented :slight_smile:

So I’ll put it into WishList on wiki.

You can do next thing to simulate similar behaviour like I described above:
Create groups ClientA, ClientB…
Write scrip that OnCreate takes requestor, then finds its group, get all
members of that group and adds them as requestors(or as Cc) to ticket.

What do you think guys?

Yeah, people becomes requestors of the tickets that they didn’t request.

Then you should add WebUI feature that allow people to
unsubscribe(“remove me from requestors(Cc)”) in one click.

Enough?

Jonathan Reeder wrote:

I’m hoping that someone else out there might have the same requirements
as I do and has found a way to satisfy them.

I’d like to have things set up such that multiple users can all be
logically linked together by their company/organization. In doing so,
I’d like all tickets created by one user who is a member of a particular
organization to be viewable by all other members of that organization.

If that’s not clear enough, here is a for-instance:

Let’s say I have two clients - Client A and Client B. I have 4 users
set up in RT:

Users bob and john are employees of Client A
Users joe and tom are employees of Client B

If user bob creates a ticket, I’d like for john to be able to see that
ticket when he logs in, but joe and tom cannot. If user joe creates a
ticket, tom can see it, but bob and john cannot.

I’m positive that there is a way to do this, since I haven’t found
anything that RT can’t do yet. I can think of one way which is writing
a scrip that adds all users that have the same organization value as the
requestor to the CC list of a ticket and then granting correct
permissions to CCs, but that just seems dirty and cumbersome.

Thanks a bunch.

Jonathan Reeder



http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

RT Administrator and Developer training is coming to your town soon!
(Boston, San Francisco, Austin, Sydney) Contact training@bestpractical.com
for details.

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

I guess there is a simpler solution to the requested functionality,
however I could not get it to work. In my case I have changed the
Selfservice site to contain not only tickets that I requested, but also
a section tickets that I watch. For that I changed to code to:

  • The titlte states “[status] tickets that I watch” in stead of “My
    ”[status] request"".

  • I have changed the line

    $MyTickets->LimitWatcher(TYPE =>‘Requestor’,VALUE =>
    $session{‘CurrentUser’}->EmailAddress);

into

$MyTickets->LimitWatcher(TYPE =>‘Cc’,VALUE =>
$session{‘CurrentUser’}->EmailAddress);

What I intended was the following, allow prime contacts of our customer
to be on the CC: list of the customer queue (we have our RT system
aranged so that we have queues per customer). I hoped that the
LimitWatchers (TYPE => ‘Cc’,… ) would also select tickets that are
indirectly, via the queue, CC-ed. but that does not seem to work. What
can I do to make that work?

I have issued the same request earlier with subject ( LimitWatchers to
check on Queue CC:) but got no response.

Kind regards,

Sytze Boonstra