I'm pretty sure the 'Approve' permission level is the default SharePoint OOTB...here's a screenshot...
Regarding your second question, sorry but I'm not quite following you. Could you please elaborate a bit on what you'd like me to check?
Here is an example on my structure, in my example I set permissions to some approvers because I have an approval task in "Do something...." and I don't want the initiator to be able to edit the item at this point. Then after approval I give initiator permissions back.
Only drawback here is that from the time the item is created till the workflow executes the first set permissions anyone with site access can see the item. But otherwise it works.
- find 'Share with' on List ribbon in list view
- click 'Advanced' in dialog opened
- click 'Check permission' on ribbon
- in dialog opened enter an approver and click 'Check now' to see what permission he/she is given
similarly for list item, just in first step start with 'Share with' on Item ribbon
Having checked both the list and list item as per your suggestion, the approver has contribute access on both.
I have done some further testing and what I have discovered is that when I set the item-level permissions to "read items that were created by the user":
then, when the workflow runs, the approver does in fact have access to approve the item. However, the Approver does NOT have access to view the item. In the approval email, if the approver clicks on 'context item display name' he gets an error. However, if he clicks on 'click here to add your comments', he can actually approve the item and add comments. Here's a few screenshots:
Error displayed after clicking on 'context item display name':
Workflow screen after clicking on 'click here to add your comments':
Note, in the above it says 'item no longer exists', even though it does.
So to summarise, the only way the approver can view the item is to change the item level permission to 'Read all items', which is not what I want. I'm very surprised not many others have raised this issue.
Thanks Martin. So, how do you have your list item-level permissions set? Is it 'Read all items' or 'Read items created by the user'? If it's Read all items, then doesn't that mean that all users can see all items in the list at any time, regardless of the workflow, if they have the URL?
yes, that's correct. as I mentioned above, list settings are stricter over permission settings.
but from your above post I understood you've realized this and enabled 'Read all items', but are missing some further permission settings...
Shouldn't this be the expected behavior though, that's where I'm confused. If the approver does not have read rights on the item, then the following will happen
Since SharePoint forces the Read items created by the user to override the item level permissions.
In most scenarios, when this comes up, it's common that the Approvers are allowed to see all items in the list they are approving. If no users should see other's submissions then there are a few ways to work with this.
Here is a solution that may help you out, but it doesn't fix the issue with using the advanced list settings that you were trying to use for "read only items created by user".
Modify the default view to only show items with the filter criteria for created by is set to [Me]. Most users won't even think to check the view and will assume that the items they see are all that's there. This will hide an item from view but still allow the user to edit and do anything else necessary. This allows you to use the "READ ALL ITEMS" in the list advance settings as you should.
There is a hierarchy to permissions and SharePoint obeys that regardless of what we do with a workflow. The List Advance Settings set up how the list will be accessed which will override the items user permission because the list is the parent container for the item itself. So if you restrict the visibility of the item at a global list level, the user will not be able to view those items via the Display, Edit and View Pages.
Also, understand that the task approval is not happening directly on that item, but through a Nintex form page which is separate from the display and edit pages, which is why an approver can technically approve the item even though they cannot see it and SharePoint say the items does not exist. Weird I know.
I did a little testing on this myself and I think you've figured out what works. If you want the user to interact with an item, the list item advanced settings at a minimum would need to be "Read all items". This will allow SharePoint to grant read access to the display.aspx, edit.aspx and view.aspx pages. This has nothing to do with the user, but the items themselves.
As for what level of permissions for the user, the user can have Read or above such as Contribute or even Edit. This is set on the list by going to the list and modify permissions. This is what you would assign to a group or user.
Hope that helps and glad you're using Nintex workflows... Keep it up and let us know if we can help. You pulled in support from three of the communities top leaders...
Thanks to everyone who has offered support here - I appreciate it very much!
There are definitely some workarounds as mentioned above. Even the simple workaround as suggested by Eric of changing the default view, will probably suffice in my case. Good to see some very useful suggestions.