Requester Groups

We’re beginning our first RT configuration. Everything is going very
well (and the documentation is great, btw).

I have run into one question. Our customers have multiple people within
their organization who contact us for requests. Sometimes it can become
unmanageable because User A and User B from the same organization ask
for something that they need done in the same time frame. Neither user
knows about the other request.

We want to set up RT such that each customer (e.g., ACME Company) has
both a queue and a group associated with it. We would then add all of
the users from that company to the group and the queue. The ideal
situation is that all employees of ACME Company can see the ACME queue
so they are aware of what their coworkers have requested.

The problem I’ve run into is that I can’t figure out how to let an
employee of ACME Company have the ability to see tickets in the ACME
queue that he or she didn’t create. The only way I’ve been able to do
it so far is to make the user privileged. However, it seems that RT
assumes that a privileged user is a staff person so they see things
like the amount of time that a request was worked on and other
information that a customer (or non-privileged user) shouldn’t see.

Am I missing something in the configuration? Is it possible to set it
up the way I describe so that employees of a customer company can see
the requests from other employees of the same company?

Thank You,

Jason

Jason Grigsby a écrit :

We’re beginning our first RT configuration. Everything is going very
well (and the documentation is great, btw).

I have run into one question. Our customers have multiple people
within their organization who contact us for requests. Sometimes it
can become unmanageable because User A and User B from the same
organization ask for something that they need done in the same time
frame. Neither user knows about the other request.

We want to set up RT such that each customer (e.g., ACME Company) has
both a queue and a group associated with it. We would then add all of
the users from that company to the group and the queue. The ideal
situation is that all employees of ACME Company can see the ACME queue
so they are aware of what their coworkers have requested.

The problem I’ve run into is that I can’t figure out how to let an
employee of ACME Company have the ability to see tickets in the ACME
queue that he or she didn’t create. The only way I’ve been able to do
it so far is to make the user privileged. However, it seems that RT
assumes that a privileged user is a staff person so they see things
like the amount of time that a request was worked on and other
information that a customer (or non-privileged user) shouldn’t see.

Am I missing something in the configuration? Is it possible to set it
up the way I describe so that employees of a customer company can see
the requests from other employees of the same company?

Try this :

  1. in the ACME queue configuration, add the group ACME company to the
    CC watchers,
  2. in the global configuration, add “ShowTicket” to right to CC role rights.

Be warned that this way, all ACME group members will receive a copy of
all correspondance of all tickets of the queue.

Alternatively, you can simply add “ShowTicket” to user defined group
“ACME company” rights in the ACME queue configuration. This should
avoid the mail “spamming”.

Guillaume Perréal.

Responsable informatique,
Cemagref, groupement de Lyon,
France.

Tél: (+33) 4.72.20.87.87.
Fax: (+33) 4.78.47.78.75.
Site: http://www.lyon.cemagref.fr/

Try this :

  1. in the ACME queue configuration, add the group ACME company to
    the CC watchers,
  2. in the global configuration, add “ShowTicket” to right to CC role rights.

Be warned that this way, all ACME group members will receive a copy
of all correspondance of all tickets of the queue.

they’ll only receive correspondance if that’s how the scrips are setup.

seph

Thank you for the response. After working on this a bit over the
weekend, I realized that the main problem I’m having is adding a user
to a group without making the user privileged (i.e., checking “Let this
user be granted rights” on the user’s account).

When I try to add users to a group, I only see privileged users. When
we make someone privileged, they see more options than I think they
should (e.g., Configuration, Approval, etc).

Is it possible to add someone to a group without making the user
privileged?

If it makes a difference, we’re running RT 3.03 until we get a Debian
Sarge server running so we can use 3.08.

Thank You,

JasonOn Feb 6, 2004, at 5:03 PM, Guillaume Perréal wrote:

Jason Grigsby a écrit :

We’re beginning our first RT configuration. Everything is going very
well (and the documentation is great, btw).

I have run into one question. Our customers have multiple people
within their organization who contact us for requests. Sometimes it
can become unmanageable because User A and User B from the same
organization ask for something that they need done in the same time
frame. Neither user knows about the other request.

We want to set up RT such that each customer (e.g., ACME Company) has
both a queue and a group associated with it. We would then add all of
the users from that company to the group and the queue. The ideal
situation is that all employees of ACME Company can see the ACME
queue so they are aware of what their coworkers have requested.

