Re: [rt-users] Prevent users from Assigning Owner during ticket create?
Hi Aaron,
you can either force the Owner back to Nobody like Kenn did (this is
possible using OnCreate too) or even better, copy the
/opt/rt3/share/html/Ticket/Create.html to your local directory and
comment out the lines with the owner (I did this for us here and in some
other files to get rid of all the built-in fields we do not use), so
people won't even see there's a possibility to set an owner themselves:
!--td class=label
|/lOwner/:
/td
td class=value
/Elements/SelectOwner, Name = Owner, QueueObj = $QueueObj,
Default = $ARGS{Owner}||$RT::Nobody-Id, DefaultValue = 0
/td--
Ben
Kenneth Crocker schrieb:
Aaron,
I reset the owner to Nobody when a ticket is moved to a new queue.
Perhaps a little change to that will work for you. Here it is:
Condition: On Create
Action:User-defined
Template: Blank
Stage: TransactionBatch
#
# Custom condition: none
#
#
# Custom action preparation code:
#
return 1;
#
# Custom action cleanup code:
#
# set new Ticket Owner value
my $ticket = $self-TicketObj;
$ticket-SetOwner(10, 'Force');
return 1;
I hope this helps.
Kenn
LBNL
On 5/22/2008 10:48 AM, Aaron Sallade wrote:
We have a workflow where our customers log in to RT and can create a new
ticket in the Helpdesk Queue. Unfortunately they are currently able to
assign an Owner during the Create process.
I have not been able to find a permission that limits or allows
assigning an owner, it seems to be granted along with the Create Ticket
right.
I have tried to write a scrip that will set the owner to Nobody, but I
get an error in the log stating that I can only assign tickets that have
no owner or are assigned to me.
Ideas?
Aaron Sallade'
Application Manager
PTSO of Washington
//Shared Technology for Community Health///
/(206) 613-8938 Desk
(206) 521-8833 Main
(206) 613-5078 Fax
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] show a new ticket tab for a special user group only
Hi Dirk,
thank you, your code works. Almost. ;)
I had to mix it up a little bit with what I've found at the wiki
(http://wiki.bestpractical.com/view/TestGroupMembership) since
HasMemberRecursively() expects a Principal as parameter.
For everybody with similar problems: here you can see my working code now:
my $group = new RT::Group($session{'CurrentUser'});
$group-LoadUserDefinedGroup('Members RMB');
my $principal = new RT::Principal($session{'CurrentUser'});
$principal-Load($session{'CurrentUser'}-Id);
if ($group-HasMemberRecursively($principal)) {
$RT::Logger-info(found: , $group-Name);
$ticket_page_tabs-{_Ca} = { title = loc('RMB'),
path = Ticket/RMB.html?id= . $id,
};
}
Ben
Dirk Pape schrieb:
Hello Ben,
--Am 22. Mai 2008 18:39:12 +0200 schrieb Benjamin Weser [EMAIL PROTECTED]:
$RT::Logger-info(User: , $session{'CurrentUser'}-Name);
my $groups = $session{'CurrentUser'}-UserObj-OwnGroups;
$RT::Logger-info(Count: , $groups-Count);
while (my $group = $groups-Next){
$RT::Logger-info(test: , $group-Name);
if ( $group-Name =~ /Members RMB/ ){
$RT::Logger-info(found: , $group-Name);
$ticket_page_tabs-{_Ca} = { title = loc('RMB'),
path = Ticket/RMB.html?id= . $id,
};
}
}
I don't know why your code does not work, but I would do it other way
round: load the group and look if currentuser is a member.
Without guarantee:
my $group = new RT::Group($session{'CurrentUser'});
$group-LoadUserDefinedGroup('Members RMB');
if ($group-HasMemberRecursively($session{'CurrentUser'})) {
$ticket_page_tabs-{_Ca} = { title = loc('RMB'),
path = Ticket/RMB.html?id= . $id,
};
}
Dirk.
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
[rt-users] permanently squelching a user
So here's my setup: I have an 'alert' email for tickets, and a 'support'
email for tickets. Alert cc's our cell phones (via /etc/aliases) and
sets the ticket to a high priority (via a scrip based on to: email
headers) . Support goes to the same queue but simply notifies the
adminCCs via email. The problem is that since I'm using the script from
the wiki to add ccs as watchers, the alert email keeps getting added to
tickets as a cc, even though support owns them. This results in
everyone's cell phones getting sms'd every time there is a reply to an
alert ticket. Even after I remove alert from the ticket, users continue
to reply to the initial email where alert was cc'd.
For some reason the part of the script that doesn't add the cc if a user
is an RT user isn't working for this email.
I attempted to shove the alert email into @blacklist in SendEmail.pm,
which seemed to work, but unrelated scrips are now failing. (Errors
below.) I'm open to suggestions if I'm going about this completely
wrong.
I added the following code into SendEmail.pm:
foreach my $address (qw/ [EMAIL PROTECTED]/){
$RT::Logger-debug(squelching alert);
push @blacklist, $address;
}
/var/log/rt/rt.log displays the following when replying to a ticket with
alert cc'd:
[Fri May 23 01:26:14 2008] [debug]: Found 5 scrips
(/usr/lib/rt/RT/Scrips_Overlay.pm:356)
[Fri May 23 01:26:14 2008] [error]: Scrip Prepare 3 died. - Can't locate
object method new via package RT::Action::Autoreply at
/usr/lib/rt/RT/ScripAction_Overlay.pm line 178.
Stack:
[/usr/lib/rt/RT/ScripAction_Overlay.pm:178]
[/usr/lib/rt/RT/Scrip_Overlay.pm:473]
[/usr/lib/rt/RT/Scrips_Overlay.pm:236]
[/usr/lib/rt/RT/Transaction_Overlay.pm:162]
[/usr/lib/rt/RT/Record.pm:1438]
[/usr/lib/rt/RT/Ticket_Overlay.pm:720]
[/usr/local/rt/lib/RT/Interface/Email.pm:793]
[/var/rt/html/REST/1.0/NoAuth/mail-gateway:58]
(/usr/lib/rt/RT/Scrip_Overlay.pm:481)
[Fri May 23 01:26:14 2008] [error]: Scrip Prepare 4 died. - Can't locate
object method new via package RT::Action::Notify at
/usr/lib/rt/RT/ScripAction_Overlay.pm line 178.
Stack:
[/usr/lib/rt/RT/ScripAction_Overlay.pm:178]
[/usr/lib/rt/RT/Scrip_Overlay.pm:473]
[/usr/lib/rt/RT/Scrips_Overlay.pm:236]
[/usr/lib/rt/RT/Transaction_Overlay.pm:162]
[/usr/lib/rt/RT/Record.pm:1438]
[/usr/lib/rt/RT/Ticket_Overlay.pm:720]
[/usr/local/rt/lib/RT/Interface/Email.pm:793]
[/var/rt/html/REST/1.0/NoAuth/mail-gateway:58]
(/usr/lib/rt/RT/Scrip_Overlay.pm:481)
[Fri May 23 01:26:14 2008] [debug]: About to commit scrips for
transaction #3535 (/usr/lib/rt/RT/Transaction_Overlay.pm:169)
~~
Kimberly McKinnis
System Operations Engineer
Service Provider Division, TiVo Inc
408-519-9607
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] permanently squelching a user
--- On Fri, 5/23/08, Kimberly McKinnis [EMAIL PROTECTED] wrote: So here's my setup: I have an 'alert' email for tickets, and a 'support' email for tickets. Alert cc's our cell phones (via /etc/aliases) and sets the ticket to a high priority (via a scrip based on to: email headers) . Support goes to the same queue but simply notifies the adminCCs via email. The problem is that since I'm using the script from the wiki to add ccs as watchers, the alert email keeps getting added to tickets as a cc, even though support owns them. This results in everyone's cell phones getting sms'd every time there is a reply to an alert ticket. Even after I remove alert from the ticket, users continue to reply to the initial email where alert was cc'd. I attempted to shove the alert email into @blacklist in SendEmail.pm, which seemed to work, but unrelated scrips are now failing. (Errors below.) I'm open to suggestions if I'm going about this completely wrong. I've written a multi purpose 'spam/text/sender/receiver filter' which sits between sendmail/postfix and RT. Basicially, it works like this: Instead of having an entry in /etc/aliases pointing to RT, the alias points to my script. The script analyzes the whole email and looks for certain text strings. If they exist (or don't exist, depending on the need), it opens a pipe to RT and passes the email along; if the conditions are met where it shouldn't go into RT, it's dropped. If you'd like a copy of my perl script, let me know. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] permanently squelching a user
Yes please! I'll drop it onto my RT testbed and see how it incorporates into the system. I originally thought there must be a simpler way to do this, but procmail wasn't working out either. -Original Message- From: Joseph Spenner [mailto:[EMAIL PROTECTED] Sent: Friday, May 23, 2008 11:46 AM To: rt-users@lists.bestpractical.com Cc: Kimberly McKinnis Subject: Re: [rt-users] permanently squelching a user --- On Fri, 5/23/08, Kimberly McKinnis [EMAIL PROTECTED] wrote: So here's my setup: I have an 'alert' email for tickets, and a 'support' email for tickets. Alert cc's our cell phones (via /etc/aliases) and sets the ticket to a high priority (via a scrip based on to: email headers) . Support goes to the same queue but simply notifies the adminCCs via email. The problem is that since I'm using the script from the wiki to add ccs as watchers, the alert email keeps getting added to tickets as a cc, even though support owns them. This results in everyone's cell phones getting sms'd every time there is a reply to an alert ticket. Even after I remove alert from the ticket, users continue to reply to the initial email where alert was cc'd. I attempted to shove the alert email into @blacklist in SendEmail.pm, which seemed to work, but unrelated scrips are now failing. (Errors below.) I'm open to suggestions if I'm going about this completely wrong. I've written a multi purpose 'spam/text/sender/receiver filter' which sits between sendmail/postfix and RT. Basicially, it works like this: Instead of having an entry in /etc/aliases pointing to RT, the alias points to my script. The script analyzes the whole email and looks for certain text strings. If they exist (or don't exist, depending on the need), it opens a pipe to RT and passes the email along; if the conditions are met where it shouldn't go into RT, it's dropped. If you'd like a copy of my perl script, let me know. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] permanently squelching a user
--- On Fri, 5/23/08, Kimberly McKinnis [EMAIL PROTECTED] wrote:
Yes please! I'll drop it onto my RT testbed and see how
it incorporates
into the system. I originally thought there must be a
simpler way to do
this, but procmail wasn't working out either.
I've written a multi purpose
'spam/text/sender/receiver filter' which
sits between sendmail/postfix and RT. Basicially, it works
like this:
Instead of having an entry in /etc/aliases pointing to RT,
the alias
points to my script. The script analyzes the whole email
and looks for
certain text strings. If they exist (or don't exist,
depending on the
need), it opens a pipe to RT and passes the email along; if
the
conditions are met where it shouldn't go into RT,
it's dropped.
Here's my script:
-
#!/usr/bin/perl
# put the contents of the message into an array
@originalMessage=STDIN;
@[EMAIL PROTECTED];
# weed out the html tags
foreach $line (@scanThis) {
$line =~ s/\[^\]*\//g;
}
# get message into a string so we can search it
$messageString1=join( , @scanThis);
$messageString2=join( , @originalMessage);
$messageString = $messageString1 $messageString2;
# get all the bad content lines from datafile
open (BADLINES, /home/gman/scripts/badlines.txt);
@badlines=BADLINES;
close BADLINES;
# if the message contains bad content, exit
foreach $line (@badlines) {
chomp $line;
if ($messageString =~ m/$line/i) {
exit 0;
}
}
# we found nothing bad, so pass it through to RT
open (PIPE, |/opt/rt2/bin/rt-mailgate --queue customer_probs --action
correspond);
print PIPE @originalMessage;
close PIPE;
I'm still using RT2, and the line:
|/opt/rt2/bin/rt-mailgate --queue customer_probs --action correspond
is directly from /etc/aliases. I'm not sure how it is done in RT3, but I'm
sure it's similar.
The file:
/home/gman/scripts/badlines.txt
Should contain text strings which have content to cause the message to never
make it to RT. Each line should contain its own text to block.
You may need to escape certain characters, such as @ and *. Here's a
section of my badlines.txt:
[EMAIL PROTECTED]@
F\*R\*E\*E
health insurance rates
chat with singles
100% risk free
EXERC1SE
Each line of the badlines.txt should contain text you want to block.
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
