First Last Prev Next    No search results available
Details
: header.*.matchFrom* functions: append/prepend arbitrary t...
Bug#: 26634
: smarttemplate4
: General
Status: RESOLVED
Resolution: FIXED
: PC
: Windows NT
: unspecified
: P3
: enhancement
: ---

:
:
:
:
:
  Show dependency tree - Show dependency graph
People
Reporter: Engle <chrystalingus@web.de>
Assigned To: Axel Grude <axel.grude@gmail.com>

Attachments
2.1 pre 48 (540.48 KB, application/x-xpinstall)
2019-01-14 07:30, Axel Grude
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.

Related actions


Description:   Opened: 2019-01-14 03:06
I would like to have the ability to append or prepend the subject with a string
ONLY IF certain conditions are met.

Ideally I would have the ability to append on reply to mail based on sender
address (if it contains xxxxx.com).

After communicating about this with Axel it seems more feasible to only do this
based on subject contents, i.e.
%header.append.matchFromSubject(hdr,regex,group[,replaceText])% although this
somewhat limits the ability to apply based on conditions.

Best regards
Engle
------- Comment #1 From Axel Grude 2019-01-14 04:02:11 -------
Yes - the quickfix her is to extend existing functions that contain the 

matchFromSubject
or 
matchFromBody

by adding a replacement string parameter. One question would be whether the
replacement parameter should be a regular expression for even more flexibility
or whether a simple string would be sufficient.

Example:

Append "[needles]" to email subject if body contains "pins"

%header.append.matchFromBody(subject,"\bpins\b",0,"[needles]")%

the other question is whether we should leave the matchgroup argument in, since
the insert of the string really works like a boolean (if something is found,
add the string) because the matchgroup doesn't really matter here. then the
alternative syntax would be:


%header.append.matchFromBody(subject,"\bpins\b","[needles]")%

... and SmarTemplateā“ would simply decide to use this based on the fact that
a quoted strings was passed.
------- Comment #2 From Engle 2019-01-14 04:36:53 -------
(In reply to comment #1)
> One question would be whether the
> replacement parameter should be a regular expression for even more flexibility
> or whether a simple string would be sufficient.

Since RegEx is so much more flexible, this seems like the reasonable choice.
------- Comment #3 From Axel Grude 2019-01-14 07:30:49 -------
Created an attachment (id=8582) [details]
2.1 pre 48

Here is a fresh test version, I decided for the 2nd variant (replacing the
group parameter). 

Here was my test case:

%header.append.matchFromBody(subject,"SmartTemplate4"," [ST Test Matched]")% 

This Reply-template searches in the (replied to) email's body for the text
"SmartTemplate4".

If the text is found, then the term 
" [ST Test Matched]" is appended.

note - none of the text arguments may contain double quote characters,
otherwise I cannot guarantee for it working. Also, do not use "[" or "]" in the
search parameter unless you want them to be interpreted as character classes
(e.g. "[abc]" matches a single character a or b or c)
------- Comment #4 From Engle 2019-01-15 01:17:58 -------
My first test were successfull. Thank you!

I will try this out on real life cases and also try to match to subject
contents. I'll let you know how it goes.
------- Comment #5 From Engle 2019-01-15 05:42:48 -------
I have tried it out in a real life case and it seems to work perfectly.
Thank you also for the tip about the RegEx format. I have however used escaped
square brackets (because they are part of my actual search string) and this
works well without issue:

%header.append.matchFromBody(subject,"\[searchString.+\]","replaceString")%


One more thing (of which I'm not sure if this here is the right place to ask):
with activated plugin and composing an email (opposed to replying) the cursor
sits at the end of my "reply to" field. With deactivated plugin it is where I
expect it, in the "to" field (so I can start typing right away).
This is not in connection to the append.matchFromBody issue.
Is there a way to tell the plugin to put the cursor in the default "to"
position?
------- Comment #6 From Axel Grude 2019-01-15 07:02:34 -------
(In reply to comment #5)
> I have tried it out in a real life case and it seems to work perfectly.
> Thank you also for the tip about the RegEx format. I have however used escaped
> square brackets (because they are part of my actual search string) and this
> works well without issue:
> 
> %header.append.matchFromBody(subject,"\[searchString.+\]","replaceString")%
>

when I tried this (using the string "\[SmartTemplate\]" ), it actually matched
single letters (such as S, m, a, r) even when I used the escaped parentheses.
Can you confirm that you do not get such "false positives"?

> 
> One more thing (of which I'm not sure if this here is the right place to ask):
> with activated plugin and composing an email (opposed to replying) the cursor
> sits at the end of my "reply to" field. With deactivated plugin it is where I
> expect it, in the "to" field (so I can start typing right away).
> This is not in connection to the append.matchFromBody issue.
> Is there a way to tell the plugin to put the cursor in the default "to"
> position?

you're right - this is not the correct place to ask, that would be for a
support mail or a new bug. I personally cannot reproduce it (my cursor ends up
in the "to" field, I specifically wrote code for this behavior), so maybe add a
bug for it (are you using a Thunderbird template?). Also make sure not to use
your %cursor% variable for the "Write" template.
------- Comment #7 From Engle 2019-01-15 07:10:55 -------
> Can you confirm that you do not get such "false positives"?

It seems to work fine.
My actual case is to catch the string [commMgrTok:XXXXXXXXXXXX]
"\[commMgrTok:.+\]" catches that perfectly. I tried it on an email containing [
c o m m M g r T o k :XXXXXXXXXXXX] and as intended it did not match.

Thanx, I will open a new bug about the other thing ;)
------- Comment #8 From Axel Grude 2019-07-28 06:44:16 -------
Complete: Release 2.1 - 28/07/2019

First Last Prev Next    No search results available