No item exist or it may have been deleted or renamed by another user

Question

I have a SP2010 list that has the Item-Level Permissions set to:

• Read items that were created by the user
• Create items and edit items that were created by the user

The idea here is for users to only see and edit their submissions to the list. This part is working.

There is a workflow attached to the list that is also working which goes through a series of approvals. The issue is that I've been asked to configure the list so that the user's supervisor can also read and edit the request for his/her user. I added a Supervisor column to the list that contains the user's supervisor. The workflow sends a notification email to the supervisor with a link to the DispForm.aspx?ID=xx form. Problem is the supervisor gets the "No item exists.. It may have been deleted or renamed by another user" error when they go to the URL.

So I added an Impersonation Step to the workflow where I Add permissions to the list item - giving the supervisor Full Control to the list item. I have validated the supervisor has permissions then to the specific list item. But the supervisor still gets the error.

How do I give the supervisor access to the specific list item without giving them Read access to the whole list?

After the workflow sets the permissions on the list item the supervisor has Full Control (for testing) to the list item and Limited Access to the parent list. It says the Limited Access can view specific list, document libraries, list items, folders, or documents when given permissions. So I don't see why it's not working

Thanks.

Answer 1

The problem is that you can't really mix the list's 'item level security' and actual item level security, they don't play well together, because when you configure the lists 'item level security' it doesn't actually change the permissions of the item at all. I put 'item level security' in quotes, because the list settings for 'item level security' aren't true item level security, they're enforced through some other mechanism. It's confusing, I know, so when I'm talking about the list settings, I'll continue using that notation to differentiate between that and true item level security.

List settings 'item level security' is enforced completely outside of SharePoint's normal authorization scheme. Once you configure 'item level security' that way, the only user's who can see and edit everything are SCAs (because SCA access is also really outside of SharePoint's normal authorization scheme, for instance you can't set permission such that an SCA can't access something), and nothing you do to the items permissions will change that.

To satisfy your requirements, you need to turn off 'item level security' at the list level and enforce all of your security requirements by setting permissions at the item level through your workflow running at elevated permission. In other words, when an item is created, the workflow should break role inheritance and assign contribute permissions to the author and supervisor, and read permissions to everyone else.

If it is, or is going to be, a large list, however, you need to keep in mind that there is a practical limit on how many unique permission can exist in a list before you may run into performance problems. That limit will depend on which version of SharePoint, but I believe it's a thousand security scopes for 2010, so if it is a modest sized list that shouldn't be an issue. A security scope is defined as the boundary for a securable object and all of it's children, assuming those children do not have broken role inheritance. Basically, a folder with a bunch of items in it is one security scope, assuming the folder has broken role inheritance but none of it's items do.

Ref: SharePoint 2010 boundaries, thresholds and supported limits