Open, but closed - what is the best approach?

[Mikael Svenson]

With a client we are setting up a solution based on Office 365 Groups. By default we want everyone in the org to be able to view pages/documents for all groups, thus Public groups makes sense. For this solution we change so that "Everyone" only has view rights on the SharePoint site, not edit rights on files.

At the same time we want a separate document space/library where only explicit members have access. The issue then for a public group is that anyone can add themselves as a member and thus read said documents.

So now we're back to a Private group. And we can add a component which makes sure "Everyone" has read access on pages/documents outside of this library. The issue is of course if they really want a "Private" group. How to distinguish a an open Private group from a closed Private group.

We could of course create custom metadata to handle this, but the Public/Private settings for the group and site access quickly becomes complicated from a functional and understanding perspective.

Ideally we could have a Public group with an option to disable auto-join, or we could have a group with visitor members - and autojoin by default would make you a visitor, not a member - and we could differentiate between those on the SharePoint side.

Today, going "Private" to disable auto-join seems to be the only viable option. Anyone encountered the same challenge and how did you solve it? Use of two groups - which is not that appealing?

cc @Christophe Fiessinger

[#2]

@Mikael Svenson

I have had similar requirements from a client and I solved it in the following way:

1. Create a private Group
2. Add "Everyone", with read permission, to the Group's site (and consequently, by inheritance, to the Group's main Document library).
3. Create an additional "Private Documents" library, blocking inheritance on it and removing the "Everyone" permission.

You have hinted something similar in your post, but it's not clear to me why you don't find it satisfactory.

Can you please elaborate a bit?

[#3]

Hi,

that's probably what we'll end up with. The issue is that if a group owner makes the group public, then private again, then the added "Everyone" group will be removed.

I also have groups which should be private, without adding Everyone to the site. So in order to differentiate the logic between private/private and private/public sites, I need to store metadata, and have some code running somewhere to check that everything is as expected.

Or, I just make all groups like that and forget about private/private, and still add code ensuring Everyone has read to the site - except for the internal library, which is there today already with broken inheritance.

So, it's not like we cannot solve it - it's just that I'd like an option for public groups to require approval of join :)