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

[Ruslan Zakirov]

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.