SOLVED

Change group permission on connected group site

Iron Contributor

Hi,

 

I would like some guidance on the following. With the new SharePoint sites that are connected to a group, the default setting for members is that they have edit permissions. I have seen some threads where people like to have contribute permissions as default, or as an option.

 

Changing the permissions through the ui is greyed out. However, changing the permissions through PowerShell is possible. Simply use this command and the permission level changes:

Set-SPOSiteGroup -Site https://tenant.sharepoint.com/sites/ModernSharePointSite -Identity "ModernSharePointSite Members" -PermissionLevelsToAdd "Contribute" -PermissionLevelsToRemove "Edit"

 

I know that sometimes it's possible, but you still shouldn't do it. Does anybody have any good arguments on why I shouldn't use this option on the modern group connected SharePoint sites?

18 Replies

We have discussed this subject in several other threads in the past. You could do a search for such threads.

The takeover is that it is not recommended to manipulate permissions in modern team sites.

The reason is that Groups are composed of many resources allocated in several workloads, with much things happening behind the scenes, and therefore manipulating permissions often breaks something in an unpredictable way.

If you need to manipulate permission, do yourself a favor and use a classic team site instead.

Maybe @Tony Redmond could add something more authoritatively than me...

 

I agree. Don't mess with the permissions for a group-connected site. If you want to do something funky with permissions, create a traditional team site and use that. There are just too many potential ways you can break the connection between Office 365 Groups and SharePoint (with potential consequences for other apps) if you change the permissions on a group-connected site.

Thanks for the replies. I've done a search and found some guidance, but not on this PowerShell option.

 

Could you elaborate on what might break? The permission change is only for SharePoint. I can imagine some consequences for Teams, as it uses SharePoint for the wiki and file storage.

 

Am I missing something else? And there's always an option to revert is back unless Microsoft closes this option.

And another point, I (try to) read and inform myself. There are a lot of users out there that will use the advance permissions options to change the permissions on the SharePoint site. According to your guidance you shouldn't do this. I'm confused as what the consequences of these changes might be. My powershell options is edgy as it overrules the ui that blocks this option, but adding a group and changing the permissions seems fully facilitated by Microsoft.

 

I don't like the alternative to use classic team sites. Microsoft is pushing hard on the new team sites, with site designs, site scripts and hub sites. If I read correctly I need to miss out on all these options when I don't want to give 'normal' users the ability to customize sites and libraries. 

 

 

SharePoint has its own permissions scheme, which comes from the on-premises product. You use that scheme with the old-style sites. Group-enabled sites essentially give responsibility for handling permissions over to Groups, where the idea is that all members have the same level of access to all content within group resources, including documents. There are changes made behind the scene to ensure that group membership updates are synchronized to SharePoint to make everything work.

 

You can come along and introduce your own permissions to a group-enabled site, and those changes might work - today. No guarantee exists that the changes will work in the future if Microsoft changes part of the mechanism that ties SharePoint and Groups together. For example, if you use the Get-SPOUser or Get-SPOExternalUser to examine the (apparent) membership of a group-enabled site, you might find that members long since removed from the group are still present according to SharePoint. This "debris" doesn't matter because Groups controls access and SharePoint refers to AAD for membership information. But if you now introduce your own permissions, you might break something.

 

Yes, there's a lot of mights and maybes here - but do yourself a favor and avoid the potential for future problems by keeping groups-enabled sites as clean as possible in terms of permissions. My view, Be my guest to go ahead and play with fire...

I understand the concern when you give access to SharePoint content by adding people to SharePoint groups or creating new SharePoint groups. It's best to keep using the provisioned Group to manage the members. 

 

What I'm proposing however, and others have done before, is not changing that principle. You either change the permission of the SharePoint group from edit to contribute. Or you create a new SharePoint group with contribute permissions and move the Office group from one SharePoint group to the other. The first one is preferable as the modern ui doesn't change. 

 

But both don't change the principle of using Office 365 Groups to manage members. We're not adding users to SharePoint directly. It would have consequences if one of the following would apply at the moment or will apply in the future:

- SharePoint is used to store data for other products, as is done with Teams for the wiki. Members might need to have edit permissions to make the product work as expected. As far as I know this is not the case at the moment.

- When the processes in the background does anything other than managing members of groups and would actually set permissions somewhere. As far as I can see from the SharePoint interface combined with my knowledge of the SharePoint permission model, this doesn't seem to be the case and would't be very likely to change.

 

Why do I comment again? You are an MVP and in my view I respect that status when guidance is given. But I have a hard time combining this comment "Be my guest to go ahead and play with fire..." with Microsoft adding the option for advanced permissions in a newly developed site and interface. They consciously added this option. It's not that they forgot to remove it or something. Are you saying that while this option exists that I might have situation where I create an unsupported environment?

 

And how about a post like this from a Microsoft employee: https://blogs.msdn.microsoft.com/bobgerman/2018/04/12/using-sharepoint-permissions-in-microsoft-team...

 

He is promoting this as a MS employee on an official MS website. I know that MS has sometimes given bad advice or that this might not be supported by the product team etc. But I hope you understand that this is very confusing. Do you know if anybody can or may give 'official' guidance? Or should I not take your guidance as a personal opinion?

best response confirmed by Colin_Severin (Occasional Reader)
Solution
Bob German’s blog is unavailable so I cannot judge his advice.

All I can say is that I favor simplicity above complexity, especially in cloud systems where you do not control all the pieces. It is up to you to decide whether to take the risk that you might break something. If you are experienced at dealing with SharePoint permissions, you might be able to work everything out and all will go smoothly. However, generally speaking, I do not recommend that people go outside the boundaries of the default permissions. It’s your tenant... so it’s up to you. And if you work everything out and make it all work as you want, perhaps you can document what you did so we all learn from your tenant experience.

I see that the link doesn't work, maybe this one works https://blogs.msdn.microsoft.com/bobgerman/2018/04/12/using-sharepoint-permissions-in-microsoft-team.... Otherwise people might search for "Using SharePoint Permissions in Microsoft Teams Channels" by Bob German.

 

Thanks for the info on why you give this advice. I'll consider writing a blog post and referring to this thread so people can decide for themselves. 

Thanks for the updated link. Bob’s post is a test case, and I hesitate in using test cases unless you have tested them in all circumstances that you might meet in production. As he notes, secure channels or private channels are on the Office 365 roadmap and will provide a solution for many situations where we have difficulty today. In the interim, have you considered using rights management to protect folders and files with granular levels of access. At least that is fully supported...

For me that would not be an option. I'll explain my case, maybe it helps Microsoft in deciding what the default permissions would be.

 

Recently I have implemented SharePoint online for a couple of customers. Where I have preferred to stay away from the modern team sites for a while, I think they are now starting make sense to use as the default option for new implementations, unless there's a good reasons to stay on classic. Especially with site designs / site scripts and the introduction of hub sites you have a very good scenario for basic SharePoint intranets that are very user friendly.

 

The issue lies with the "basic" part. Most of my customers have inexperienced users and would only like to give them the option to add, edit and delete content. However, the default permissions is the Edit level, which gives them permissions to add and edit lists and libraries. I wouldn't expect basic users to have that permissions. Most of the time they don't know what they are doing and are very likely to make a mess of that environment. I would expect that only site owners would have that permission. Using classification and labels doesn't solve that issue. 

The default probably comes from the the default setting for site members in classic SharePoint. At least then it was an easy fix by changing the permissions. Now with the cloud, that easy fix is harder and might have consequences that you can't know at the moment. However, the case remains, it's very normal that you want to give users access to content, without giving them access to change the structure.

 

Sounds like a plan. I shall look forward to the write-up.

To add some relevant content to the discussion. I was reading this blog post: https://beaucameron.net/2018/04/17/security-trimmed-hub-site-navigation-updates/ and found this quote:

"Which means that users in the Member group have access to change the navigation" (of a Hub site)

 

This makes me think two things:

- Microsoft will likely fix this, as this is becoming an issue for many

- If Microsoft fixes this, I should better wait.

 

 

Hi @Martijn Eikelenboom

Out of curiosity, do you want to use Groups only for the Modern team sites new features, or also for the other peculiar Groups features (Outlook conversation, notebook, Teams, Planner, etc.)?

Well, given that you've already said that most users don't know SharePoint, how likely is it that someone will come along and change something like navigation?

@Salvatore Biscari for the two cases I have now, only SharePoint. 

 

Any reasons why you ask this question? Am I missing an option to create new style team / communications sites without a connection to groups? Although I prefer the concept of Office Group membership over the former SharePoint group membership. 

@Tony Redmond normally they wouldn't. But they made that pretty easy too. Especially adding columns to lists and libraries is very prominent in the user interface. Regarding the navigation, I don't know. It's too new to say. But that made that pretty easy to edit as well.

Just consider SharePoint intranets based on a hub site where literately everybody can edit the global navigation if you just want them to edit some documents or post some news.

 

I do love the new interface and how easy it is. That's no complaint.

There have been several threads showing techniques for "modernizing" classic team sites.

Of course, such "modernization", until it will be implemented directly by Microsoft (if ever), is not full-featured.

Nevertheless, you could try it...

1 best response

Accepted Solutions
best response confirmed by Colin_Severin (Occasional Reader)
Solution
Bob German’s blog is unavailable so I cannot judge his advice.

All I can say is that I favor simplicity above complexity, especially in cloud systems where you do not control all the pieces. It is up to you to decide whether to take the risk that you might break something. If you are experienced at dealing with SharePoint permissions, you might be able to work everything out and all will go smoothly. However, generally speaking, I do not recommend that people go outside the boundaries of the default permissions. It’s your tenant... so it’s up to you. And if you work everything out and make it all work as you want, perhaps you can document what you did so we all learn from your tenant experience.

View solution in original post