I'm having trouble figuring out whether JEMH is supposed to accept directives throughout the email or just at the first line. I've found this in the documentation:
The handler assumes that the first line(s) of an email may contain Directives. Generally, a single empty line after any Directives indicates the start of the Comment. If no Directives are found in the body at all, the whole email is used as the Comment (subject to minimum criteria being met, defaults found etc). The exception to this rule is the SubjectBasedFieldProcessor, which works for most options, is unable to be used for all options.
It seems to sort of imply that directives can be throughout the body, but maybe not. In my testing, JEMH has not been picking up directives unless they are at the top of the email.
Is there any way to configure JEMH to pull directives from anywhere in the email?
Thanks,
Matt
Short answer: No, body based directives are expected to precede 'content' that would be taken as 'comment content'. All examples illustrate this.
Longer answer: This allows those directives to be removed and not form part of the 'comment content'. Multi line directives may exist in JEMH directives, but the rider is that the last directive must not be a multi line, and a double CR signifies the end of directives.
Custom email field processors can be written, e.g. Nagios, eg Wufoo, each of which is tailored for a specific kind of content.
Once JEMH 1.0 ships as a p2 plugin complete with UI and so on, future extensions will allow you to write scripted 'custom' field processors without any recompilation.
Meantime, If your source is generic, perhaps a handler for such a source could be written.
Andy,
Thanks for the clarification. I look forward to seeing the 1.0 release, as I've just discovered JEMH and have quickly become a fan.
Perhaps allowing directives to be at the very end, or creating something like @JEMH_START and @JEMH_END directives would serve to alleviate concerns of unpredictable behavior of processing the whole body?
How would one go about implementing such a handler on top of JEMH?
Thanks,
MN
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
This issue tracked https://studio.plugins.atlassian.com/browse/JEMH-483
A key feature of 1.0 is to get more control over which Field Processors are enabled. Markers for directive blocks are certainly possible, https://studio.plugins.atlassian.com/browse/JEMH-484 duly created.
Regarding implementing new handlers, Im afraid JEMH is now closed source, to enable to me to justify ongoing development (such as a UI and more). My intention is that once 1.0 is all happy with JIRA5, future work will provide a UI based scripted field processor, allowing 'custom' things to be done, as well as a possibly enabling a pluggable interface for other handlers (deploy your plugin that JEMH can then defer to).
Rgds,
Andy
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Google says this is moved to https://thepluginpeople.atlassian.net/browse/JEMH-483
But then I see "This issue can't be viewed"
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
If we pre-process to strip off any content prior to the directive block is there a way to get the directives embedded in the content to work?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.