That's great Mark-Kashman.
A few questions:
- When do we get to have group members' permission as "contribute" to the site instead of "edit". This is a pain point. Anyone ends up fiddling with, tinkering and changing any page including the home page (either inadvertently by trying out the edit button, or intentionally to put their point). Our users want only the owners to be able to create, edit, or delete site pages (or designated multiple owners). Not every member of the group.
- Related to above - not sure then how news would work? News is pages. Can news be in a separate page library of its own, so that it's easier to manage permissions. Then members could then create/edit/delete their own news pages and not other's. And this will also help us having a specific content type associated with that library solely for news applying managed metadata which could be separate from regular site pages which may not really require metadata. The whole "promotedstate=2" is hidden anyway.
- How do we get to assign "visitor" / "read" permission to everyone on a private group's connected site? When we use the "site permissions" right-pane to share "everyone" with "only this site", that is added to the "visitors" group and everything works fine. But, after a few days that disappears and suddenly everyone gets access denied. Our use-case is that although some documents, collaboration and other activities of the group are private, but they may want to keep the site open for all to visit and read. Specific libraries and lists will then override inheritance and be available to only group members. Something like a hybrid between a team-site and a communication-site.
- How do we select a particular managed path (teams or sites) for admin created modern sites? Our use-case being, for example IT has its team site for internal collab, but wants to have a communication site with the same name for wider dissemination. So, the path "teams" would make sense for the team site, and path "sites" would make sense for the comms site.
- How can admins create a modern team site without necessarily being forced to create an O365 Group behind it? Our use-case being, there are several sites that require fluid permission sets with lots of lists and libraries having unique permissions. Nested security groups works best in such cases. Moreover, our users don't want to clog up their Outlook with tens of groups when they don't need to converse at all. Yes, I could go with a classic site, but then it still would be "classic" which at some point in near future may get deprecated. The road-map is clearly modern, isn't it? We want to look ahead, but with flexibility.