The problem I’ve run into is that I can’t figure out how to let an
employee of ACME Company have the ability to see tickets in the ACME
queue that he or she didn’t create. The only way I’ve been able to do
it so far is to make the user privileged. However, it seems that RT
assumes that a privileged user is a staff person so they see things
like the amount of time that a request was worked on and other
information that a customer (or non-privileged user) shouldn’t see.

Am I missing something in the configuration? Is it possible to set it
up the way I describe so that employees of a customer company can see
the requests from other employees of the same company?

Try this :

  1. in the ACME queue configuration, add the group ACME company to
    the CC watchers,
  2. in the global configuration, add “ShowTicket” to right to CC role
    rights.

Be warned that this way, all ACME group members will receive a copy
of all correspondance of all tickets of the queue.

Alternatively, you can simply add “ShowTicket” to user defined group
“ACME company” rights in the ACME queue configuration. This should
avoid the mail “spamming”.


Guillaume Perréal.

Responsable informatique,
Cemagref, groupement de Lyon,
France.

Tél: (+33) 4.72.20.87.87.
Fax: (+33) 4.78.47.78.75.
Site: http://www.lyon.cemagref.fr/

Is it possible to add someone to a group without making the user
privileged?

That’s what priviledged is defined to mean, “can be added to groups”

seph

Is it possible to add someone to a group without making the user
privileged?

That’s what priviledged is defined to mean, “can be added to groups”

Ok, so you can’t add a user to a group without making them privileged.
Should customers be privileged then? It seems that privileged means
more than just being able to access a group. It also means that the
user can see the configuration menu and see all of the users and groups
(not to mention, the approval menu and other options that a customer
shouldn’t see).

The RT Draft Manual says:

“Let this user be granted rights checkbox: This is unchecked by
default. Check the box to make this a staff user.”

This makes it sound like RT isn’t intended to allow customers to be
assigned to groups (if you can’t assign them to groups without making
the user privileged).

Is it common for people to use groups to organize customers within RT?

-Jason

The more I play with RT, the more I’m beginning to fear that RT won’t
do what work for what we need (the ability to let multiple users for a
single customer see all of the tickets in the customer’s queue but none
of the other queues). I did see a contribution that attempts to solve a
similar problem:

http://download.bestpractical.com/pub/rt/contrib/2.0/GroupService.README

Has anyone attempted to use that contribution with the 3.0 version of
RT?

-JasonOn Feb 9, 2004, at 10:27 AM, Jason Grigsby wrote:

On Feb 9, 2004, at 10:04 AM, seph wrote:

Is it possible to add someone to a group without making the user
privileged?

That’s what priviledged is defined to mean, “can be added to groups”

Ok, so you can’t add a user to a group without making them privileged.
Should customers be privileged then? It seems that privileged means
more than just being able to access a group. It also means that the
user can see the configuration menu and see all of the users and
groups (not to mention, the approval menu and other options that a
customer shouldn’t see).

The RT Draft Manual says:

“Let this user be granted rights checkbox: This is unchecked by
default. Check the box to make this a staff user.”

This makes it sound like RT isn’t intended to allow customers to be
assigned to groups (if you can’t assign them to groups without making
the user privileged).

Is it common for people to use groups to organize customers within RT?

-Jason


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

seph seph@directionless.org writes:

Is it possible to add someone to a group without making the user
privileged?
That’s what priviledged is defined to mean, “can be added to groups”

Eh? From a) my understanding of the word and b) the way RT handles
users by default “privileged” means “may be granted rights” (and,
incidentally, "will be shown the standard interface instead of
SelfService).

To answer the original question:

copy </path/to/rt3>/share/html/Admin/Elements/SelectNewGroupMembers to
</path/to/rt3>/local/html/Admin/Elements/SelectNewGroupMembers (you
may have to create the path) and comment out the line:

$users->LimitToPrivileged();

This lets you add unprivileged users to groups.

We use this to control queue access for our customers, but we haven’t
yet implemented a way to let all users at a customer see all tickets
requested by that customer (as we haven’t really had a need to).

Espen Wiborg espenhw@empolis.no
There are more chickens than people in the world.