Assign child ticket to a separate queue?

[Ciancetta_Barbara_J]

Using RT 3.8.7 and trying to configure so that it will support the following workflow:

Need:
Team A create tickets for team B to take action
Keep team B’s access restricted to just those tickets that team opened for their action
Keep statistics for Team A clean (i.e. number of tickets in Team A queue)

Seems a good approach to this would be team A (in their queue) creating a child ticket but assigning it to team B’s queue. My interpretation of the following statement from article (WorkFlow - Request Tracker Wiki) seems to indicate that may be possible.
“The Queue is the queue in which the new ticket is created. At the moment, we’ve elected to create them in the same queue as the parent ticket, but it may make more sense to create them in other queues. The Parent link will keep everything tied together if you do.”

However trying to create a child ticket and assign it to a separate queue in our dev environment doesn’t seem possible. Does anyone know if this is possible? Please help.

[Emmanuel_Lacour]

However trying to create a child ticket and assign it to a separate queue
in our dev environment doesn’t seem possible. Does anyone know if this is
possible? Please help.

you have to patch a little bit RT to allow users to choose the queue
when they create “sub tickets”.

Attached patch should do this.

choose-queue-for-child-tickets.patch (1.93 KB)

[Luis_E]

However trying to create a child ticket and assign it to a separate
queue in our dev environment doesn’t seem possible. Does anyone know
if this is possible? Please help.

Yes, it’s possible. Check the obvious first, such as permissions to
create tickets in the B queue.

Regards.

-lem

[Emmanuel_Lacour]

However trying to create a child ticket and assign it to a separate
queue in our dev environment doesn’t seem possible. Does anyone know
if this is possible? Please help.

Yes, it’s possible. Check the obvious first, such as permissions to
create tickets in the B queue.

of course, but you cannot choose the queue when using “add” links in
“Links” box of current ticket. Hence the patch I sent.

[Peter_Barton]

I have seen the RT-Extension-MandatorySubject plugin and this is great for opening tickets via the web interface. However, my company opens at least 90% of its tickets via email. Is there anything out that can enforce mandatory subjects on tickets opened via email?

Peter Barton

[Raed_El-Hames2]

Peter,

I have seen the RT-Extension-MandatorySubject plugin and this is great for
opening tickets via the web interface. However, my company opens at least
90% of its tickets via email. Is there anything out that can enforce
mandatory subjects on tickets opened via email?

How would you do that? Sending a bounce back? – which is not convenient?
What you can do is write a scrip on create to look for empty subject and then insert one based on whatever criteria you want, eg requestor / sender email address or the first line of the content etc …

Regards;
Roy

[Peter_Barton]

I have seen the RT-Extension-MandatorySubject plugin and this is
great for
opening tickets via the web interface. However, my company opens at
least
90% of its tickets via email. Is there anything out that can enforce
mandatory subjects on tickets opened via email?

How would you do that? Sending a bounce back? – which is not
convenient?
What you can do is write a scrip on create to look for empty subject
and then insert one based on whatever criteria you want, eg requestor /
sender email >address or the first line of the content etc …

Regards;
Roy

I would actually like to bounce the email back notifying the sender that
the subject is required.

Peter Barton

[Emmanuel_Lacour]

I would actually like to bounce the email back notifying the sender that
the subject is required.

You can hack lib/RT/Interface/Email.pm::Gateway, add a test on $Subject after the
test of $Authstat and use MailError in the same way.

Or a scrip that makes the ticket rejected and send an email to
requestor.

[Kenneth_Marshall]

I have seen the RT-Extension-MandatorySubject plugin and this is
great for
opening tickets via the web interface. However, my company opens at
least
90% of its tickets via email. Is there anything out that can enforce
mandatory subjects on tickets opened via email?

How would you do that? Sending a bounce back? – which is not
convenient?
What you can do is write a scrip on create to look for empty subject
and then insert one based on whatever criteria you want, eg requestor /
sender email >address or the first line of the content etc …

Regards;
Roy

I would actually like to bounce the email back notifying the sender that
the subject is required.

---

Peter Barton

In order to prevent problems caused by back-scatter, you may want to
consider returning a 5xx error to the mail message with an informative
message. You could use header_checks with postfix and most other MTA’s
support similar functionality.

Cheers,
Ken

[Jason_A_Smith]

I have seen the RT-Extension-MandatorySubject plugin and this is
great for
opening tickets via the web interface. However, my company opens at
least
90% of its tickets via email. Is there anything out that can enforce
mandatory subjects on tickets opened via email?

How would you do that? Sending a bounce back? – which is not
convenient?
What you can do is write a scrip on create to look for empty subject
and then insert one based on whatever criteria you want, eg requestor /
sender email>address or the first line of the content etc …

Regards;
Roy

