[rt-users] Grouping of un-priv user tickets

[Ben Robson]

Ruslan,

Thanks heaps for this, I have not completed full testing but it
certainly seems to be working like a charm.

So, to help those dealing with this issue in the future I will now say
(for the use of the ht-dig search engine):

If you are looking for a way to automatically Cc unprivileged users to
Requestors tickets grouping customers via organization, this scrip seems
to work perfectly.

Thanks again,
BenR

Group
Unprivileged
Users
Organization
Scrip
Cc

> -----Original Message-----
> From: Ruslan Zakirov [mailto:ruslan.zakirov at gmail.com]
> Sent: Thursday, 30 March 2006 5:22 AM
> To: Ben Robson
> Cc: rt-users at lists.bestpractical.com
> Subject: Re: [rt-users] Grouping of un-priv user tickets
> 
> Here is scrip action that do this, it has comments and should work:
> 
> <<<<<<<
> my @orgs; # list of the organizations
> 
> # find groups that holds Requestors and Ccs
> my $requestors_group = $self->TicketObj->Requestors;
> my $ccs_group = $self->TicketObj->Cc;
> 
> # fetch organizations from current list of the requestors
> my $requestors = $requestors_group->UserMembersObj;
> while ( my $requestor = $requestors->Next ) {
>     push @orgs, $requestor->Organization;
> }
> 
> # filter orgs: not empty and unique
> { my %seen;
>   @orgs = grep $_ && !$seen{$_}, @orgs;
> }
> 
> # exit if did't find any organizations
> return 1 unless @orgs;
> 
> # find users who have value of organization from the @orgs list
> my $users = RT::Users->new($RT::SystemUser);
> $users->Limit( FIELD => 'Organization', VALUE => $_ ) foreach @orgs;
> 
> # add users we've found to the Cc list, but only if they aren't
members
> allready
> while ( my $user = $users->Next ) {
>   next if $requestors_group->HasMemberRecursively( $user->PrincipalObj
);
>   next if $ccs_group->HasMemberRecursively( $user->PrincipalObj );
>   my ($status, $msg) = $ccs_group->AddMember( $user->id );
>   $RT::Logger->error("Couldn't add memeber: $msg") unless $status;
> }
> 
> return 1;
> >>>>>>>>>
> 
> On 3/29/06, Ben Robson <ben.robson at classicblue.com.au> wrote:
> >
> >
> > I wasn't planning on altering any of the core code.
> >
> > What I was hoping to do was adapt the below scrip such that where it
> > currently fetches the Creator->Organisation it identifies who the
> > Ticket->Requestor is OnCreate, find's the Requestor's organisation
from
> the
> > $users and then procedes to match other $users against the same
> > organisation, as it does now.
> >
> > I don't think that should require anything further than an
embelishment
> of
> > the existing scrip.
> >
> > The part I am struggling with right now is the bit that says "OK,
heres
> the
> > Requestor, now what's that person's organisation?"  I obviously
can't
> just
> > do RequestorObj->__Value('Organization'); because
> > "RequestorObj" doesn't exist.  So in some way I need to identify the
> ticket
> > requestor (not part of TransactionObj), and then trawl through
$users to
> > find that requestor and then identify that requestor's organisation.
> >
> > Anyone else got any thoughts on this?
> >
> > BenR
> >
> >  ________________________________
> >  From: Kenneth Crocker [mailto:KFCrocker at lbl.gov]
> > Sent: Wed 29/03/2006 4:35 AM
> > To: Ben Robson
> > Cc: rt-users at lists.bestpractical.com
> > Subject: Re: [rt-users] Grouping of un-priv user tickets
> >
> >
> > Ben,
> >
> >     There's an awful lot of code in RT that relies on some of the
> default
> > info to remain unchanged, like the requestor. If you need some other
> custom
> > field to show someone else created the request, then fine, create
the
> custom
> > field but leave the requestor field alone and make sure that when
the
> > "creator" creates the ticket, the correct info on the "real"
requestor
> (like
> > e_mail, etc.) is put in and I think the Requestor will get his
e_mail
> and be
> > able to do whatever rights you gave to the requestor role (liek
> seeQueue,
> > show outgoingmail, showticket, reply to ticket, etc.). Our feelings
here
> are
> > that adding custom code should NEVER interfere with the code that is
> already
> > there, it should be extra and self-contained. Less chance of messing
up
> a
> > function that was already working when the software arrived. But
heck,
> > that's just our philosphy and what do we know. ;-)
> >
> > Kenn
> >
> > Ben Robson wrote:
> >
> > All,
> >
> > I, along with others I believe, have been struggling with the issue
of
> > allowing un-priv users who work for the same company (customer) to
see
> each
> > others tickets.
> >
> > I have a scrip in place that currently checks the Organization ( my
> > $organization =
> > $self->TransactionObj->CreatorObj->__Value('Organization');
> > ) of the creator of the ticket and then proceeds to add the details
to
> the
> > CC list of the ticket for all other users who's organization is the
same
> > value.
> >
> > This works great, up to a point.....
> >
> > In the event that the Requestor is not the Creator, for example when
the
> > requestor calls the company's helpdesk and a helpdesk operator
completes
> the
> > ticket, the Creator's organization details are used and not the
> Requestor's.
> >
> > This means that when a member of the Requesting company goes to view
> tickets
> > the created ticket may not be vissible, unless they are explicitly
the
> > individual who requested it.
> >
> > Below is my "Customer action preparation code".  Can anyone see how
this
> > might be modified such that rather than getting the Creator's
> organization
> > on the first line, it gets the Requestor's organization instead?
> >
> >
> > my $organization =
> > $self->TransactionObj->CreatorObj->__Value('Organization');
> > my $users = new RT::Users($RT::SystemUser);
> > my $cclist = $self->TicketObj->Cc;
> >
> > while( my $user = $users->Next )
> > {
> >         my $userOrg=$user->Organization;
> >         if ($organization eq $userOrg) {
> >        $cclist->AddMember($user->id)
> >         }
> >  $RT::Logger->info( "OnCreateCCDomain scrip added ". $user->Name ."
as a
> > CC!" );
> > }
> >
> > Thanks all, I am sure many may find this useful.
> >
> > Ben
> >
>
Robson..................................................................
..
> ........................................................
> >
> > This email (including all attachments) is intended solely for the
named
> > addressee. It is confidential and may contain legally privileged
> > information. If you receive it in error, please let us know by reply
> email,
> > do not disclose any information contained in it, delete it from your
> system
> > and destroy any copies. This email is also subject to copyright. No
part
> of
> > it should be reproduced, adapted or transmitted without the written
> consent
> > of the copyright owner. Emails may be interfered with, may contain
> computer
> > viruses or other defects and may not be successfully replicated on
other
> > systems.
> >
> > We give no warranties in relation to these matters. If you have any
> doubts
> > about the authenticity of an email purportedly sent by us, please
> contact us
> > immediately. Privacy - Please be aware that information provided in
> response
> > to this email may contain personal information, which Classic Blue
may
> > collect, and use for the purposes of marketing information
technology
> > products and services to you. For further information regarding
Classic
> > Blue's privacy policies please refer to www.classicblue.com.au
> >
>
........................................................................
..
> ..................................................
> >
> > ________________________________
> >
> > _______________________________________________
> > http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
> >
> > Community help: http://wiki.bestpractical.com
> > Commercial support: sales at bestpractical.com
> >
> >
> > Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
> > Buy a copy at http://rtbook.bestpractical.com
> >
> >
> > We're hiring! Come hack Perl for Best Practical:
> > http://bestpractical.com/about/jobs.html
> >
>
........................................................................
..
> ..................................................
> >
> > This email (including all attachments) is intended solely for the
named
> > addressee. It is confidential and may contain legally privileged
> > information. If you receive it in error, please let us know by reply
> email,
> > do not disclose any information contained in it, delete it from your
> system
> > and destroy any copies. This email is also subject to copyright. No
part
> of
> > it should be reproduced, adapted or transmitted without the written
> consent
> > of the copyright owner. Emails may be interfered with, may contain
> computer
> > viruses or other defects and may not be successfully replicated on
other
> > systems.
> >
> > We give no warranties in relation to these matters. If you have any
> doubts
> > about the authenticity of an email purportedly sent by us, please
> contact us
> > immediately. Privacy - Please be aware that information provided in
> response
> > to this email may contain personal information, which Classic Blue
may
> > collect, and use for the purposes of marketing information
technology
> > products and services to you. For further information regarding
Classic
> > Blue's privacy policies please refer to www.classicblue.com.au
> >
>
........................................................................
..
> ..................................................
> >
> >
> > _______________________________________________
> > http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
> >
> > Community help: http://wiki.bestpractical.com
> > Commercial support: sales at bestpractical.com
> >
> >
> > Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
> > Buy a copy at http://rtbook.bestpractical.com
> >
> >
> > We're hiring! Come hack Perl for Best Practical:
> > http://bestpractical.com/about/jobs.html
> >
> >
> 
> 
> --
> Best regards, Ruslan.
............................................................................................................................

This email (including all attachments) is intended solely for the named addressee. It is confidential and may contain legally privileged information. If you receive it in error, please let us know by reply email, do not disclose any information contained in it, delete it from your system and destroy any copies. This email is also subject to copyright. No part of it should be reproduced, adapted or transmitted without the written consent of the copyright owner. Emails may be interfered with, may contain computer viruses or other defects and may not be successfully replicated on other systems.

We give no warranties in relation to these matters. If you have any doubts about the authenticity of an email purportedly sent by us, please contact us immediately.  Privacy - Please be aware that information provided in response to this email may contain personal information, which Classic Blue may collect, and use for the purposes of marketing information technology products and services to you.  For further information regarding Classic Blue's privacy policies please refer to www.classicblue.com.au
............................................................................................................................