Richard,<br><br>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.<br><br>Kenn<br>
LBNL<br><br><div class="gmail_quote">On Wed, Oct 26, 2011 at 4:01 AM, Richard Clark <span dir="ltr"><<a href="mailto:noc@fohnet.co.uk">noc@fohnet.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Wed, Oct 26, 2011 at 12:30:20PM +0200, Carlos Garcia Montoro wrote:<br>
> As far as I know, I have never seen something like "private" groups<br>
> since we began using RT with version 3.8.x On the other hand you<br>
> have groups in which you can add the users you want.<br>
><br>
> I would advice you to create a group with proper privileges and to<br>
> add in this group the users you need, instead of create a generic<br>
> user and spread credentials. If you do what you propose, you cannot<br>
> know who has done what, and every time you need to remove a user<br>
> from this generic group, you will need to change its password and<br>
> distribute the new one to all the users.<br>
><br>
> Hope this helps. Regards,<br>
> Carlos<br>
><br>
> David escribió:<br>
> ><br>
> >Hi, I have a group of staff in a department that want to<br>
> >collaborate on some ticket(s) resolution. I was going to add a<br>
> >generic user, create a private group and add the particular staff<br>
> >to that private group. Ownership of any tickets that are going to<br>
> >be collaborated on would be given to the generic user. But I can't<br>
> >find private groups in the new install of RT 4.0.2. Until very<br>
> >recently we have been using 3.6 so I've lost my way.<br>
> ><br>
> >Is there a better method than the one I was going to use? I'm<br>
> >guessing that private groups has been depreciated in RT v4, if so<br>
> >is there an equivalent?<br>
> ><br>
> >Thanks.<br>
> ><br>
> ><br>
> >David.<br>
> >--------<br>
<br>
</div></div>What I do is create a group as normal with appropriate permissions - membership<br>
of this group is populated using a script, from an LDAP group in our<br>
directory that corresponds to this group.<br>
<br>
I then create a virtual user within RT that is also a member of this<br>
group. This user has no password and is never used to log in via the web<br>
interface - the email address corresponding to that user goes to a group<br>
email address, and so gets sent to all users within that LDAP group.<br>
<br>
Therefore, when a ticket gets assigned to the virtual group user,<br>
everyone in that group gets notifications and sees email threads as<br>
normal.<br>
<br>
Users within the group can steal it from the virtual group user as<br>
normal, or they can have a workflow where it stays owned by that virtual<br>
user and they only need to steal it upon closure.<br>
<br>
One consideration with this approach is that some scrips may need<br>
updating to avoid duplicate email notifications (one received via the virtual group user, another received as an adminCC).<br>
<br>
There are a couple of ways of achieving this - we have a standard naming<br>
convention for these virtual group users, so we just need a simple regex<br>
matching this in instances where we need to avoid duplicate mails going<br>
out.<br>
<font color="#888888"><br>
<br>
--<br>
Richard Clark<br>
<a href="mailto:richard@fohnet.co.uk">richard@fohnet.co.uk</a><br>
</font><br>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.10 (GNU/Linux)<br>
<br>
iEYEARECAAYFAk6n6I8ACgkQp6c03gd+P7/1GgCgqbdZDTaHYUsewgmuXzs36IkA<br>
YKAAn2sm3CuC8GeiMSWKfibbVz7I+mxR<br>
=kuiP<br>
-----END PGP SIGNATURE-----<br>
<br>--------<br>
RT Training Sessions (<a href="http://bestpractical.com/services/training.html" target="_blank">http://bestpractical.com/services/training.html</a>)<br>
*  Washington DC, USA — October 31 & November 1, 2011<br>
*  Barcelona, Spain — November 28 & 29, 2011<br></blockquote></div><br>