I would actually like to bounce the email back notifying the sender that
the subject is required.

Personally I don’t see a problem with sending a bounce to a person who
sent an email without a subject either. I think the original email
without a subject is inconvenient, so they deserve a bounce.

We send all of our RT email through procmail for some additional
filtering like this and this is the section of our procmail that checks
for missing subjects. It sends a copy of their original email back to
them, with a subject saying that their ticket was rejected because the
subject was missing. It also adds a message to the email body, but
unfortunately it is appended so they may not see it. I haven’t bothered
to try to figure out a way to prepend it. I Bcc the bounces to my email
address also, so I know when people do this and I can check to see if
they resent the email with a subject.

~Jason

procmail (1.05 KB)

smime.p7s (3.97 KB)

[Kenneth_Marshall]

I have seen the RT-Extension-MandatorySubject plugin and this is
great for
opening tickets via the web interface. However, my company opens at
least
90% of its tickets via email. Is there anything out that can enforce
mandatory subjects on tickets opened via email?

How would you do that? Sending a bounce back? – which is not
convenient?
What you can do is write a scrip on create to look for empty subject
and then insert one based on whatever criteria you want, eg requestor /
sender email>address or the first line of the content etc …

Regards;
Roy

I would actually like to bounce the email back notifying the sender that
the subject is required.

Personally I don’t see a problem with sending a bounce to a person who sent
an email without a subject either. I think the original email without a
subject is inconvenient, so they deserve a bounce.

We send all of our RT email through procmail for some additional filtering
like this and this is the section of our procmail that checks for missing
subjects. It sends a copy of their original email back to them, with a
subject saying that their ticket was rejected because the subject was
missing. It also adds a message to the email body, but unfortunately it is
appended so they may not see it. I haven’t bothered to try to figure out a
way to prepend it. I Bcc the bounces to my email address also, so I know
when people do this and I can check to see if they resent the email with a
subject.

~Jason

Check for missing or empty subjects:

ERRORS_TO="my.email@domain.com"
SUBJECT=formail -xSubject: | expand | sed -e 's/^[ ]*//g' -e 's/[ ]*$//g'
:0 c:

• SUBJECT ?? ^^^^
  | formail -I “Status: R” >>${MAILDIR}/noSubject
  :0 A
  |( formail -brkt -I"From: RT Ticket System ticket-address@domain.com"
  -I"Bcc: $ERRORS_TO"
  -I"Subject: RT email ticket rejected - NO SUBJECT.";
  echo “-------- RT Message --------”;
  echo “Your email ticket request will NOT be processed without a subject.”;
  echo “Please include a subject in your email message above and resend it.”
  ) | $SENDMAIL -oi -t
  :0 c:
• SUBJECT ?? (no subject)
  | formail -I “Status: R” >>${MAILDIR}/noSubject
  :0 A
  |( formail -brkt -I"From: RT Ticket System ticket-address@domain.com"
  -I"Bcc: $ERRORS_TO"
  -I"Subject: RT email ticket rejected - NO SUBJECT.";
  echo “-------- RT Message --------”;
  echo “Your email ticket request will NOT be processed without a subject.”;
  echo “Please include a subject in your email message above and resend it.”
  ) | $SENDMAIL -oi -t

In principle, an informative bounce is okay. Unfortunately, it can
be taken advantage of by unscrupulous mailers to send SPAM messages
to other E-mail addresses with the consequent impact to your mail
reputation and ability to send E-mail from your domain to others.
If you restrict such bounces to local authenticated E-mail, then
you can minimize the risk through the use of accountability.

Cheers,
Ken

[Konstantin_Khomoutov]

I have seen the RT-Extension-MandatorySubject plugin and this is
great for opening tickets via the web interface. However, my company
opens at least 90% of its tickets via email. Is there anything out
that can enforce mandatory subjects on tickets opened via email?

We were facing the same problem (the difference is that in our case
100% tickets are filed using web interface) and it was solved using two
different soultions (deployed one after another, we’re currently using
the first one).

The first is to make a scrip which sets the subject to the first
non-empty line of the report text.

Meta info for the scrip:
Description: “00 On Create Set Subject From Request Text”
Condition: User Defined
Action: User Defined
Template: Global Template: Blank
Stage: TransactionCreate

Scrip condition code:

if ($self->TransactionObj->Type eq ‘Create’
&& $self->TicketObj->Subject() eq ‘’) {
return 1;
} else {
return undef;
}

Scrip code:

my @lines = split(/\n/, $self->TransactionObj->Content());
for my $line (@lines) {
$line =~ s/^\s+//;
$line =~ s/\s+$//;
if ($line ne ‘’) {
my ($ok, $msg) = $self->TicketObj->SetSubject($line);
if (!$ok) {
$RT::Logger->error(“Failed to set ticket subject: $msg”);
return 0;
}
last;
}
}
return 1;

