Grouping of un-priv user tickets

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

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. :wink:

Kenn

Ben Robson 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?

BenRFrom: 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
............................................................................................................................
  



http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

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: 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

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;

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. :wink:

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@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@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.

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@gmail.com]
Sent: Thursday, 30 March 2006 5:22 AM
To: Ben Robson
Cc: rt-users@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;

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. :wink:

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@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@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