we use JETI since several months to send notifications to non-JIRA users, based on JIRA events. To do this, we added a custom field on issues, and configured JETI to get the recipients emails addresses from this field.
After all these months, it appears that for some issues, emails are never sent by JETI. It was not simple to identify as for a lot of issues, emails are sent as expected.
We first thought of a problem in our JIRA configuration, or our mail server. But it appears to be simply due to the lack of support of the whitespace separator in the emails recipients list. JETI doesn't complain of this problem (no error messages, and no clue in the Email Log page). Maybe we don't know where to look, but it was not obvious to find the reason.
External watchers: firstname.lastname@example.org,email@example.com,firstname.lastname@example.org
External watchers: email@example.com firstname.lastname@example.org email@example.com
A quick manual overview on our JIRA database shows that we may have hundreds of issues impacted by this problem, and this is not simple to fix. JQL is really not intended to search for whitespaces or commas. So we don't have yet a simple way to fix it. As this field is set by human users, they don't always put commas as separator. We can't blame them, as it is a standard behavior in JIRA (like in the label field where whitespaces are used, and not commas).
So, we hope you could handle whitespaces in the emails list. These should not break any existing behaviour in JETI, as whitespaces are not allowed in an email address.
Please let us know if you could help us.
in our case, these are just basic spaces ' ', but we guess handling any kind of whitespaces would be great.
Thanks in advance.
the problem with spaces is that JETI accepts this email address format: "John Smith <firstname.lastname@example.org>" and it contains spaces. So if we want to split on spaces, this format will fail.
Ok, we didn't know this was possible. In our case we will never have entries of the form "Firstname Lastname <email>".
So, do you think it is possible to add an option in the settings to enable spaces support? The option would be inactive by default, so the current behavior won't change.
Support for spaces (not whitespaces added). if email addresses in external form (FirstName LastName <email@example.com>) are in the values, spaces are discarded as separators.
This feature or fix has been released in version 220.127.116.11 and 7.0.16