Hi there,

While I suspect this was never so relevant for Jira Cloud, much time has passed and I wonder if there is still the need for this level of customisation. In the meantime, there are some changes in the pipeline that might also help to mitigate some of the other issues expressed in the comments above:

https://confluence.atlassian.com/jirasoftwarecloud/blog/2019/02/jira-emails-are-changing

In light of that, it doesn't align so well at the moment to allow this level of customisation in Jira, and we are actively working on other measures such as the above to improve the experience.

I'll close this ticket for now, but feel free to comment further if additional needs should be raised.

Oliver

Um, for what its worth, I approached this by (a) getting the project to remove its reference to the notification scheme, (b) using my own issue listener, hooked up to the users re-selection of said notification scheme through my plugin. As JIRA is not aware, the result is the same.

I don't think this is going to happen. It might one day if JIRA PMs revisited the whole mail infrastructure in JIRA - some projects need best-effort, immediate notification (think IM, SMS). Others need reliable email. Both need ways to reduce the number of notifications people get. I see a lot of filtering of JIRA messages out there.

Hmm, 4.4 EAP? seeing as not in 4.4, maybe 4.5? fingers crossed, again.

I'm upgrading a customer and one of their custom plugins needs this. I'm providing a patched system class to avoid it, which isn't very good practice.

If this isn't going to be addressed, could the documentation at least be updated so as not to get our hopes up?

Just making ConsistencyCheckImpl not check isn't the only thing that needs doing. Some part of the install process would need to do the initial setup of listener. Subsequent deletion (and somehow notifying the admin of this) could be handled a bunch of ways. Fingers crossed for 4.2.1

Technically, this issue's summary should read "Unable to stop JIRA recreating the default/internal Mail Listener", since it can be deleted via a URL. It would be worth checking whether that last assumption is still true in 4.2.

So, not in 4.2, bah. 4.2.1? please?

It's a right pain to do custom mail listeners with this problem in existence.