Starting in September, they are planning on enforcing a limitation to the number of grants per permissions scheme of 50 total grants. I do understand the rationale for this. However, in my opinion, it is completely unrealistic that we could achieve this limitation.
From what I have seen, most of our permission schemes have in the neighborhood of 45 permissions on each. For example, we have one that has 46 permissions on it, which means only 4 of those can have more than 1 grant applied in any one scheme.
Additionally, making it even more unrealistic is the fact that the 'atlassian-addons-project-access' gets automatically applied to each permission by Atlassian if you have any add-on apps (which I assume nearly everyone has at least one of as they are extremely common for expansion of functionality). We did not create this role, we cannot prevent its usage, and in many cases we cannot safely remove it without a negative impact to application functionality. However, once you factor the automatic additional and assignment of this role into the process, it leaves only 5 permissions in total that we are able to self-assign.
I hope we are not the only customers to be in this predicament. Please share your thoughts on this Atlassian-planned restriction. Thanks for your insight.
Sorry all. I jumped the gun on submitting this. I have just found out from Atlassian that the limit of 50 grants is on each individual permission within a scheme, not a grand total for the entire scheme.
Sorry for any alarm and/or confusion as a result of my premature submission on this discussion group.
Noob question but in their vernacular is "Grants" now the new code word for the "Assigned To" count?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The in app messaging is extremely poor. I read it the same way you did and was freaking out a bit.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, that is correct. What they are referring to is that each person or group being granted/given access to each permission in the scheme is considered 1 "Grant", and they will only be allowing a maximum of 50 per permission.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you for the clarification. I was just starting to go down the same spiral of "How am i going to make this work". Atlassian should really adjust the warning message for this.
For anyone looking for official document with the per permission wording i found the below:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Started seeing a yellow "Starting in September, permissions will be limited to 50 grants" message today in our instance. After selecting the Optimize link it then shows a report with the ### number of grants.
If the 50 grants is per project permission type, then Atlassian needs to clarify this in their message. The grant number in the optimize link report also gives the impression I'm way over. As I look at this more objectively, it makes Atlassian sense, but I think a lot of admins are gonna freak out, like Tim and myself. :-P
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
A support rep actually just sent me to this thread to tell me other people are bringing it up. He didn't mention though that it is PER line item. Confirming now in that support ticket. I certainly hope its as you guys mentioned, and its per item. That's easy to stay within. 50 across the entire thing? Especially when addons is a forced line item everywhere? That's about impossible.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Rep confirmed on my end too. It is 50 per line item. So a limit of 50 to Browse Space. A limit of 50 to Add Attachment, etc.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you @Tim Bonney for this post.
And it is not on you.
It is on Atlassian for phrasing this in the most mis-understandable way possible.
I clicked on the "optimize check"y thing and this also only showed a total, to reinforce this misunderstanding.
@Atlassian shouldn't you know better by now?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Even Rovo misinterpreted the banner when I asked it about it :/
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I feel like Rovo misinterprets most things ...
Seriously, I cannot count on two hands the number of random hidden settings Rovo has suggested I change or look into that just don't exist. Usually from some feature setup that hasn't existed in 3 years. Or when it told me there were special Bitbucket audit log features you get for premium that have never existed.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
It also likes to correct me about Jira spaces being called projects and spaces only existing in Confluence
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.