By: Austin Gainey
Anyone that has lived on the Admin side of even the smallest of SharePoint 2013 on premise environments has probably come across some of the many interesting “out of the box” permissions scenarios. Having personally worked for the last two years as an Admin in an 8+ farm 100+ server SharePoint Universe, I like to think I have a firm grasp on more simple SharePoint concepts like user permissions. But just as I’m feeling comfortable, the SharePoint gods bestow upon me new and interesting scenarios.
I had a team of users reach out to me recently as they were having issues with managing data alerts on individual SSRS Reports. Specifically, users with the “View Only” permission level were able to create a data alert for a specific SSRS Report without issues. But after creation, they were met with the infamous “Access Denied” page.
After some trial and error, I found that if you gave users just the next step up in permission level to “Read Only”, they could access and interact with the “My Data Alerts” page just fine (as seen below).
After discussions with the team, it was concluded that “Read Only” access wasn’t a good option as it gave the “View Only” users too much visibility into other areas of the site, specifically the ability to see data connection properties.
I was curious to understand what the true difference was between the “View Only” and “Read Only” permission levels as it pertained to data alerts.
So to find out, I compared the selected features of each level, which can be viewed by going to Site Settings > Site Permissions > Permission Levels.
Once inside the permission levels screen, you can click on “View Only” and “Read Only.” Doing so will show a list of features each level allows on the site.
“View Only” comes with the following enabled features:
While “Read Only” has these enabled features:
A comparison of the two lists shows the only difference being this feature:
As you can see, it is not clearly obvious that this setting alone should impact the ability to manage personal data alerts. I even created a custom “View Only” permission level and included the “Open Item” feature. But just like with the “Read Only” level, it gave the users more access than the site administrators were comfortable with.
Ultimately this was simply a limitation of Sharepoint Permissions that we weren’t able to easily use out of the box tools for. The limitation resulted in the team having to make unique permissions on certain content/libraries of their SharePoint site – something that is always less than ideal. Hopefully future iterations and updates to SharePoint on premise environments can give greater customization and “work arounds” to seemingly simple issues like this one.
I’m always on the lookout for better explanations and other user experiences, so comment below if you have come across this issue or other similar ones. I will do my best to follow up with any comments or questions.