Skip to main content

I love(d) Flexitask, Assign To-Do task actions until .... today.  Reason?   It is not secure enough is some cases.

A business case requires tasks assigned individually to several users.  Of course we want to be sure that only the assigned user may change his task (and only his task), and should not be able to:

- delete his task (or else Nintex WF will hang)

- delete tasks in the same tasklist of other users (or else Nintex WF will hang)

- change tasks of another user stored in the same tasklist.

Logic?  This is what I expect.

The problem is that

- Flexi Task, Assign ToDo task etc are not managing permissions of the task item itself.

- An approver of a task needs at least Contribute rights to the task list (else he/she can't open the task and respond to it --> see other threads)

This means that an approver with contribute rights on the task list can:

  1. delete any item in the task list  (solution could be: custom permission level 'contribute without delete')
  2. may edit a "Assign ToDo task" of somebody else
  3. Is NOT able to edit a "Flexi Task" when using the default EDIT form of a flexi task (which is OK, because it contains Nintex logic), BUT what about edit the tasks in Datasheet view, or via REST web service??

"Hey, just use item level security when the flexi task or ToDo task is created!" --> "not possible dude, because the FlexiTask & Assign ToDo Task actions inside your WF will wait till the tasks are completed --> so Set Item Permissions is not possible to use."

Indirectly, you can set item level permissions on individual tasks created by  flexi task or ToDo actions --> create a new WF "Set Permissions" on the task list itself and run them when new task is created in the task list.

Good workaround?  Maybe.  I don't like to split WF logic in two individual/independent components.

Another alternative is: Don't use Flexitask/Assign ToDo Task, but create an UDA which:

- creates needed tasks in task list (create new item action) eg in a task list you have define  as input parameter (which could be different task list assigned to the WF wink.png)

- set item level permissions according your own business logic

- send email message (if required)

- Use a loop to monitor the status of the actions you have created earlier

- Send reminder or complete tasks after certain period during this loop.

- Exit UDA with results or statuses according your business logic

Is my way of thinking correct?  What is your experience of using SP, Nintex WF in an environment when tracing and security is important?

Thanks for the feedback!

Koen

Hi Koen,

With the options you presented above what would stop you from

1] Creating you own custom permission set (Contribute - NoDelete) for the Task list?

2] Have a seperate task list for your NIntex workflows? Even if you edit it should probably show you the same form?

Regards,

Shrini

1]  This is advise that a WF designer needs to know when they use Nintex tasks --> take measures when you don't want that end-users delete other's tasks. (or their own!).

2] In a secure/solid business scenario where I want to have an full-proof electronic approval, having a separate Nintex WF Task list will not garantuee item level permissions.  There are still workarounds to change other approval tasks without using the edit form.  At the end your approvers still have "Contribute without delete".

So in 90% of my SharePoint projects, I don't care about security, and is a flexi task perfect (with at least custom permission level).  But when you need to be compliant with some standards, you need to make sure that the task can't be changed/approved by another person.

HI Koen,

That is correct, I believe you could raise this as a product wishlist. I have also added some out there for a different ones and I believe Nintex iif they action it would be really great.

For smaller scenarios generally Nintex as an engine should be good its only when we start implementing it for a full fledged robust solutions we probably come across such bottle necks.

Most of the time we circumvent (like cases as you suggested) is by making sure that the user journey is correct and it does not take them to the workflow task list, but if the user is familiar with SharePoint and also wants to play a bit then obviously you would hit a dead end happy.png ..

Shrini

I don't know the entire story for this, but rather than not allowing your users to delete or change items and causing yourself a headache, could you not educate your users about this, and then put in some measures to allow auditing on the task list, like Version History, and alerts when a user deletes an item.

With regards to your issue around users editing Flexi Tasks with datasheet view and REST webservice...what kind of users are you dealing with here??? Datasheet view you can turn off in the list settings, but do you actually have end users who can invoke webservices and know what to do with them???

If you wanted to enforce permissions, I would definitely go with the method you mentioned of creating a new workflow on the tasklist every time a new task is created. We've implemented this before and it performs well for us.

I have just implemented a solution where we use customer permissions set Contribute no delete - works a charm!

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings