Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Available since JEMH 2.7.3

Table of Contents




JEMH has always had Cleanup Expressions (used to remove content from message subjects and body) and Body Delimiter Expressions (used to chop signature text as well as reply-to content).  It worked, but it had two main usability problems:

  1. the fields Fields involved were comma separated regular expressions, which was complicated to manage and had side effects on usability (like matching comma literal characters)
  2. the expressions Expressions were global within the Profile, so applied to all issues regardless
  3. understanding Understanding what the impact of a change would be required (a) saving the profile (b) running a test case to (c) view created issue and see the result


What has changed

In JEMH 2.7.3 we address this area by migrating the CSV expressions from the Profile level down into Project Mappings, which is how JEMH is evolving (closer to the sister product JEMHC view).

its implicit now, the Global ones are pre-directive, the Project Mapping ones are post-directive
WhatWhere is it nowNotes
Profile Subject CleanupsRe-titled named Global Subject CleanupsYep, still CSV regexpValues are entered as regular expressions, separated by commas (CSV).
Profile Body CleanupsRe-titled named Global Body CleanupsYep, still CSV regexpValues are entered as regular expressions, separated by commas (CSV).
Body Cleanup Mode?OrderRemovedSetting removedGlobal cleanups at the profile level are applied before directives processing. Project Mapping cleanups are applied after directive processing.
Body Delimiters

Migrated into

  • Project Mappings > X > Pre-Processing > Cleanup Expressions
  • Project Mappings > X > Pre-Processing > Body Delimiters

The pre-migrated body delimiter expressions could be prefixed with a \n expression for newline, which limited the number of matches to the number of lines in the email, this reduced regexp matching for large emails from billions to a few K (impact of this was processing time).

As part of the migration, each historic CSV regexp value was evaluated, and if it started with a \n, had it removed.  The reason for this is that ALL Body Delimiters are now prefixed the \n at evaluation time, ensuring that the evaluations are as safe and optimal as possible as well as minimizing the repetitive nature during entry.


Old Profiles can be imported into 2.7.3, which will re-run the same transference of also migrate Body Delimiters from the Profile level to the Default Project Mapping.

Project Mappings


Body Expressions are required to match the line of text that prefixes 'replied to' content.  This content is unknowable, depending on your OS, mail client, Locale, othervaries depending on the email client used and the locale of the client user.  Effectively its it is just text so we must match it as closely as possible.  As mentioned above ALL delimiter expressions are evaluated with a \n prefixing them to minimize the number of matches.  This also works at the start of the email content as \n is dynamically injected for that case, and removed after.  Its better to range match on expected text than take the 'lazy' .* route, bad regexps that overuse .* can cause A LOT of possible match evaluations by the Regexp Engine.  If your Jira stops processing mail, one possible causes is an overuse of .*, the Regexp Engine is busy, it could take a few hours, days or longer to complete owing to the combination of Regexp and email size.