<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<DIV id=idOWAReplyText30858 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>I wasn't planning on altering
any of the core code.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>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.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>I don't think that should require anything
further than an embelishment of the existing scrip.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>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.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Anyone else got any thoughts on
this?</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>BenR</FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Kenneth Crocker
[mailto:KFCrocker@lbl.gov]<BR><B>Sent:</B> Wed 29/03/2006 4:35 AM<BR><B>To:</B>
Ben Robson<BR><B>Cc:</B> rt-users@lists.bestpractical.com<BR><B>Subject:</B> Re:
[rt-users] Grouping of un-priv user tickets<BR></FONT><BR></DIV>
<DIV>Ben,<BR><BR> 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. ;-)<BR><BR>Kenn<BR><BR>Ben Robson wrote:
<BLOCKQUOTE cite="" type="cite">
<DIV><FONT face=Arial color=#000000 size=2>All,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>This works great, up to a point.....</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>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?</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>my $organization =
$self->TransactionObj->CreatorObj->__Value('Organization');</FONT></DIV>
<DIV><FONT face=Arial size=2>my $users = new
RT::Users($RT::SystemUser);</FONT></DIV>
<DIV><FONT face=Arial size=2>my $cclist =
$self->TicketObj->Cc;<BR> <BR>while( my $user = $users->Next
)<BR>{<BR> my
$userOrg=$user->Organization;<BR>
if ($organization eq $userOrg) {<BR>
$cclist->AddMember($user->id)<BR>
} <BR> $RT::Logger->info( "OnCreateCCDomain scrip added ".
$user->Name ." as a CC!" );<BR>}</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Thanks all, I am sure many may find this
useful.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Ben Robson</FONT></DIV><PRE>............................................................................................................................
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 <A class=moz-txt-link-abbreviated href="http://www.classicblue.com.au">www.classicblue.com.au</A>
............................................................................................................................
</PRE><PRE><HR width="90%" SIZE=4>
_______________________________________________
<A class=moz-txt-link-freetext href="http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users">http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users</A>
Community help: <A class=moz-txt-link-freetext href="http://wiki.bestpractical.com">http://wiki.bestpractical.com</A>
Commercial support: <A class=moz-txt-link-abbreviated href="mailto:sales@bestpractical.com">sales@bestpractical.com</A>
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at <A class=moz-txt-link-freetext href="http://rtbook.bestpractical.com">http://rtbook.bestpractical.com</A>
We're hiring! Come hack Perl for Best Practical: <A class=moz-txt-link-freetext href="http://bestpractical.com/about/jobs.html">http://bestpractical.com/about/jobs.html</A></PRE></BLOCKQUOTE></DIV>
<pre>............................................................................................................................
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
............................................................................................................................
</pre></body>
</html>