Our organization has a requirement to delegate the maintenance of a number of Site Columns (re-used throughout our business application) to colleagues who do not have Site-wide responsibilities or authority. We didn’t want to simply grant one of the all-powerful permissions/groups (such as Site Collection Administrators, Site Collection Owner, [Site] Owners, or just granting Full Control) as that would leave them open to accusatory questions every time the site or application started behaving badly. We’d like them to be able to act fairly autonomously, without having to worry that they could cause unintentional damage to the site or application due to excessive permissions.
Knowing that most every Microsoft product has a rich, granular set of DACLs applied at every object level, and having exercised some of the rich permissions available in SharePoint 2010, I was pretty sure there should be a way to combine some permissions together to enable Site Column edits, without giving away the farm. However I was unable to find any documentation or research that definitively asserted they knew what those permissions were.
Finally I asked my colleague Dale Cox to pair up with me and, together with four hours and an experimental sub-site, we were able to work out a tight sub-set of permissions that (a) definitely allow Site Columns edits to propagate to inheriting Lists and (b) were ratcheted down stepwise until we were comfortable there was no place lower to go.
There are two sets of permissions we tested for: site-level permissions needed to edit an existing Site Column (that is being used as a column in one or more Lists in the SharePoint site), and List-level permissions needed to propagate Site Column changes down to inheriting columns in a List.
The former permissions *only* exist at the site level (even though some permissions in the permissions set are labelled “site permissions” and others “list permissions”) – we’ve found there are *no* permissions that can be managed directly related to Site Columns, but only indirectly via the site-level permissions.
That we also require the latter permissions was surprising at first (once we configured the inheritance, why should we need ongoing permissions on every inheriting List?), but that’s just a design decision that Microsoft’s SharePoint team made. It means we have to manually *track* all the Lists that inherit changes from Site Columns, and make sure our site column maintenance people have enough permissions to the Lists.
- Manage Lists (labelled “List Permissions”)
- View Items (labelled “List Permissions”)
- Add and Customize Pages (labelled “Site Permissions”)
- Browse Directories (labelled “Site Permissions”)
- View Pages (labelled “Site Permissions”)
- Open (labelled “Site Permissions”)
- Manage Lists (individual permission – which includes View Items, View Pages and Open)
- Contribute (permission set)
There is one case we did *not* explicitly test for, but found was part of the resultant permissions we arrived at: creating a new Site Column. While we believe this probably requires only a subset of the site-level (site and/or List) permissions, we didn’t spend the extra cycles to isolate the minimum permissions needed there. Perhaps it’s implied in the results, and if we need to know we’ll pursue it, but it’s not something we needed to know right now.
Steps We Followed To Distill These Permissions
We had to work as a team to test each permissions combination, as I’d found early on that as soon as I removed myself from the all-powerful groups, I was unable to restore myself or change permissions later on. I manipulated the permissions, and Dale ran the test cases. I pre-created the following groups in our experimental site and assigned them specific site-level permissions, to make it easy to switch from one permission set to another:
Permission Levels assigned to group (custom permissions included)
|Manage lists||Manage Lists (Manage Lists, View Items, View Pages, Open, Manage Personal Views)|
|Manage web site||Manage Web Site (View Items, Manage Web Site, Add and Customize Pages, Browse Directories, View Pages, Enumerate Permissions, Browse User Information, Open)|
|Site viewers||Contribute, Read, View Only|
|Edit Site Columns||(Add and Customize Pages, Browse Directories, View Pages, Open)|
- Dale’s starting position:
- Permissions: member of Site Viewers group
- Result: can view site Libraries and Lists but cannot even load the Site Columns page (/_layouts/mngfield.aspx)
- Added Dale to “Manage Lists” group
- Result: can load Site Settings page but still cannot access Site Columns page
- Removed Dale from “Manage Lists” group, added to “Manage web site” group
- Result: Can load Site Columns page but cannot edit site columns
- Granted Dale the Contribute permission on one of the Lists that inherits a Column definition from the Site Column being tested.
- Result: can still load Site Columns page but still cannot edit the site column being tested
- Dale even tried just updating the site column definition without propagating the change to the inheriting Lists, but that still didn’t work
- NOTE: from here onwards we started making a point of trying to separate out the ability to edit the site column definition from the ability for that site column definition to propagate to inheriting lists
- Removed Dale from “Manage web site” group, added to “Approve” group
- Result: Dale cannot load Site Columns page
- Added “Manage Web Site” permission to a new permission group called “Approve + MWS”
- That is, copied the “Approve” permission group, then checked the “Manage Web Site” permission (and left the dependent permissions that came with it)
- Result: Dale can load the Site Columns page, but cannot commit changes to any Site Columns
- Removed Dale from “Approve + MWS”, added Dale to “Manage Hierarchy” group
- Note: while the difference in included permissions between “Manage Web Site” and “Manage Hierarchy” is large, still the “Manage Hierarchy” permission set is a superset of “Manage Web Site”
- Result: Dale can access the Site Columns page, but cannot commit changes to Site Columns
- However, we noticed that Dale can create a new Site Column, and can edit that new Site Column
- Dale attempted just a non-propagating edit with one of the existing Site Columns, and was successful.
- Theory: current permissions on the Lists that inherit from the existing Site Columns are what’s blocking the previous Site Column edits
- Granted to Dale “Contribute” permission on all of the three Lists which inherit from the existing Site Columns
- Result: Dale cannot commit a propagating edit on an existing, inherited Site Column
- Theory: the individual permission “Manage Lists” is what’s needed on each inheriting List for the Site Column propagation to succeed
- Granted to Dale “Design” permission (which includes the individual “Manage Lists” permission) to one of the three inheriting Lists
- Result: Dale could not commit a propagating edit on an existing, inherited Site Column. Further, the change did not even inherit to the inheriting List (where the permissions needed for propagation could have allowed the change).
- Theory: propagating edits to a Site Column are a transactional request – if the request doesn’t succeed on every inheriting List, then the edit “transaction” is rolled back, rather than partially succeeding.
- Changed the following permissions to all three inheriting Lists: changed from “Design” + “Contribute” to “Manage Lists” + “Contribute”
- Result: Dale’s propagating edit finally succeeded!
- Decided to go back over the site-level permissions to determine whether there was an unknown interaction between the site-level and list-level permissions that we didn’t account for.
- Kept the List-level permissions as-is, but changed Dale’s site-level permissions – removed him from “Manage Hierarchy” and added him to “Approve + MWS” group.
- Result: propagating edit failed, and non-propagating edit failed.
- Removed Dale from “Approve + MWS” group, added Dale to Design group (which has Design permissions set).
- Result: propagating edit succeeded.
- Compared the permissions between the “Design” and the “Manage Hierarchy” permissions groups, and found the following eight permissions in common:
- Add and Customize Pages
- Browse Directories
- View Pages
- Browse User Information
- Use Remote Interfaces
- Use Client Integration Features
- Edit Personal User Information
- Analysis of these permissions, looking for the “secret sauce” that they share:
- The “Manage Web Site” site-level individual permission isn’t the one that Dale needs (as it isn’t part of the Design permission set, and yet Dale was still able to propagate the edit when he had the Design permission)
- Based on the descriptions of each individual permission listed above, the most likely candidate is “Add and Customize Pages”
- Created a new Group called “Edit Site Columns”. Created a new permissions set called “Edit Site Columns”. To that permissions set, we added only “Add and Customize Pages”. Removed Dale from Design group, added him to Edit Site Columns group.
- Note: when “Add and Customize Pages” is checked, the following permissions were automatically checked: “Browse Directories”, “View Pages”, “Open”, “View Items”.
- Result: propagating and non-propagating edits failed. Adding a new Site Column also failed. Dale could access the Site Columns page.
- Added back all eight site-level permissions that were in common between the Design and Manage Hierarchy permissions sets.
- Note: the “Edit Site Columns” permission set at this point doesn’t include any of the List-level permissions that I’ve so far ignored. Continued failure means that to edit Site Columns, a user needs some of these “list permissions” assigned at the site level. [Confused yet?]
- Result: propagating and non-propagating edits failed. Dale is still able to access the Site Columns page.
- Re-examined the “list permissions” that were included in both of the site-level permissions sets (Design and Manage Hierarchy) that were successful for Dale:
- Manage Lists – Create and delete lists, add or remove columns in a list, and add or remove public views of a list.
- Override Check Out – Discard or check in a document which is checked out to another user.
- Add Items – Add items to lists and add documents to document libraries.
- Edit Items – Edit items in lists, edit documents in document libraries, and customize Web Part Pages in document libraries.
- Delete Items – Delete items from a list and documents from a document library.
- View Items – View items in lists and documents in document libraries.
- Open Items – View the source of documents with server-side file handlers.
- View Versions – View past versions of a list item or document.
- Delete Versions – Delete past versions of a list item or document.
- Create Alerts – Create alerts.
- View Application Pages – View forms, views, and application pages. Enumerate lists.
- Added all of the above permissions to the “Edit Site Columns” permission set except View Items.
- Result: propagating edits were successful.
- Stripped down the site permissions from the “Edit Site Columns” permission set to leave only the following: ACP, Browse Directories, View Pages, Open.
- Result: propagating edits were successful.
- Stripped out a number of List-level permissions from the “Edit Site Columns” permission set to leave only the following: ML, VI. Left the site permissions as in the last step.
- Result: propagating edits were successful.
- Wanted to ensure this result is reproducible, so we created a new permissions set “Edit Site Columns – Confirmation”, added the same permissions to this new set (i.e. ML, VI, ACP, BD, VP, Open), created new group “Edit Site Columns – Confirmation”, granted the new permission set to the new group, added Dale to the new group and removed him from the older “Edit Site Columns” group.
- Result: all operations were successful – view Site Columns page, commit propagating and non-propagating edit of inherited Site Columns, add new Site Column.