[rt-users] Private Groups in RT v4.0.x or equivalent?

[Richard Clark]

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 at fohnet.co.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20111026/a5bb83b8/attachment.sig>