I'm trying to decide how to handle requirements I have for removing security groups and permission levels that are added by activating the SharePoint Server Publishing Infrastructure (SSPI) feature with a custom feature.
Considerations I can come up with include
- whether to put a dependency on SSPI for my feature or check for existence of groups, etc...
- whether and/or how to restore them during retraction of my custom feature
- whether I can get away with simply "hiding them" with CSS or jQuery (or whether this is even necessary or better in any way)
Specifically, the customer has requested removal of the
Manage Hierarchy permission level and the
Restricted Readers, and
Style Resource Readers groups. They also would prefer that some permissions not be assignable to people directly (through the "Grant Permissions" ribbon button that brings up aclinv.aspx in a dialog)
This is not a how-to-code question - I've found plenty of resources for that. It's a question of the risks and impacts of deleting or removing access to those groups and permission levels and reasoning behind restoring them during feature retraction (other than it's just "best practices").
I understand that the customer want the hierarchy locked down (and actually the content approval too) to very select people that also having full control, while having all the other content types and features that come with SSPI - not sure if that helps. EDIT We've also removed access to the masterpage gallery and theme customization (both through permissions and
HideCustomAction, where applicable) end edit
Question: What are the impacts of deleting permission levels and groups created by SSPI?