The change has been rolled out to our site today. And it caused an issue, as looks like the segregation of users can not be configured (or I missed something?).
So now every Jira user automatically received permission to ALL JSM projects, thanks to the new role. I tested, and yes, if I add this role to a user, it grants access to every project. Now, internal users see all external customer facing projects and portals, and can open issues too. I hope this can configure somewhere, othervise it is a huge security concern, and has big data protection issues!
At the end, we should keep the old way to be able to limit users to see only a project where they should see things.
I have access to two User Profiles one is Admin the other my own day to day use. I have limited users over all just 10.
My own user profile has access to a lot of projects, one that I know I don't have access to allows me to see some of the admin features , but it would not let me see the tickets nor will it allow me to create any tickets. and see information in the frames.
Some of the messages I'm getting.
Oops, something went wrong! You must have the browse project permission to view this project
You cannot create issues in this project.
This project isn't available It may have been deleted or your permissions may have changed
I just got a work colleague across the country to try and access a link to a project, they don't have access to and they confirmed they don't have access, as expected.
I have now searched through the admin / user management pages of a site that received this update and I cannot seem to find a dedicated setting for granting this Customer role?
It seems the naming is redundant with the existing "Customer access" and (at least for me) currently a bit confusing. Is this new feature covered via the Product Access -> Customer Access tab?
If we are using the API to add portal-only accounts, the current endpoint is to post to /customers. This seems a bit confusing with the new naming scheme. Is this still the appropriate way to automate adding external accounts?
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Please add a section to your text describing, how this will affect Atlassian Access and the sync of users from AzureAD. I need to have all AzureAD-users, which are synced via Atlassian Access to be in the new role of "customers".
@Ash Young 1. we already had Customer access configured and 2. this might have broken the url for people to get JSM product access as Agents JST-900369
Don't have the time to read all the existing comments so maybe this has been covered but is causing us issues.
Since this new group was added, new Atlassian users on our site are now blocked from accessing our Help Centre. Previously, as long as they came from a valid domain (we use allowed domains for our Help Centre) they could access.
Now, they also need to be part of this group as a requirement and are blocked from accessing our *single* Help Centre.
Are we missing something here? Is there some extra setting we need to tick now? The communications above clearly said there's nothing more for us to do and access won't be affected, so this is simply not true for us.
We have the same issue as @Chris Tolley - this change broke our new user onboarding - now our users aren't automatically made customers, so they don't show up in User-Picker lists and don't have access to the Help Center Portal, which is a big setback for getting their access requests set up, equipment provisioned, etc. We provision accounts via Okta automatically. Now with this zero-day warning about the change, we're searching how to fix this. How do we make new users of a domain have the Customer role enabled automatically?
We have a unique situation with the same topic which you discussed above and we are migrating from DC to Cloud this month. We have enterprise subscription for cloud. Could we have a meeting setup with you to discuss about this scenario and possibly find a solution for our problem. Its really hard for me describe the issue that we have here. If you are available for a meeting we can schedule one a discuss further, or please let us know how we can get in touch with a Atlassian Product Manager who works on JSM.
I'd point you towards the "Approved domains" feature and check you've configured that users from your domain are provisioned the "Customer" role when accessing JSM.
Hi @Justin Huang by approved domains I meant this process which I suppose is called restricted domains.
The approved domains process you linked here is not used by us, because we have a specific process in place where users should not be able to freely sign up to our site. We need users instead to raise a ticket via JSM for full licensed access to our site, rather than just being able to join via allowed domains.
Are you saying that allowed domains is the right approach here for this new Customer role? Following this logic, do we need the list of allowed domains to match our restricted domains via my link atop this comment? Doesn't this just mean we're having to put the same domains in two places, when we already have approved domains via "restricted domains"?
EDIT/UPDATE: Today we've tried granting the Customer role through allowed domains to "any domain" and this allowed anyone (tested with a personal email account) to access our portal. So that seems to overrule any restricted domains set in JSM portal settings. So the only way I logically see this working is if we list all approved domains (we have over 40) in the approved domains section to copy the domains listed in restricted domains. Doesn't make much sense to me!
115 comments