NOTE: This bug report is for JIRA Server. Using JIRA Cloud? See the corresponding bug report.

      Regarding the default/internal MailListener, the documentation states:

      This listener is usually always turned on in JIRA - see Email Notifications for more details. If you want to write more complex or more specific notifications, you can disable the internal MailListener and add your own.

      However, as the MailListener is marked as 'internal', it is not possible to be remove it.

      At present, it is necessary to recompile the MailListener class and set isInternal to false.

      Need to allow users to delete/remove the MailListener through UI.

            [JRASERVER-19957] Unable to delete the default/internal MailListener

            Of course yes, but nothing prevent you for deletion this standard listener at startup.

            Denis Sheluhanov added a comment - Of course yes, but nothing prevent you for deletion this standard listener at startup.

            Matt Doar added a comment -

            Right, but when you restart Jira I think the DefaultMailListener is recreated if it is not present?

            Matt Doar added a comment - Right, but when you restart Jira I think the DefaultMailListener is recreated if it is not present?

            Sure, https://docs.atlassian.com/software/jira/docs/api/7.2.2/com/atlassian/jira/event/ListenerManager.html#deleteListener-java.lang.Class-

            And in your listener:
            @Override
            public void init(Map params)

            { ListenerManager listenerManager = ComponentAccessor.getComponent(ListenerManager.class); listenerManager.deleteListener(MailListener.class); }

            Denis Sheluhanov added a comment - Sure,  https://docs.atlassian.com/software/jira/docs/api/7.2.2/com/atlassian/jira/event/ListenerManager.html#deleteListener-java.lang.Class- And in your listener: @Override public void init(Map params) { ListenerManager listenerManager = ComponentAccessor.getComponent(ListenerManager.class); listenerManager.deleteListener(MailListener.class); }

            Matt Doar added a comment -

            But can you delete the DefaultMailListener?

            Matt Doar added a comment - But can you delete the DefaultMailListener?

            Denis Sheluhanov added a comment - - edited

            Maybe it is time to close this issue as there is now com.atlassian.jira.event.ListenerManager#deleteListener

            Denis Sheluhanov added a comment - - edited Maybe it is time to close this issue as there is now com.atlassian.jira.event.ListenerManager#deleteListener

            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.

            Andy Brook (Javahollic Software) added a comment - 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.

            MattS added a comment - - edited

            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.

            MattS added a comment - - edited 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.

            Andy Brook (Javahollic Software) added a comment - - edited Hmm, 4.4 EAP? seeing as not in 4.4, maybe 4.5? fingers crossed, again.

            MattS added a comment -

            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.

            MattS added a comment - 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?

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

              Unassigned Unassigned
              73d805a2526b MattS
              Affected customers:
              43 This affects my team
              Watchers:
              32 Start watching this issue

                Created:
                Updated: