Forum Discussion
Best Practices for Permissions on an O365 Group SharePoint Site
you are right, it's recommended to manage permissions with the end user interface. However, every PowerUser is aware how to use the native permissions from previous normal site collections. Very often companies have complex permission requirements, which will definitely not be covered by only three groups (Owners, Members, Visitiors). Therefore we want to conifgure additional permissions directly on the site. It's deifnitely confusing, when users are granted permission to this site, but there is actually nobody in the regarding groups.
Doesn't matter, which UI I use, it should be deifnitely consistent to avoid ambiguities. That's my opinion. Happy to hear your opinion. :-)
I agree with you: the various UIs should be consistent.
Nevertheless, Groups have definitely a non-standard implementation wrt their parts (team sites, shared mailbox etc.): I think we should accept it.
Also, in classic team sites, upon creation, the three groups (Owners, in particular, but also Members and Visitors, of course) are empty.
- You think that's fun, try creating a subsite in a Group team site, the permissions there are all wonky too. The same restrictions are applied to "sub-site Members" (can't edit default "Edit" permissions). It tries to act like a "Group", but its not, "site information" doesn't load because it is not a Group. No way to get back up a level unless you hard code in a "go back" link or inherit menu, which may or may not work depending on the day.
This is a mess.
