Assigning "Contribute" permission instead of "Edit" to the SharePoint Modern Team site's Site members

Question

I have created a new SharePoint Modern Team site and i got 3 security groups created for us, as follow:-

but the problem i am facing is that the "Site members" will have Edit permission, while i want them to have "Contribute". and modifying this from the UI will not be possible, as the "Edit User Permission" will be disabled, as follow:-

now i read many links about this problem, and seems we can modify the Edit permission level using power shell, but lot of folks mentioned that this is not recommended..

Also recently i came across this link Changing Default Permissions in Office 365 Group Sites and the author mentioned that we can overcome this problem by adding a new security group inside sharepoint and grant it Contribute permission. But if i create a new sharepoint security group and i grant it a contribute permission (while i leave the built-in "Site Members" which have Edit permission level empty), then i will loose the benefits of having a real SP modern team site? is this correct?

I mean sharepoint modern team sites, assume that the built-in "Site Members" contain users, so they can use the shared calendar,shared mailbox, planner ,etc.. but having users added to the sharepoint modern team site using a sharepoint group (rather than relying on the office 365 built-in "Site Members" ) will minimize the benefits of having a real Office 365 modern team site, as users added to the custom sharepoint group (which have contribute permission) will not be able to use the Office 365 Group's features mainly; shared calendar, planner, mail box, etc.. is my point valid? and maybe it will be better to have a communication site instead of having SP modern team site in this case? so can anyone advice on how we can change the default Permission in sharepoint modern team site for the Members groups, from Edit to Contribute?

Answer 1

The blog you linked to has the correct answer. It's not optimal, but it works.

One source of confusion is that after creating a team site, there are two groups with the same name. For example, if you create a new team site named "project 1", the following groups will be created:

• "project 1" - This group is visible in the list of groups in the admin console. The admin console will show that this group has an email address, and a group type of Office 365. The admin console will also show the list of owners and members. When viewing the home page of the site, it will display "x members" at the upper right. clicking on it will display the members of this group.
• "project 1 members" - This group is visible by navigating to site permissions --> advanced. This page will show this group (plus others), and it will have a group type of "SharePoint Group". This group will have a default permission level of edit
• "project 1 owners" - same as above, with a permission level of full control
• "project 1 visitors" - same as above, with a permission level of read

If you click into the project 1 members SharePoint Group, you will see that it has one member by default: "project 1 Members", which is the members of the Office 365 Group.

If you go back to the homepage and to site permissions, you will see listings for site owners, members, and visitors. These are references to the SharePoint groups. The site members group will show one member, "project 1 Members members". Changing the dropdown from edit to read does not change the permissions of the SharePoint group, but instead moves the Office 365 Group out of the project 1 members sharepoint group, and into the project 1 visitors sharepoint group.

Given the above:

• navigate to the advanced permissions screen, and click on the project 1 members SharePoint group
• click the checkbox next to the project 1 members office 365 group
• click actions --> remove users from group
• Go back to the advanced permissions screen, create a new SharePoint group, and give it contribute permissions. After creating the group, it should take you to the people and groups page, showing the membership of your new group. click "new", and add the project 1 members group to your new group. (this will be the office 365 group.)

Once you've done the above:

• The members of the project 1 office 365 group will have contribute access.
• Clicking the x members link on the homepage and modifying the group membership will work fine, as that still modifies the membership of the office 365 group, which has contribute access.
• clicking "site permissions" will still show project 1 owners with full control, but will not show anyone as a member or visitor. This is the flaw with this approach. The group has contribute access, but this screen will not display it. Instead, this panel will simply state "there are additional groups with permissions on this site"

(In my procedure, I removed the O365 Group from the SharePoint Group. In the blog post you linked to, Paul suggests to switch it to a visitor. I'm not sure which I like better. Paul's approach still makes the group visible on the site permissions panel, but that also makes it really easy for a user to switch them back to a member, defeating the purpose of all of this).

So, not a perfect solution, as the site permissions panel doesn't allow you to view or change the permissions for members, and any further changes will need to be done in the advanced site permissions screen. This does, however, preserve the ability to modify the list of site members via the "group membership" panel from the home page.

edit: I mentioned the other post wasn't "optimal". This was not a criticism of the blog post, rather that I wish MS provided a way for us to do with without all of the above.

Answer 2

When you create a modern team site, it automatically creates an office 365 group (azure ad group) that contains all members and adds to site members sharepoint group. When you add user/invite user from modern UI you are essentially adding the user to the Azure Ad group. The services connected to the Office 365 group like shared mailbox, planner etc use the same azure group to manage permissions on the respective services. In this way if a user is added to the group, the permissions on all connected services are updated.

When you create a new SharePoint group and add users directly, those users only get access to the SharePoint site and they wont be able to leverage any other connected services as they are not part of the Azure group.

You can create SharePoint group and add the azure group to it and then assign contribute permission to the SharePoint group just like as mentioned in the link in your question and other answer (to ensure users are managed by azure ad group), I would not personally recommend it.

One issue I have know is that if the group is connected to MS team, and then user tries to add a wiki tab for the first time they will encounter an error due to the fact that they just have contribute permission on the corresponding SharePoint site. The first time you add a wiki tab, it tries to provision a list and library (team wiki data) which requires the user to have 'add list' permission part of 'Edit' permission level.

As MS continuously updates the services, you never know what kind of cross service dependency they may add and thus breaking your changes.

If you do not need services provided by modern group site, I personally would recommend to create a classic team site and enable modern experience on library level (if tenant level is set to use classic). This way you are free to manage permissions in manner you wish. You also have an option to connect to an office 365 group in case your requirements change in future.

Answer 3

The permission level of the groups can be changed using the PnP PowerShell module:

Connect-PnpOnline https://tenant.sharepoint.com/teams/myteam
Set-PnPGroupPermissions -Identity "myteam Members" -AddRole "Contribute" -RemoveRole "Edit"

Yes, it is not recommended, that's why there is no option to change the permission level to Contribute in the UI.

I do not think the solution in the blog is recommended either.

Both methods achieve the same outcome of removing the Manage Lists permission and either could break functionality or provide unintended results.