Running Nintex Workflow 2013 version: 220.127.116.11 on Sharepoint 2013.
I have a State Machine action at the root of my workflow configured to run with owner permissions, the owner being a farm administrator account.
in the tree under it, i got a request data task assigned to the initiator user whose access on the list item is restricted to View only and who has the same level of access on the "Workflow Tasks" list.
When the user performs the task, the workflow fails with an access denied error. It only works if i grant the user Contribute access on the "Workflow Tasks" list, which i don't want to do.
If the workflow is running with owner permissions, I don't understand why the user needs to have contribute access to this list in order to be able to perform the action.
I want access to be locked down so is there a way i can identify the workflow task item in question and grant him access to only that item? would that work?
Solved! Go to Solution.
Since the task is created for the initiator, the list item in the Workflow Task List is created by anyone with contribute access (the farm account). But only users with contribute rights can edit list items in any list in SharePoint. When a user completes a task, what they are doing is changing the Status and Outcome, and possibly Comments to the task. A user must have edit rights to make changes to list items. When they are working with tasks, they are outside the context of the workflow per-say and editing a SharePoint list items that the workflow is watching. If you grant everyone contribute access to the Workflow Task list, and another user opens the task, Nintex will disable the functions of the task form and say "You are not authorized" on the form. Is that of any use?
Thanks, I was afraid that everybody with contribute access would be able to edit the task, not just by opening the item itself for edit but mainly by editing the whole list and changing items at will.
by the way, the reply action on a thread message in this site does not work in chrome.
I would try to not edit the workflow task list permissions and let Nintex control who can respond to the tasks via the form. But feel free to change the permission on the current item in question during approval process. And make sure you have a commit pending changes after a Set Item Permission action as a commit is required for this batched process.
(side comment: reply in chrome is working fine, but I did see that editing from an email thread url wouldn't bring up the editor. When I reply to the post directly without the email added querystring, I could reply fine. But this only occurred for this thread and not others i'm on. Interesting.)
My application is built with REST api, and it uses that rather than Nintex forms to respond to the nintex tasks.
If you are saying that responding to a task using Nintex provided forms is the only way to restrict access to a task, then i am afraid that will not work for me for the reason mentioned above.
The problem is that if i do not grant my users explicit contribute access to the workflow list tasks, i get access denied errors when they try to approve/reject.
Also, I've been using the Set Item Permissions action without a committing pending changes and i never had any problem with it. could you please explain where the risk lies in this approach.
and you are right about the reply in chrome. thanks for pointing that out.
I see now, sounds like a cool application. But no, using nintex forms is not the only way to restrict the access, it's just a built in feature. Controlling the permissions will be what you need then as you are using.
Using Commit Pending Changes ensures the change in the permission in that process of the workflow as that action is a batch driven action. See details here Designing your Workflow - Commit Pending Changes Action NW2010 & NW2013
Using the actions just ensures that a commit occurs quickly. There are several other means that commits occur, like a workflow completing, all batched items will commit. A pause in a workflow will cause a commit to a batch. So if you have actions that depend on each other, like a check in/out and update, and the sequence of these actions are important, then you use a commit when necessary. You most likely don't need a commit because any following actions in the workflow are not dependent on the batch updates of other items.