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 LBNL On Wed, Oct 26, 2011 at 4:01 AM, Richard Clark <[email protected]> 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 > [email protected] > > -----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 >
-------- RT Training Sessions (http://bestpractical.com/services/training.html) * Washington DC, USA October 31 & November 1, 2011 * Barcelona, Spain November 28 & 29, 2011
