|
[
Permlink
| « Hide
]
Jeff Turner [Atlassian] added a comment - 25/Oct/05 12:04 AM
Thanks, we'll take a look at this for 3.5 ('merge' might be a bit tricky - we need to integrate into our existing handler rather than just create a new one).
You probably want to be able to chain "processors" to a handler - and have different processors for different email types
However, adding it as-is to 3.4 would also be useful for a lot of people - not least us I think you want to do something like filters in Jive...
> I think you want to do something like filters in Jive...
We do indeed > However, adding it as-is to 3.4 would also be useful for a lot of people - not least us Anton Come on....
It has tests and everything... -Nick Just for information sake, are you aware that the NonQuotedCommentHandler looks at the outlook-email.translations file for delimiters of quoated messages? Only the direct matches are now found, no regexps. Adding regexps would be the next stage.
Yep - saw that when I started writing Regex....
The regex handler is a splitter-only. Thanks for the code Nick, it's loaded and ready to go in 3.4!
Nick,
Out of curiousity, is there any reason why you didn't just add more lines to the outlook-email.translations file and use the NonQuotedCommentHandler Cheers Mark C Yeah, if there is some variation on the seperator format that you havent accounted for, you have to do a re-deploy to fix it
If I do something like >> Quoting something deliberately Will my quoted bits get axed by the NonQuotedCommentHandler? That would axe all lines except "here".
Thats what I thought...
Thats not ideal... Ouch. Not sure if you noticed, but my last test was complete shite.
Should have been String processedComment = regexCommentHandler.splitMailBody(rawEmailbody);
(rather than regexCommentHandler.splitMailBody(expectedComment)) Not entirely surprising, when you make that change, the test no longer passes. params.put(KEY_REGEX, "/Extranet\\s*jira.london.echonet/FMB/UK/EUROPE/GROUP@CRAPPYLOTUSNOTES/");
Its only the test thats borked - the actual implementation is fine....
(this unit testing .... will never catch on....) This is a great handler for commenting, but it would be even better if it could create issues too. Can it be combined with the vanilla "create or comment" handler but retain the regex for commenting?
Daniel,
This is not currently possible. You will need to customise JIRA's CreateOrCommentHandler to do this. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||