Hi,
Column permissions (or field security or whatever you like to call it) is a very common need, especially as more and more companies chose to computerize their paper forms using SharePoint. A simple vacation request form that needs to be approved by the manager has two kinds of columns - thse filled out by the employee (start date and end dates come to mind :)) and those filled out by the manager (approve/deny). How can that be accomplished?
Well, the short answer is - it cannot be done in SharePoint out of the box. The product does not have any support for column security, all columns always have the same permissions as the item which values they represent. So we need to look at the alternatives.
- InfoPath forms- SharePoint and InfoPath have been best friends for a long time, there was a forms library in SharePoint 2003 and the situation has been improving ever since. In InfoPath you can implements rules and condition and create just the user interface you want using a simple designer. Using Forms Services you can fill out the resulting form using nothing but your browser. But there is also a dark side:
- InfoPath forms are not lists, although you can promote certain value to become columns in the form library, but this is not 100% list-based solution, for once, you cannot use custom fields
- Creating InfoPath forms requires some learning curve, nothing major, but enough to deter users
- It looks different, it behaves differently, it just does not fit in the familiar look and feel of your system
- "Secure" custom field type- some sort of custom field that encrypts its value and only shows it to users with sufficient permissions. This type of solution is offerred by a few companies out there and does seem to provide an interesting approach. But there are some drawbacks as well:
- This is a custom field, although it is possible to make it behave similarly to the built-in fields, such as text, number or date, it can never replace all field types out there, certainly not the custom one you might need in your solution.
- The value is stored can only be used by the field itself, if you want to get rid of the field type, you need to re-enter all the data. All you wanted was a SharePoint list, not a catholic wedding :)
- Custom iterator - is the component that controls which columns will appear on the new/edit/view form of any SharePoint list or document library. The SharePoint infrastructure allows the built-in component to be replaced by custom one, that can show or hide columns based on custom logic, such as column permissions. Due to the fact that only the background component is replaced, your user interface remains unchanged and you can use any field type, built-in or custom. This approach is not without sin:
- These are display restrictions, the underlying data does not have any security layer applyed to it. So the columns can still be shown using standard views and datasheet view. This is actually not a big deal, as you can control which columns appear in views and you can block the datasheet view. But in most cases even these measures are unnecessary as all you want to do is basically prevent a regular user from accidently editing the fields they are not supposed to edit, the changes can always be tracked by turning on the auditing feature when needed.
In my personal opinion, the third option is by far the most convenient and useful, despite the drawbacks. It allows you to create advanced, multistage electronic forms with minimal effort and easy-to-use, consistent interface. This is why we based our Ultimate Forms product around this appoach, adding such cool features as tabs and tab permissions, view permissions, custom validation and more.
Get it free or install the 30-day trial version, this is really cool and helpful.
That's all for now :)
