Create a Public Group where members have Read (not Edit) Permissions?

Regular Contributor

I work at a large University and a number of our academic departments have asked about creating Groups for their students (e.g.: Psychology Students or Biology Students). In an ideal world, we'd be able to use some bits of the "School Data Sync" component to interface with our SIS and create dynamically managed groups based on enrollment data (e.g.: if major code = PSYCHOLOGY, put student in the Psychology Students Group). I have asked our O365 admins and DBAs about this possibility, but I don't see that going anywhere for at least a year or more.

 

So, my next thought was to create a Public Outlook Group that students could "opt-in" to. They could then use the group mailbox as a means of communicating with one another and even the calendar to schedule stuff with each other. That's all find. The issue is the SharePoint site. We would want the Students to have Read (not Edit) permissions to the connected SP site, with the idea that the department itself would populate content (commonly-used forms, etc) in that site for students to consume.

 

I think this should be possible by just change the permissions of the "(department) Students" group from Edit to Read in the SP site, but has anyone actually done this? If so, how did it work? Or, I should ask: how well did it work? I figure this could go one of two ways: no students join the group and it sits there wasting resources OR students really latch on and use the site/group to death. The one big issue with it being a Public group is that there would be no way to "police" it to ensure that, say, only Biology students can join the Biology Students Group. Department admins tend to lean toward the "control freak" end of the spectrum and there will definitely be some who refuse this model unless they have a way to bar anyone but the appropriate students from accessing the group/site.

1 Reply

Generally speaking, the advice is not to change SharePoint permissions for group-enabled team sites because you never know what you might do that will interfere with something in the future. Another way of saying this is that people who change SharePoint permissions without knowing exactly what they are doing create the potential for mistakes...

 

But some SharePoint experts are quite happy to make changes (for example, see https://www.techmikael.com/2017/12/better-security-defaults-for-office-365.html). If you're happy to take the risk, test to make sure that you know what happens, and document everything so that people will understand exactly what was done, then you can go ahead... and test.