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

[Ben Robson]

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
............................................................................................................................
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20060329/b7953f22/attachment.htm>