InfoPath, I really like InfoPath. I like the interface and how easy it makes editing custom list forms in SharePoint (especially if you want to make snazzy looking forms in SharePoint 2010). However, custom actions do not like InfoPath, not one bit.
The problem
Here’s the situation, we have a heavily customised custom SharePoint 2010 list which was leveraging InfoPath based forms. We were getting reports of latency when trying to open the InfoPath forms and the decision was made to revert back to the default ones.
Also, another requirement was to have a two edit forms for this list, one set as default with several fields omitted for end users – another one for administrators of the list. Once the edit forms were created I embarked on my journey of creating a custom action that would open the administrator’s edit form from the ribbon, utilising rights masks to make it only appear for those with adequate permissions.
I quickly found that this wasn’t going to work. I tried several times to create the custom action but it just wouldn’t appear. Even after reverting the list back to the default forms from InfoPath through list settings and deleting the InfoPath forms from server the custom action wouldn’t show. I found some useful conversations about this issue below:
After I realised the custom action approach wasn’t going to work, I made the decision to go down the route of having one custom edit form that would conditionally show or hide fields based on their permissions – the answer I found was within a XSLT conditional if test!
The solution
Here are the steps taken to hide a field based on a user’s permissions within a custom edit form:
- Open the list you want to edit in SharePoint Designer
- In the Forms section, open your custom edit form
- Switch to Advanced Mode
- Use the design view and select the field you wish to hide
- In the code view, add the following code snippet above and below your field:
<xsl:if test="ddwrt:IfHasRights(2048)">
</xsl:if>
- The end result should look something like this:
- Save the changes
If this has worked, you should now be able to test the edit form as a user with the correct permissions and see the field, then verify that for a user without the relevant permissions it’s hidden.
Within the if test, the number corresponds to a permissions mask that assigns a particular value (i.e. 2048 = Manage Lists).
Here is a list of all the values and permissions masks:
| Permission | Permission Mask |
| ViewListItems | 1 |
| AddListItems | 2 |
| EditListItems | 4 |
| DeleteListItems | 8 |
| ApproveItems | 16 |
| OpenItems | 32 |
| ViewVersions | 64 |
| DeleteVersions | 128 |
| CancelCheckout | 256 |
| PersonalViews | 512 |
| ManageLists | 2048 |
| ViewFormPages | 4096 |
| Open | 65536 |
| ViewPages | 131072 |
| AddAndCustomizePages | 262144 |
| AppleThemeBorder | 524288 |
| ApplyStyleSheets | 1048576 |
| ViewUsageData | 2097152 |
| CreateSSCSite | 4194314 |
| ManageSubwebs | 8388608 |
| CreateGroups | 16777216 |
| ManagePermissions | 33554432 |
| BrowseDirectories | 67108864 |
| BrowseUserInfo | 134217728 |
| AddDelPrivateWebParts | 268435456 |
| UpdatePersonalWebParts | 536870912 |
| ManageWeb | 1073741824 |
| UseRemoteAPIs | 137438953472 |
| ManageAlerts | 274877906944 |
| CreateAlerts | 549755813888 |
| EditMyUserInfo | 1099511627776 |
| EnumeratePermissions | 4611686018427387904 |
| FullMask | 9223372036854775807 |
SharePoint Stuff 