Highbrowse

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.

   

    

In the previous blog post, a technique was described for embedding a browser-enabled InfoPath form in a SharePoint web part page. This was done using a standard XML Form View web part and allows the navigation context of the page to be retained. The only disadvantage of using this technique is that it is not possible to close the InfoPath form and return to the original Document Library, as would be the case with a normal document library or SharePoint list.

The InfoPath forms server displays a simple message that the form has been closed, as follows:

If this behavior poses a problem to users, then an alternative XML web part is available, which allows for additional URL strings to be passed containing the address of the page which should be returned to after the InfoPath form has been saved.

Ensure that the InfoPathFormViewer web part is available in the Site Collection Web Part Gallery and insert into a basic web part page.

Set the parameters under the Miscellaneous section as follows:

HTML Code

Form URL

Note that to return to a specific page, it is necessary to add a Source URL parameter, alongside the Xsn and Save Locations.

This will allow the InfoPath form to close and for the default AllItems view to be loaded. However, as the form is in an IFrame, the page will load into the frame unless some JavaScript is used to escape from the frame.

This code should be entered in a Content Editor web part positioned in the All Items view page before any other web parts.