Grouping requestors by organisation?

Hi,

I’d like to be able to somehow group RT users from the same organisation so
that they can see other tickets opened by their organisation - is there a
nice built-in way to this? I guess the alternative is to somehow force the
requestor address to known one, but our customer’s get confused enough
about corresponding via RT as it is :slight_smile:

Does anyone already do something like this?

Best Regards,

Howard

Step one is to put all the users from the same organization
in the same RT group.

Two, if you can create one queue per organization then
create the queue.

Three, give the group the proper permissions on the queue.

If tickets from different organization need to be in the same
queue you will need to make the group an AdminCc on a per
ticket basis, which is either manual or could be automated
with a scrip. Then give the role AdminCc the desired permissions.

-ToddOn Wed, Nov 03, 2004 at 04:01:00PM -0000, Howard Jones wrote:

Hi,

I’d like to be able to somehow group RT users from the same organisation so
that they can see other tickets opened by their organisation - is there a
nice built-in way to this? I guess the alternative is to somehow force the
requestor address to known one, but our customer’s get confused enough
about corresponding via RT as it is :slight_smile:

Does anyone already do something like this?

Best Regards,

Howard


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

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

Ah - I should have specified a bit better :slight_smile:

We already have queues based on product line, and a single e-mail address to
feed them - mail goes into the General queue and gets sorted by us into the
right queue. What I’m really after is some way to either manually tag
existing users as being related and able to see each other’s tickets, or to
look up the user in an external database, and then do the same.

The ultimate aim is to have Company X users be able to log in to a portal of
some sort and see information from other sources, along with a list of ‘Your
open RT tickets’ that includes their colleagues tickets. I’m hoping that
external auth will do part of that, but I don’t think it will do the
group-access part.

Regards,

HowardFrom: “Todd Chapman” rt@chaka.net
To: “Howard Jones” howard.jones@network-i.net
Cc: rt-users@lists.bestpractical.com
Sent: Wednesday, November 03, 2004 8:48 PM
Subject: Re: [rt-users] Grouping requestors by organisation?

Step one is to put all the users from the same organization
in the same RT group.

Two, if you can create one queue per organization then
create the queue.

Three, give the group the proper permissions on the queue.

If tickets from different organization need to be in the same
queue you will need to make the group an AdminCc on a per
ticket basis, which is either manual or could be automated
with a scrip. Then give the role AdminCc the desired permissions.

-Todd

Hi,

I’d like to be able to somehow group RT users from the same organisation
so

that they can see other tickets opened by their organisation - is there
a

nice built-in way to this? I guess the alternative is to somehow force
the

requestor address to known one, but our customer’s get confused enough
about corresponding via RT as it is :slight_smile:

Does anyone already do something like this?

Best Regards,

Howard


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

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

Then you need a scrip that will add the appropriate group as
an AdminCc to the ticket. Can it be safely said that each
user will only belong to one group?On Thu, Nov 04, 2004 at 09:49:50AM -0000, Howard Jones wrote:

Ah - I should have specified a bit better :slight_smile:

We already have queues based on product line, and a single e-mail address to
feed them - mail goes into the General queue and gets sorted by us into the
right queue. What I’m really after is some way to either manually tag
existing users as being related and able to see each other’s tickets, or to
look up the user in an external database, and then do the same.

The ultimate aim is to have Company X users be able to log in to a portal of
some sort and see information from other sources, along with a list of ‘Your
open RT tickets’ that includes their colleagues tickets. I’m hoping that
external auth will do part of that, but I don’t think it will do the
group-access part.

Regards,

Howard