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@lbl.gov]
Sent: Wed 29/03/2006 4:35 AM
To: Ben Robson
Cc: rt-users@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
…
The rt-users Archives
Community help: http://wiki.bestpractical.com
Commercial support: sales@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:
Careers — Best Practical Solutions
…
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
…
The rt-users Archives
Community help: http://wiki.bestpractical.com
Commercial support: sales@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:
Careers — Best Practical Solutions
Best regards, Ruslan.
