TheGeezer2010
asked on
Sharepoint 2010 Permissions inheritance issue
Have created a SP 2010 permissions structure top-down which seems to be working well. All departments are in same SC, each department has own site/subsite/libraries/lis
I can remove this group's access from everything below, but there are two issues here :-
1. A lot of initial extra work - remove Portal Viewer group permissions from all subsites, libraries and lists.
2. (Most important) Since these permissions are inherited from the department TLS, any NEWLY created Siubsites, lists or libraries will inherit the READ permissions for the Portal Viewers group - NOT what is required.
Can anyone suggest a better way of doing this (given that I have inherited the structure and have to work with it) ? I was thinking maybe to create a BUFFER site at the top level for each department, give the access rights to the Portal Viewers group at THAT level, BLOCK inheritance at the next level and add the permissions for the aforementioned 4 department groups at the NEXT level. In this way, publicly viewable content at the TLS, privately managed content at the level below. But again, a lot of extra work as all subsites, libraries and lists would have to be moved to the newly created site at the level below the TLS.
Thanks for all suggestions
I can remove this group's access from everything below, but there are two issues here :-
1. A lot of initial extra work - remove Portal Viewer group permissions from all subsites, libraries and lists.
2. (Most important) Since these permissions are inherited from the department TLS, any NEWLY created Siubsites, lists or libraries will inherit the READ permissions for the Portal Viewers group - NOT what is required.
Can anyone suggest a better way of doing this (given that I have inherited the structure and have to work with it) ? I was thinking maybe to create a BUFFER site at the top level for each department, give the access rights to the Portal Viewers group at THAT level, BLOCK inheritance at the next level and add the permissions for the aforementioned 4 department groups at the NEXT level. In this way, publicly viewable content at the TLS, privately managed content at the level below. But again, a lot of extra work as all subsites, libraries and lists would have to be moved to the newly created site at the level below the TLS.
Thanks for all suggestions
SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
Sorry that was the link for another site: this gives an overview of the event handlers that you have:
http://www.sharepoint-tips.com/2009/11/event-handlers-in-sharepoint-2010.html
http://www.sharepoint-tips.com/2009/11/event-handlers-in-sharepoint-2010.html
ASKER
Hi Bradgcoza
We made a conscious decision to avoid using AD groups as much as possible as the nature of use in Sharepoint is very different to the requirements for AD. We have four groups at each level - the three you mention and in addition <sitename>Designer - for allowing senior users to architect their own structures.
Hi Koen
I did not think there would be an easy way to do this at this stage, so do you think having the Department Read-Only level at which Portal Vistors are given Read-Only, and below this in each case, the Department's private data for which no permisions are accorded to Portal users, only non-inherited local department permissions are accorded by means of the four aforementioned groups :-
<sitename>Visitors/Contrib
Is this the most efficient way to go at this stage ?
I like the idea of the event handler and will look into that - presume it can be modified to include any new libraries and/or lists as well ?
We made a conscious decision to avoid using AD groups as much as possible as the nature of use in Sharepoint is very different to the requirements for AD. We have four groups at each level - the three you mention and in addition <sitename>Designer - for allowing senior users to architect their own structures.
Hi Koen
I did not think there would be an easy way to do this at this stage, so do you think having the Department Read-Only level at which Portal Vistors are given Read-Only, and below this in each case, the Department's private data for which no permisions are accorded to Portal users, only non-inherited local department permissions are accorded by means of the four aforementioned groups :-
<sitename>Visitors/Contrib
Is this the most efficient way to go at this stage ?
I like the idea of the event handler and will look into that - presume it can be modified to include any new libraries and/or lists as well ?
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
ASKER
Hi Koen
Well the choices I have are as follows :-
1. Go with what we have now, remove the Portal Visitor permissions from EVERY subsite, list and library in each Department site, implement the handler to remove same permissions from every subsite, list, library created under the Department main sites.
2. Create a Department subsite under each department site. Move all content to the new subsite (as far as I am aware, this means manually creating folder structure within lists/libraries, and using site content and structure to move the actual content to the new subsite), and then break inheritance and apply Departmental only permissions at this site and below (Remove Portal Visitors). In this way I would not have to implement a handler as the inherited permissions would be correct.
Both a lot of work but just feel the latter allows for expansion and change far better than the first solution ?
Well the choices I have are as follows :-
1. Go with what we have now, remove the Portal Visitor permissions from EVERY subsite, list and library in each Department site, implement the handler to remove same permissions from every subsite, list, library created under the Department main sites.
2. Create a Department subsite under each department site. Move all content to the new subsite (as far as I am aware, this means manually creating folder structure within lists/libraries, and using site content and structure to move the actual content to the new subsite), and then break inheritance and apply Departmental only permissions at this site and below (Remove Portal Visitors). In this way I would not have to implement a handler as the inherited permissions would be correct.
Both a lot of work but just feel the latter allows for expansion and change far better than the first solution ?
ASKER
OK I am going for the second choice and going to implement next week, will allocate points and close once completed.
Problem 2. I would use a site event handler that whenever a site is created on a specific sub level you break inheritance and remove a specific group:
http://sharepoint247.com/sharepoint2010/sharepoint-2010-event-handler-to-create-subsites/