Cancelling group invitations does not always cancel the invite request

XMLWordPrintable

    • 10
    • Severity 2 - Major
    • 2,093

      Issue Summary

      • If a user has been invited to multiple groups (ie they were automatically invited to default group, but then added to Admin user group) - cancelling one of those groups doesn't update the "last sent" date and therefore does not re-send the invitation via SMTP
      • Essentially, the invitation request is a collection of child group invitations - if one child group is cancelled, this does not cancel the entire parent invitation request
      • This creates a problem when a user isn't able to receive email notifications - as this behaviour creates problems for the administrator

      Steps to Reproduce

      1. Have a user invited to more than one group (ie Default user group and Administrators)
      2. Cancel the invitation for one of these groups, the invite date does not update for that group, and no email is sent via SMTP logs (as the entire invite was not cancelled)

      Expected Results

      1. The invitation is cancelled for that particular group, adding the user again correctly reflects the new sent date and the notification to this new group is considered a seperate invitation and is sent via SMTP

      Actual Results

      1. We've had a case where a user was invited to two groups (default group and Administrators) - they had notifications disabled on their Atlassian account and didn't receive any invites.
      2. They re-enabled their notifications, but having their invitation cancelled/re-added did nothing as both group invites were not cancelled - therefore SMTP never triggered a fresh email (as the parent invitation request was not considered fully cancelled).

      Workaround

      • Manually scan through each group, ensure that a user is not invited to multiple groups at any given time - make sure to cancel each and every group invite before attempting to add them again
      • Ideally, decoupling group invitations from each other should prevent this issue from occurring in the first place

              Assignee:
              Unassigned
              Reporter:
              Ben
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated: