nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

acquire locks in grouptask (WFM)

Annad

Hi,
I implemented an approval workflow in WFM with a bunch of cgi tasks, external tasks, grouptask and usertask. In all the tasks except for the approver task (which is a group task) the lock and transer Only attributes are set to false. In the approver task (group task) these 2 attributes are set to true so that the user who takes the ownership of the task will be able to acquire the locks of the DCRs. According to the workflow manual, this seems to be the way to do it. But it doesn't work for me.

Has anyone tried this and got it to work?

I am using TS6.7.1 SP1.

Thanks

Find more posts tagged with

Comments

Faizi

Hi,
I implemented an approval workflow in WFM with a bunch of cgi tasks, external tasks, grouptask and usertask. In all the tasks except for the approver task (which is a group task) the lock and transer Only attributes are set to false. In the approver task (group task) these 2 attributes are set to true so that the user who takes the ownership of the task will be able to acquire the locks of the DCRs. According to the workflow manual, this seems to be the way to do it. But it doesn't work for me.

Has anyone tried this and got it to work?

I am using TS6.7.1 SP1.

Thanks

Hi,
Have the group users sufficient rights and privilage.
There are also bug with Group Task in TS 6.7.1 version. There are many posting related to Group Task bug.

Thanks,

Annad

Yes, the group users have sufficient rights to edit all files in the workarea.

I read in an other post that this was a bug but was fixed in TS6.5. We are on 6.7.1 SP1.

Let me know if you have any other suggestions,

Anna

Annad

I tried setting the lock and transfer Only attrib to "t" in the task that comes before the group task and on the group task. However, when the workflow is kicked off by an author who owns the locks to the DCR, the workflow tries to acquire the lock in the task preceding the group task and it fails to even create that task.

Can anyone help please? I believe this locking feature worked in WFT (I don't quite remember it anymore). I am using workflow modeller. Would this be a bug only in workflow modeler? Please let me know.

Thanks,
Anna

Adam Stoller

I tried setting the lock and transfer Only attrib to "t" in the task that comes before the group task and on the group task. However, when the workflow is kicked off by an author who owns the locks to the DCR, the workflow tries to acquire the lock in the task preceding the group task and it fails to even create that task.

Can anyone help please? I believe this locking feature worked in WFT (I don't quite remember it anymore). I am using workflow modeller. Would this be a bug only in workflow modeler? Please let me know.

Thanks,
Anna

Workflow has, for a long time, had a problem managing locks held on files from outside the context of the workflow itself. I don't think this is anything new with WFM in that regard.

If you're willing to force all locks on all files associated with the workflow to be released and then re-created within the context of the workflow - try putting an externaltask before any of the tasks that try to get the lock - the externaltask can then call IWHOME/local/bin/unlock.ipl - and after that the following tasks should not have a problem acquiring the locks.

RepairActivity.rptdesign

Annad

I tried putting an external task just before the approver task (group task). However, the users aren't happy with it since it will keep the files unlocked until one of the approver takes the ownership of the task.

What I did in the mean time is set up an iwat event script for the "TaskGroupTaken" event. The perl script that runs on this event simple locks all files in the task by the user to took ownership of the group task. The only problem that the approver faces in this is that they'll have to refresh the task detail page after clicking on the "take" link to see that they have the locks.

This fix is ok for now as far as our users are concerned. However, it would be nice if TS built-in locking feature works for the group task as IW claims in their documentation.

-Anna

Adam Stoller

I tried putting an external task just before the approver task (group task). However, the users aren't happy with it since it will keep the files unlocked until one of the approver takes the ownership of the task.

What I did in the mean time is set up an iwat event script for the "TaskGroupTaken" event. The perl script that runs on this event simple locks all files in the task by the user to took ownership of the group task. The only problem that the approver faces in this is that they'll have to refresh the task detail page after clicking on the "take" link to see that they have the locks.

This fix is ok for now as far as our users are concerned. However, it would be nice if TS built-in locking feature works for the group task as IW claims in their documentation.

-Anna

You could follow the externaltask that does the unlock with a locktask and then the grouptask. Or you could just have the locktask in front of the grouptask and have the failure-transition of the locktask go to the externaltask to forcibly unlock everything and then transition back to the locktask to lock everything.

Yeah - it's a bit convoluted, but it's not that bad.