I recently had to build a system for a media company so they could manage their stories across all publications across Australia each day (they then use the information to publish the next day’s newspapers). One request was to have the ability to put story ideas that had been published into an archive list; this then allows the business to do trend analysis on previous stories… however only people who were at a certain business level should be able to archive a story (senior managers), and they should only be able to archive stories from their own masthead.
It was pretty easy to use SharePoint Designer workflow to push items between a primary list and an archive list based on the value of a column (onChange, if Archive Story = Yes)… and I was already securing each story to a masthead when it was created (because I had a lookup list that told me which masthead each person worked for, and I used the shiny new “Remove user from list item” workflow task in SharePoint Designer to give other mastheads read, but not write)… But how was I going to stop people who could edit the story from enabling that field? You can’t secure a column in SharePoint, and you can’t secure a view in SharePoint (at least, it’s not obvious)… you can set a column to hidden so it does not appear in the edit forms, but that affects everyone… so I’d mentally descoped the request.
But while I was hunting around for a solution to another question I saw that Matt Bramer had managed to work out a way to secure a view. Bonus! So, the approach I took was to:
- Hide the column (so users could not update the value in Create or Edit Item views)
- Create the view I wanted in Datasheet mode (because even though you can hide columns, you can still display hidden columns in a datasheet or list view)
- Copy the code between the <ZoneTemplate>…</ZoneTemplate> tags from the view in SharePoint Designer, then deleted the view (Thru SPD or the UI, does not matter)
- Pasted the copied code into the secured page in the page library (so now the page – which we can lock down – contains the grid view)
- Prevent users from creating personal views (so they could not work around this constraint through the UI)
- Even though this prevents anyone from modifying that field through the UI, field updates are still possible through the API / Web Services, etc. It is, however better than security through obscurity.
- When you click on the view in the document library, it takes you to the page… so you don’t have access to any other views any more from the breadcrumb / title without navigating back to the list
- The secured page in the page library appears as a “View” in the list, so you can continue to modify the view through the UI
- Anything you can do to secure pages you can also do to secure the list view in question
- It works in the way the business is happy with
Warnings and Notes:
- Copy the list view code before deleting it – you cannot undo a list view deletion or restore it from the recycle bin.
- Double-check that none of the other views display the column you are trying to prevent access to – otherwise all people need to do is switch to datagrid view
- Remove contributor’s ability to create personal views – otherwise if they know enough about SharePoint, they can get around your “garden wall”.