Follow Us:
I was working with a client recently in a simplified signup site. One overall important requirement was to keep the interface as simple and easy as possible for the users, eliminating any possibility for the users to make mistakes. For this sign up functionality, all the functionality was kept to one list. Users would browse a list of available sessions to choose from, edit the session item, and fill in an attendee field with their name. For this, when the user would edit the session item, we wanted to only allow them to edit the attendee field, and not anything about the session (title, date/time, location, etc.). In effect what was needed was to make the fields read only based on the role of the user.
As with most things in SharePoint, you could accomplish this many different ways:
For simplicity, I went the first route, just using SharePoint Designer and a custom list form. To demonstrate the final result, this is the edit form when an admin user with Designer-level permissions edit an item:
All of the fields are editable. When a non-admin user with Contribute-level permissions goes to sign up (where there is no attendee in the item), they get a mostly read-only view except for the attendee field:
If a non-admin user edits an item where they are in the attendee field, they still get the edit control but only for the Attendee field (in essence we only allow them to edit the field if its their item):
If a non-admin user edits the item where they are NOT in the attendee field, they do not get the edit control:
To accomplish this, we will perform the following basic steps:
Let’s get started.
On a side note, for the Attendee field I am doing checking on the people picker for that field. But you could also use the Created By field (@Author) or Modified By (@Editor) instead of @ParticipantsPicker in the expressions above.
NOTE: If things don’t work, go inspect the XSLT in code view for the formula VERY CAREFULLY. I saw a few times where pieces of the expression where removed or changed, and I had to just paste in the full XSL. I will provide here for easy pasting (be sure you are closing the xsl tag with </xsl:if>):
Whew! Ok now we just need to create the custom permission level. Again this is to ensure that non-admin users can only edit existing items, and cannot add or delete items.
Test it out, you’re done! This should work with SharePoint Foundation or Server, and doesn’t require any coding or InfoPath. Hope you learned something!
For more information about C5 Insight or this blog entry, please Contact Us.
Thank you. This very helpful.
I am lost at the attendee field part. Are we still using the boolean option and if has rights? or are we using the boolean option and double click on the boolean option?
The complementary paper includes over 12 years of research, recent survey results, and CRM turnaround success stories.
Request Download
This 60-second assessment is designed to evaluate your organization's collaboration readiness.
Learn how you rank compared to organizations typically in years 1 to 5 of implementation - and which areas to focus on to improve.
This is a sandbox solution which can be activated per site collection to allow you to easily collect feedback from users into a custom Feedback list.
Whether you are upgrading to SharePoint Online, 2010, 2013 or the latest 2016, this checklist contains everything you need to know for a successful transition.