Forum Discussion
Modern teamsites - unable to change permission level for security groups
I noticed that for a newly created modern teamsite (via New-PnPSite) I'm unable to change permission levels for the out of the box security groups. For example, I go to /user.aspx and put a check mark in front of a security group. Usually, the "Edit User Permissions" and "Remove User Permissions" menus become selectable.
However, for modern teamsites they remain greyed out although I'm a site collection admin:
The unfortunate thing is is that I can grant additional permission levels through the leftmost "Grant permissions" button but because "Edit User Permissions" is always greyed out, I cannot remove them.
Any idea why that is?
Thanks
- The button may be grayed out but the Edit Permissions page is still there and working, just need to figure out and manually enter the URL to it..
1) Go to your permissions page https://myorg.sharepoint.com/sites/mysite/_layouts/15/user.aspx
2) click the group you want to edit, and note the groupID from the url
https://myorg.sharepoint.com/sites/mysite/_layouts/15/people.aspx?MembershipGroupId=6
3) Navigate to the edit permissions page of another group (it seems to work for the non-default ones) and change the groupId query in the url to the one you want to actually edit
https://myorg.sharepoint.com/sites/mysite/_layouts/15/editprms.aspx?obj=https%3A%2F%2Fmyorg%2Esharepoint%2Ecom%2Fsites%2Fmysite%2CWEB&sel=6
replace myorg and mysite in both the domain and query string, and replace 6 with the group id you want to edit- Fantastic - thank you that worked! Although did not solve that horrd 'limited access' assigned by Microsoft. In the end I just created custom security groups 🙂
- Thanks!
This is a known limitation on the Owners, Members, and Visitors groups in a Team site (actually on all Office Group sites). I wrote a Blog post about the issue, and a potential workaround, that you can read here:
Thanks, this is quite interesting. Another thing I found out is that the GUI let's you assign the security group itself two different permission levels:
But, contrary to classic teamsites, you cannot change/remove them afterwards since "Edit User Permissions" is greyed out. Quite Frustrating I might say.
Deleted I have found you have to allow custom scripting on your site. This is turned off by default.
Set-SPOsite -Identity "https://unitedchurch.sharepoint.com/sites/YOURSITE" -DenyAddAndCustomizePages 0
I then have to wait a few minutes and refresh the page, once it's done you can edit your permissions like you could before.
I am able to partly reproduce your behavior in my tenant, only for the first part in which the buttons remain greyed out for the default created Groups. When I grant permissions using leftmost Grant Permissions button I am able to use both buttons afterwards
I don't know exactly why this is, but I can imagine it's to protect you from messing up the permissions with regards to the underlying O365 Group that's created for modern team sites and keep the basic permissions model controlled through O365 Group settings working.
paulpascha I found that despite being an Administrator and an Owner for a site, I was unable to change permission levels for a security group after Microsoft had assigned the "limited access" permission level to the Owners or Members security groups (of which I was a member). The "limited access" permission level is apparently assigned when a user shares a document/list with someone who is already a member of the Sharepoint Site (LOTS of Sharepoint/Microsoft community blogs and complaints about this). The problem is you cannot delete the Limited Access permission level and you cannot remove the Limited Access for the security groups to which assigned (greyed out).
The way I got around this is to create two Custom security groups (CustomOwner and CustomMember with the required permission levels) .... and added the applicable staff/O365 Groups with these custom groups. Not sure whether that horrid "limited access" will pitch up again for the custom security groups if an item/document is shared; I am too nervous to test after so many hours researching these issues
