Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-19874

CreateOrCommentHandler should fall back to defaultreporter if email user does not have permissions to perform operation

XMLWordPrintable

    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

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

      With the current mail handler, if Jira receives an email whose address is associated with a user that does not have permission to comment or create issues, the email is rejected. However, if the address is not associated with any user, and the handler has a reporterusername, then the comment will be added as that default user.

      This ends in the absurd situation where a non existing user can add comments to a case, but an existing user cannot. This user could then create a bogus email account to add comments to the issue.

      In my understanding, the logic of the handleMessage/getReporter mail handlers should be changed. For the previous case (existing user but no permissions) the logic should be:

      1. Get user from email
      2. If user exists, check if user has permission to perform operation
      3. If no permissions, fall back to reporterusername

      I am aware that JRA-16786 was raised in the past with a similar request, and the functionality was claimed to be like that by design. However, I think the situation I describe is a flaw in that design.

      If the logic was as described before, we could have avoided creating the proxy commenter for SAC to fix JRA-15431. The proxy commenter performs the logic as described before (with some additional magic)

              Unassigned Unassigned
              dalonso Diego Alonso [Atlassian]
              Votes:
              4 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: