Unfortunately, SharePoint views offer no possibility, out-of-the-box to be used to manage access rights. This is often a major headache, as SharePoint administrators regularly need to restrict visibility to certain items in a list, depending on the membership of different groups. Some use can be made of filtered views, as mentioned in a previous CDM Blog article, but real security cannot be based on such a technique, as it relies merely on hiding information rather than securing it. Audience targeting suffers from the same drawback: it is a content filtering mechanism not suitable for managing security.

The only alternative is therefore is to manage security at the item level. If done by hand, this task will rapidly become unmanageable, and so it should be implemented via a workflow. Or more precisely a series of workflows.

Imagine a simple Knowledge Base site where technical articles are added by a community of users. There is a standard SharePoint Approval Cycle which means that draft articles are only visible to their creators and the approvers group until approved. Most articles, once past the draft stage, should be visible to all authenticated users. However, there are some which need to be restricted to a certain audience for a certain period of time, for example, until a future release date, after which they can be made public.

These requirements imply two workflows, written with SharePoint Designer:

  1. The first we will call InitialPermission which will look at an audience field which can contain different values. One of these may be CoE , in which case Permission levels have to be set to Zero for the Item and for a group of users, typically those that would normally have read access to articles.

     

    This workflow is designed to be run automatically when a new Knowledge Base article is created. The Zero permission level does not exist out of the box in SharePoint, it has to be created by hand.

 

 

  1. The second workflow is used to resent the permission on the item concerned when the Audience field is set to something other than CoE (in this example), and just reverses the Item level permissions.

     

Advertisements