SharePoint’s Field Level Security – The Overview
If you’re like me, you’re very frustrated that SharePoint doesn’t have a way, out of the box, to handle field-level security. However, there are several ways to extend SharePoint to make this happen.
- Custom Field Controls
- Custom Forms (Edit, Display, New Forms)
- Custom Event Handlers
I’m going to cover each of these in seperate articles. They cannot be adequately covered in one blog post. Well, they probably can, but I cannot adequately cover them all at once!
To start, I’ll offer just an overview of each before writing up posts for each of them.
Custom Field Controls
These are the truest form of Field Level Security. No matter where the field is used, the control will apply the same security rules — whatever those may be, as this is a custom control you’ll write your own rules. This can be good, or bad. Imagine designing this control to work with multiple sites, site collections, even web applications. How do you design it to function properly across the entire farm? Answer: you’ll have to wait until that blog post is written! Another issue with using custom field controls is that you have to write a custom control for each type that you’d like to have secured — types being single line of text, multiple lines of text, dates, booleans, etc.
(Note: I’m focusing on the Edit Form)
The custom edit form is not one that is designed with SharePoint Designer. While you could design one-offs this way, we’re interested in scalable and repeatable designs. The custom edit form that we’re interested in designing is one that can easily be packaged and deployed. This method is more flexible, but isn’t the truest field level security. We’re going to look into custom templates. This allows us to use a single control (ascx file) that works for multiple forms. Just point your content type to this control, and viola! A secured edit form!
Also, one could create a custom form that is an application page, deploy it, and then point a content type to that form. TO do so, just update the Form’s <Form> xml node within the Content Type. While that provides a lot of flexibility in the code, ultimately, I’m not looking to replace SharePoint functionality here. I’m really just trying to get Field Level Security implemented.
Custom Event Handlers
Custom Event Handlers are my least favorite method of the three. On the plus side, they are by far the easiest to grasp and implement, they work for any content type, and they are the most familiar to SharePoint developers. So why are they my least favorite? Because they don’t provide any forewarning to the user that security rules exist. The user can interact with the control and seemingly make edits. But when they click the Save button, the security rules get applied, and suddenly the user is told they don’t have the priviledges to make their changes. Imagine making changes to a Word document or Excel spreadsheet, getting all the right info into it, and then when the user saves it, the application throws a message and discards the changes. Not a great approach, IMO. Another negative is the hassle of dealing with Before and After Properties. Sure, those work for list items in most cases. But what about document libraries? Document libraries require special attention because the ItemAdding and ItemAdded method must both be used, since AfterProperties aren’t available in ItemAdding while BeforeProperties aren’t available in ItemAdded.
Also, how do you handle the case where the user can update FieldA but not FieldB? Do you keep the changes for FieldA and not FieldB? How do you inform the userFieldA was indeed changed, but FieldB was not? Keep in mind, you can display a message if and when you use the Cancel. If you don’t Cancel the change, you can’t display the message. So you can discard all changes (in this case to A and B) and let the user know. Or, you can accept the change to A and not B, but the user won’t explicitly be told.
I’d love to hear your thoughts on these three options. Another type of workaround would be workflow, but that’s a lot of hassle.