We are setting an item level permission through Nintex workflow, workflow stop inherit permission and setting unique read permission to the requester.
After setting the permission, requester unable to view the item (error access denied error message). if we check the item permission, it says read access which as assigned by the workflow.
please suggest me to resolve this issue.
Thanks in advance!
Maybe the permissions to a parent folder or list is not what it should be for the user to access the item? Could you provide more details about the list and its permissions. And possibly a screen shot of your action? Thanks,
I have a workflow which provides access to a folder within a document library. The user can create a folder and can select single/multiple groups through a check box column. I have created 4 SharePoint groups with Read Access. Group A, B, C and D. In each of the group I have added 1 or 2 different users.
Now, when I run the Workflow it gives permissions to all the users present in the 4 groups. I then logged the output of the Query XML which returns the users that belong to a particular group. The result was correct and this result I used as input to Set Item Permissions. But still access is been given to all the users.
PFA the images. My Group A had 1 user and Group B had 2 users. Fetched users are correct, but still permissions are given to all. Can someone help?
Shyam, please post new questions as a new post so we make sure we answer Arun's original questions separately. Also if we are able to help you, then you can mark an answer and it will help the community.
But if you are using the Set Item Permissions action, make sure you use the option Remove Existing Permissions so that the original set permissions do not apply any longer and provide others with access.
In my case the user can select multiple groups so I loop through each group get the user names and assign permissions. If I use the option Remove Existing Permissions then the users which are fetched first and given access will be overwritten by the next group execution.
Ok, so if you never do the Remove Existing then the older and inherited permissions will remain. Maybe an simply way to still allow the multiple groups is to first do a set permissions with the remove option set, and provide the initiator an appropriate permission as an individual. At this point the inheriting permissions are gone. Now loop through the remaining groups and add them.
Just make sure whom ever is adjusting the permissions, if it is the initiator, that they do not get lessor privileges to editing the permissions. Also, I would have a commit pending changes after the first Set Permissions that removes all other's access before adding the other groups.
In my situation, i had a list that i was using as a lookup and i was getting access denied because the initiator did not have reading permissions to the lookup list. I simply granted the user access there an all was working well.
I hope this is the case with you as well.