Business rule criteria "begins with" doesn't work as intended with HTML-emails as "description"
Hello,
We are using ServiceDeskPlus 9.0 Build 9017, and o ur workflow is to have incoming emails (to the servicedesk address) being sorted based on description (email body) content : different rules to dispatch the requests, and we are using "description begins with" criteria.
Note : The requesters can't be asked to pre-format their sollicitations to include the e-mail commands (@@@ and @@x=y@@ stuff) to ensure proper attribution, that was deemed "too complicated". In the same way, we can't ask to modify the subject of the email to inlude the desired keyword there, even with ends-with...
So our scheme is to have the requester use the first word of the email being the name-type of the request (various forms are recognized as the same, for example net/networking/network/firewall/router as a networking task, and bill/accounting/commercial as another task), then type whatever they want as a task description.
The problem is the following :
Here are the relevant test cases (this is the email message source received by SDP) :
Case 1 : plain text email with task name ( begins with rule matched ok)
Case 2a : html text email with task name and no whitespace before the keyword (begins with rule did not matched)
Thanks in advance for your feedback
Don't hesitate to ask for more information if needed.
PS : there's a wrong "solution" to this problem we found : we tried to use "contains" with keyword, or keep "begins with" but change the value to *keyword. It actually works with html emails... but introduced a bad classification of the emails, because of rules order match. For example, let's say rule #1 matches network task, and rule #2 matches accounting task, then a with a "contains" criteria, a body containing both "network" and "accounting" words (wherever they may be) would always match rule #1 as it's evaluated first (or the opposite if we reorder rules). TL;DR that's why we need "begins with" criteria, so the two rules are mutually exclusive even if both keywords are present in the description.
PPS : Another clean solution would be to consider each criteria value as a regexp (instead of simple string+wildcards) so that we could actually prefix each keyword with a regexp matching "non-visible" markup (ie whitespace & other non-printed tags) : that way, it would match both plaintext and html-based emails... but that doesn't very "clean".
We are using ServiceDeskPlus 9.0 Build 9017, and o ur workflow is to have incoming emails (to the servicedesk address) being sorted based on description (email body) content : different rules to dispatch the requests, and we are using "description begins with" criteria.
Note : The requesters can't be asked to pre-format their sollicitations to include the e-mail commands (@@@ and @@x=y@@ stuff) to ensure proper attribution, that was deemed "too complicated". In the same way, we can't ask to modify the subject of the email to inlude the desired keyword there, even with ends-with...
So our scheme is to have the requester use the first word of the email being the name-type of the request (various forms are recognized as the same, for example net/networking/network/firewall/router as a networking task, and bill/accounting/commercial as another task), then type whatever they want as a task description.
The problem is the following :
- everything works perfect with plain text email, the rule matches the first word, and the request is correctly classified
- it doesn't work with html-based emails, and we guess it's due to the email actually starting with html markup and whitespaces, which prevent the "begins with" to actually match. Nothing matches, and thus the request is not classified
Here are the relevant test cases (this is the email message source received by SDP) :
Case 1 : plain text email with task name ( begins with rule matched ok)
-
Content-Transfer-Encoding: 8bit networking
Case 2a : html text email with task name and no whitespace before the keyword (begins with rule did not matched)
-
Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body text="#000000" bgcolor="#FFFFFF"> networking<br>
-
<html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body text="#000000" bgcolor="#FFFFFF"> <br> <br> <br> <div class="moz-forward-container"> networking<br>
Thanks in advance for your feedback
Don't hesitate to ask for more information if needed.
PS : there's a wrong "solution" to this problem we found : we tried to use "contains" with keyword, or keep "begins with" but change the value to *keyword. It actually works with html emails... but introduced a bad classification of the emails, because of rules order match. For example, let's say rule #1 matches network task, and rule #2 matches accounting task, then a with a "contains" criteria, a body containing both "network" and "accounting" words (wherever they may be) would always match rule #1 as it's evaluated first (or the opposite if we reorder rules). TL;DR that's why we need "begins with" criteria, so the two rules are mutually exclusive even if both keywords are present in the description.
PPS : Another clean solution would be to consider each criteria value as a regexp (instead of simple string+wildcards) so that we could actually prefix each keyword with a regexp matching "non-visible" markup (ie whitespace & other non-printed tags) : that way, it would match both plaintext and html-based emails... but that doesn't very "clean".