The scrip description starts with "00 " to ensure it is executed
earlier that other scrips (see [1]) which is needed so that the
watchers of the relevant queue get their notification e-mail with
the subject appropriately modified.

Then we switched to using a callback for the BeforeCreate event of the
/SelfService/Create.html form and now the subject is set in that
callback using roughly the same code.

1. ScripExecOrder - Request Tracker Wiki

[Jason_A_Smith]

In principle, an informative bounce is okay. Unfortunately, it can
be taken advantage of by unscrupulous mailers to send SPAM messages
to other E-mail addresses with the consequent impact to your mail
reputation and ability to send E-mail from your domain to others.
If you restrict such bounces to local authenticated E-mail, then
you can minimize the risk through the use of accountability.

Cheers,
Ken

True, but if your RT is setup to accept email tickets from anywhere,
because there is no central directory of known email addresses and a
need for many people to be able to submit tickets, then it doesn’t
matter since the “sender” (real or fake) will either get the no subject
bounce or the rt ticket created auto-reply.

Also, in our procmail, the no subject check is the last filter before
the queue check rules. Before these are several other rules to filter
out spam, and emails from mailers, lists, daemons, etc…

~Jason

smime.p7s (3.97 KB)

[Kenn_Crocker]

Ciancetta,

Yes, it is possible. Currently, when you click the “Create” button to create
a child ticket, RT automatically puts the Queue from the parent ticket as
the Queue where the child ticket will be created. That’s a problem and I’m
sure in 3.10, they will allow a manual override similar to the owner,
requestor, etc. However, in the meantime, you can get around this problem.

First, Create a Custom Field called, let’s say, “Child Queue”. Set this CF
as “Enter one value”. Apply this CF to whatever Queues need this function
(you may have Queues that are for maintenance only and don’t have children
tickets). When a user creates that child, they set the CF value to the name
or ID of that Queue (you could have a list of all possible Queues and they
could select from that list as well).

Second, you create a scrip for these same Queues that looks at the CF value
and based on that value, changes the Queue to the value set in that CF.

This works, as I’ve done for some of our Queues where someone sent in an
email to the wrong Queue and we intercept that email, evaluate the “From”
address and re-direct that ticket to a different Queue.

Hope this helps.

Kenn
LBNLOn Wed, Sep 8, 2010 at 5:55 AM, Ciancetta, Barbara J. bcian@mitre.orgwrote:

Using RT 3.8.7 and trying to configure so that it will support the
following workflow:

Need:

Team A create tickets for team B to take action

Keep team B’s access restricted to just those tickets that team opened for
their action

Keep statistics for Team A clean (i.e. number of tickets in Team A queue)

Seems a good approach to this would be team A (in their queue) creating a
child ticket but assigning it to team B’s queue. My interpretation of the
following statement from article (
WorkFlow - Request Tracker Wiki) seems to indicate that may be
possible.

“The Queue is the queue in which the new ticket is created*. At the
moment, we’ve elected to create them in the same queue as the parent ticket,
but it may make more sense to create them in other queues*. The Parent
link will keep everything tied together if you do.”

However trying to create a child ticket and assign it to a separate queue
in our dev environment doesn’t seem possible. Does anyone know if this is
possible? Please help.

RT Training in Washington DC, USA on Oct 25 & 26 2010
Last one this year – Learn how to get the most out of RT!

[Kenneth_Marshall]

In principle, an informative bounce is okay. Unfortunately, it can
be taken advantage of by unscrupulous mailers to send SPAM messages
to other E-mail addresses with the consequent impact to your mail
reputation and ability to send E-mail from your domain to others.
If you restrict such bounces to local authenticated E-mail, then
you can minimize the risk through the use of accountability.

Cheers,
Ken

True, but if your RT is setup to accept email tickets from anywhere,
because there is no central directory of known email addresses and a need
for many people to be able to submit tickets, then it doesn’t matter since
the “sender” (real or fake) will either get the no subject bounce or the rt
ticket created auto-reply.

Also, in our procmail, the no subject check is the last filter before the
queue check rules. Before these are several other rules to filter out
spam, and emails from mailers, lists, daemons, etc…

~Jason

True, these sorts of attacks are caught in our situation by the
anti-spam filter before submitting the message to RT. The same
setup could help ameleorate this back-scatter problem of a no-
subject bounce as well.

Cheers,
Ken

[Andrea_Perotti]

Seems a good approach to this would be team A (in their queue) creating
a child ticket but assigning it to team B’s queue.
I’ve solved the same problem in a cleaner way: extension!

RT-Extension-SpawnLinkedTicketInQueue-1.01 - quickly spawn linked tickets in...

this will add in the UI the possibility to choose the queue when
creating connected tickets.

hth

Andrea Perotti