Forum Discussion
Open, but closed - what is the best approach?
I have had similar requirements from a client and I solved it in the following way:
- Create a private Group
- Add "Everyone", with read permission, to the Group's site (and consequently, by inheritance, to the Group's main Document library).
- 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?
- Mikael SvensonMar 27, 2018Steel Contributor
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 :)