Access changes
Background
We have historically had ‘interactive’ users authenticated by AtlassianID able to create support issues interactively. Whilst this worked, it created several pain points for us and customers:
adding more people was over complicated as we had a hybrid portal / interactive model including issue security level
Customers could sign up for a portal account with email X then, later login with AtlassianID with email X. This causes us headaches when looking up email addresses for users and typically getting the wrong one (we’d see 50:50 users either using the Portal or Jira interactively)
The Plan
We planned to remove all users not accessing our site in May/June and get them to sign up for a Portal account. Removing users site-access was a headache, Atlassian don't give even a page level bulk change for 20 users, lots of clicks.
Once we had old users revoked of site access we ran into what seems to be JSDCLOUD-6042 that prevented portal user account creation for any pre-existing or event deleted account, whether it was involved in an issue or not - some workarounds for admins have now been posted.
Confluence
Confluence was relatively simple, we enabled public access, removed group level access for right to use and done. Available anonymously:
Jira
It seemed straight forward, revoke users, push to Portal to create users, done. Well, no.
Options
If we left the revoked users as is, when accessing our site (which is available anonymously) they would not be considered as anonymous, would not be able to access our Wiki and would just hit a ‘not authorised’ kind of error.
If we finally deleted the revoked users, then they would be able to access the Wiki, but due to JSDCLOUD-6043 would not be able to sign up for a Portal account using the same email. We found that users could register a Portal account using their main email with a sub address, e.g. (bold) user+pluginpeople@domain.com, we thought it would be a simple thing to just change the email after the fact, right? Enter JSDCLOUD-5746 ‘future consideration’. That path looked messy.
Re-enabling the revoked users but removing app access was the only other option, which allowed those users only to access our site using their AtlassianID, to access our Wiki and have default access to our site (https://thepluginpeople.atlassian.net/) redirect to the Portal view. New AtlassianID users would still be able to get to the Wiki, but would still have to create a Portal account, being a 'new' AtlassianID user unregistered with our site, they will not hit JSDCLOUD-6043.
More clicking
So, we for the second time (lack of bulk change, lack of API: ID-7710), we had a clickathon to re-enable existing AtlassianID users with site only access. Done, for now. We still have lots of ‘interactive’ users registered.
New AtlassianID user friction
We don’t currently seem to be able to allow AtlassianID users to automatically gain site access without getting application access. If this were ever possible, we could use the ‘per-user’ migration tool to migrate issues from one user to another (seems like this is just a reporter bulk change).