[rt-devel] Attempting to make Subject: tag matching a little more permissive, diff enclosed

[Jim Brandt]

Your approach could work (you don't mention which version of RT, recent 
versions changed incoming email handling).

Another approach to limit the scope of your change would be to search 
for incoming mail only from that email address (or domain, if there are 
many) and update the subject to put the space back in. The main 
advantages here are: 1) you limit the scope of the change to just email 
from that address and 2) you're making it look like RT expects, which is 
less likely to miss some other location that assumes subject will be in 
the specified format.

You could do this with some tool before the email gets into RT or by 
adding an email processing step somewhere before the code below.

Either way, if you make changes, do it in an override library in local, 
not in the main code. That way it's simple to revert if it doesn't 
behave as you expect.


On 9/28/16 1:53 PM, Alexis Rosen wrote:
> Hi. I'm trying to make RT play nice with a certain large telecom vendor's ticketing system. They're trying to play nice too, but they're too dumb to get it right. :-( In particular, they're turning our "[tag #12345]" into "[tag#12345]" on subject lines. So I want to relax the requirement for whitespace between the tag and the ticket number.
>
> I was a bit lazy for a cold source-dive, but fortunately google turned up a commit a few years back that looked like it was touching exactly the code I wanted, lib/RT/Interface/Email.pm: ParseTicketId().
>
> It looks like the changes I need to make are:
>
> --- Email.pm    2015-10-19 13:38:13.000000000 -0400
> +++ Email.test.pm       2016-09-28 12:50:06.000000000 -0400
> @@ -1139,11 +1139,11 @@
>     # We use @captures and pull out the last capture value to guard against
>     # someone using (...) instead of (?:...) in $EmailSubjectTagRegex.
>     my $id;
> -    if ( my @captures = $Subject =~ /\[$test_name\s+\#(\d+)\s*\]/i ) {
> +    if ( my @captures = $Subject =~ /\[$test_name\s*\#(\d+)\s*\]/i ) {
>         $id = $captures[-1];
>     } else {
>         foreach my $tag ( RT->System->SubjectTag ) {
> -            next unless my @captures = $Subject =~ /\[\Q$tag\E\s+\#(\d+)\s*\]/i;
> +            next unless my @captures = $Subject =~ /\[\Q$tag\E\s*\#(\d+)\s*\]/i;
>             $id = $captures[-1];
>             last;
>         }
>
> In other words, just replace a "+" with a "*", so it'll match no whitespace as well as some.
>
> So, questions:
> 1) Does this make sense?
> 2) Am I likely to screw anything up by doing this?
> 3) Did I leave out something else that needs to be adjusted, besides ParseTicketId()?
> 4) Do I really need the first change? (I'm not sure what "$test_name" is for)
>
> And lastly, is it worth submitting this patch? In my estimation, it's still a unique enough match that it shouldn't scarf up things it shouldn't, so it might be generally useful to others trying to work with foreign ticketing systems, while not bothering anyone who isn't.
>
> I can run this way in a test instance for a while, but my major concern is screwing up on real-world inbound mail, which I can't easily test.
>
> I'll be monitoring this list on the web, but a direct reply would be appreciated anyway.
>
> Thanks,
> /a
> ---------
> RT 4.4 and RTIR training sessions, and a new workshop day! https://bestpractical.com/training
> * Boston - October 24-26
> * Los Angeles - Q1 2017
>