Private Groups in RT v4.0.x or equivalent?

David6 · October 25, 2011, 10:40pm

Hi, I have a group of staff in a department that want to collaborate on some ticket(s) resolution. I
was going to add a generic user, create a private group and add the particular staff to that private
group. Ownership of any tickets that are going to be collaborated on would be given to the generic
user. But I can’t find private groups in the new install of RT 4.0.2. Until very recently we have
been using 3.6 so I’ve lost my way.

Is there a better method than the one I was going to use? I’m guessing that private groups has been
depreciated in RT v4, if so is there an equivalent?

Thanks.

David.

Carlos_Garcia_Montor · October 26, 2011, 10:30am

As far as I know, I have never seen something like “private” groups
since we began using RT with version 3.8.x On the other hand you have
groups in which you can add the users you want.

I would advice you to create a group with proper privileges and to add
in this group the users you need, instead of create a generic user and
spread credentials. If you do what you propose, you cannot know who has
done what, and every time you need to remove a user from this generic
group, you will need to change its password and distribute the new one
to all the users.

Hope this helps. Regards,
Carlos

David escribiï¿½:

Hi, I have a group of staff in a department that want to collaborate
on some ticket(s) resolution. I was going to add a generic user,
create a private group and add the particular staff to that private
group. Ownership of any tickets that are going to be collaborated on
would be given to the generic user. But I can’t find private groups in
the new install of RT 4.0.2. Until very recently we have been using
3.6 so I’ve lost my way.

Is there a better method than the one I was going to use? I’m guessing
that private groups has been depreciated in RT v4, if so is there an
equivalent?

Thanks.

David.

RT Training Sessions (http://bestpractical.com/services/training.html)

Washington DC, USA October 31 & November 1, 2011

Barcelona, Spain November 28 & 29, 2011

| __ __ | Carlos Garcï¿½a Montoro Ingeniero Informï¿½tico
|_Y/| Instituto de Fï¿½sica Corpuscular Centro Mixto CSIC - UV
|_] [/| CPAN www.i-cpan.es
| [] | Edificio Institutos de Investigaciï¿½n webmaster@i-cpan.es
|C S I C| Apartado de Correos 22085 E-46071 Valencia Tel:+34 963543706
|______| Espaï¿½a / Spain Fax:+34 963543488

cgarcia.vcf (449 Bytes)

Richard_Clark · October 26, 2011, 11:01am

As far as I know, I have never seen something like “private” groups
since we began using RT with version 3.8.x On the other hand you
have groups in which you can add the users you want.

I would advice you to create a group with proper privileges and to
add in this group the users you need, instead of create a generic
user and spread credentials. If you do what you propose, you cannot
know who has done what, and every time you need to remove a user
from this generic group, you will need to change its password and
distribute the new one to all the users.

Hope this helps. Regards,
Carlos

David escribió:

Hi, I have a group of staff in a department that want to
collaborate on some ticket(s) resolution. I was going to add a
generic user, create a private group and add the particular staff
to that private group. Ownership of any tickets that are going to
be collaborated on would be given to the generic user. But I can’t
find private groups in the new install of RT 4.0.2. Until very
recently we have been using 3.6 so I’ve lost my way.

Is there a better method than the one I was going to use? I’m
guessing that private groups has been depreciated in RT v4, if so
is there an equivalent?

Thanks.

David.

What I do is create a group as normal with appropriate permissions - membership
of this group is populated using a script, from an LDAP group in our
directory that corresponds to this group.

I then create a virtual user within RT that is also a member of this
group. This user has no password and is never used to log in via the web
interface - the email address corresponding to that user goes to a group
email address, and so gets sent to all users within that LDAP group.

Therefore, when a ticket gets assigned to the virtual group user,
everyone in that group gets notifications and sees email threads as
normal.

Users within the group can steal it from the virtual group user as
normal, or they can have a workflow where it stays owned by that virtual
user and they only need to steal it upon closure.

One consideration with this approach is that some scrips may need
updating to avoid duplicate email notifications (one received via the virtual group user, another received as an adminCC).

There are a couple of ways of achieving this - we have a standard naming
convention for these virtual group users, so we just need a simple regex
matching this in instances where we need to avoid duplicate mails going
out.

Richard Clark
richard@fohnet.co.uk

signature.asc (198 Bytes)

Kenn_Crocker · October 26, 2011, 3:50pm

Richard,

All of this can be done without the need of the virtual user. It seems
redundant to me. Emails can be sent to all members of a group, all members
can steal without the need of a virtual user.

Kenn
LBNLOn Wed, Oct 26, 2011 at 4:01 AM, Richard Clark noc@fohnet.co.uk wrote:

On Wed, Oct 26, 2011 at 12:30:20PM +0200, Carlos Garcia Montoro wrote:

As far as I know, I have never seen something like “private” groups
since we began using RT with version 3.8.x On the other hand you
have groups in which you can add the users you want.

I would advice you to create a group with proper privileges and to
add in this group the users you need, instead of create a generic
user and spread credentials. If you do what you propose, you cannot
know who has done what, and every time you need to remove a user
from this generic group, you will need to change its password and
distribute the new one to all the users.

Hope this helps. Regards,
Carlos

David escribió:

Hi, I have a group of staff in a department that want to
collaborate on some ticket(s) resolution. I was going to add a
generic user, create a private group and add the particular staff
to that private group. Ownership of any tickets that are going to
be collaborated on would be given to the generic user. But I can’t
find private groups in the new install of RT 4.0.2. Until very
recently we have been using 3.6 so I’ve lost my way.

Is there a better method than the one I was going to use? I’m
guessing that private groups has been depreciated in RT v4, if so
is there an equivalent?

Thanks.

David.

What I do is create a group as normal with appropriate permissions -
membership
of this group is populated using a script, from an LDAP group in our
directory that corresponds to this group.

I then create a virtual user within RT that is also a member of this
group. This user has no password and is never used to log in via the web
interface - the email address corresponding to that user goes to a group
email address, and so gets sent to all users within that LDAP group.

Therefore, when a ticket gets assigned to the virtual group user,
everyone in that group gets notifications and sees email threads as
normal.

Users within the group can steal it from the virtual group user as
normal, or they can have a workflow where it stays owned by that virtual
user and they only need to steal it upon closure.

One consideration with this approach is that some scrips may need
updating to avoid duplicate email notifications (one received via the
virtual group user, another received as an adminCC).

There are a couple of ways of achieving this - we have a standard naming
convention for these virtual group users, so we just need a simple regex
matching this in instances where we need to avoid duplicate mails going
out.

–
Richard Clark
richard@fohnet.co.uk

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk6n6I8ACgkQp6c03gd+P7/1GgCgqbdZDTaHYUsewgmuXzs36IkA
YKAAn2sm3CuC8GeiMSWKfibbVz7I+mxR
=kuiP
-----END PGP SIGNATURE-----

RT Training Sessions (http://bestpractical.com/services/training.html)

Washington DC, USA — October 31 & November 1, 2011

Barcelona, Spain — November 28 & 29, 2011

Kevin_Falcone · October 26, 2011, 9:56pm

would be given to the generic user. But I can’t find private groups
in the new install of RT 4.0.2. Until very recently we have been
using 3.6 so I’ve lost my way.

To be clear, we removed Delegations, which included Private Groups, in
RT4. The other correspondents in this thread have provided our normal
solutions, so I won’t repeat them.

-kevin

David6 · October 31, 2011, 9:57pm

Users within the group can steal it from the virtual group user as
normal, or they can have a workflow where it stays owned by that virtual
user and they only need to steal it upon closure.

Thanks for all the responses but I’m stuck with “stealing”.

I’ve gone “configure queues”, “group rights”, selected the group and under “rights for staff” have
enabled “steal ticket”. But when I log in as a user in that group and try to take ownership of a
ticket owned by the virtual user I get “you can only take tickets that are unowned”.

I’ve also tried granting “steal ticket” under global user rights but I get the same message.

Even as an admin user with with “do anything and everything” enabled when I try and reassign the
ticket I get “You can only reassign tickets that you own or that are unowned” ??

Any assistance will be greatly appreciated (before I loose all my hair).

Using RT 4.0.2

Thanks.

David.

David6 · October 31, 2011, 10:07pm

Thanks for all the responses but I’m stuck with “stealing”.

Please ignore, under “actions” I’ve found the option “steal”.

Thanks.

David.