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; } } }

File not unlocked after submit using a submit task

Lee

I've a workflow configured within a branch (submit locking model) which runs a simple approval process on the user clicking submit. However the files do not get unlocked after the submit? Why is this ?
Thanks Lee C

Find more posts tagged with

Comments

Jeremy

Hi,

This may sound like a silly suggestion but are you using unlock="t"?

Unlock If set to Yes, then the submittask will unlock all files following successful
submission.

Jeremy

Lee

Yes i'm setting unlock. The task is pasted below just in case i've made a typo etc. the task owner will be an author user.

Lee C

<submittask name='submit'
owner="__TAG__('iw_user');"
description="__TAG__('job_name');" unlock="t">

__INSERT__("<areavpath v='$area_vpath'/>");
<successorset>
<succ v='submitNotification'/>
</successorset>
<activation>
<pred v='adddcr'/>
</activation>
</submittask>

Script.txt

james1

Did the workflow job create the locks that you expect to be removed? I think that a job (i.e., a submittask) can only remove locks that that job created. And/or, the only locks that will be removed are those that the owner of the submittask is allowed to remove.

Who created your lock, and who owns your submittask?

-- James

--
James H Koh
Interwoven Engineering

Lee

An author user outside a workflow edits (hence locks) and regenerates a file. They then click submit which sparks a simple workflow ending with a submit task. The submit task is owned by the user which submits the file (ie the user who owns the lock).

If the submit task really does not unlock files whoses lock arose "outside" of it's workflow (how can it tell?) is their a simple way round it? I'd like to avoid a string of locking tasks if possible

Lee C

james1

I've heard of some people running an externaltask (owned by a powerful user) that simply attempts to unlock every file attached to the task as a way to make sure that files are unlocked by the end of the job.

-- James

--
James H Koh
Interwoven Engineering

Adam Stoller

Yes - generally folks run an externaltask with the OOTB IWHOME/local/bin/unlock.ipl script. It's a bit heavy-handed (assuming the owner of the externaltask has rights, it will unlock anything) - but it's the simple solution.

A more complex solution involves writing your own externaltask script that performs that same kind of operation, but which first checks to see if the file is locked and if so by whom, and then based on some logic (yours) determines whether it should atempt to unlock the file. If you have built in an error handler into your workflow, then you might also double-check the end-results before sending a callback to the workflow engine, otherwise just send a callback and hope for the best (which usually works in this case, but ...)

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Lee

Thanks for all of the above info. I guess I'll go with an unlocking externaltask. As an aside I would be interested in knowing how the workflow maintains info on the locks it has set. Is it as corny as looking at the locking comment on the file?

Lee C

nico

What throws me about author submit workflow is if the file unlocks before it is reviewed by an approver and someone else makes a change to the file you are hosed. Am I missing something here?

Thanks,
Nico

Bill Klish

We ran into this problem as well and what we did was make the submittask owned by 'iw_areaowner' and our problems have gone away. I am not completely sure if that presents any problems for you, since I don't know the whole context of your workflow.

nitinc

Dear Nico,
I am facing a peculiar problem. I am just using the default author submit and default author submit dcr workflows that ships with the software. I have just made a small modification making the submit task readonly=false so that when authors submit tasks to editors, the editor can edit the files.

The author has been clicking on new forms in the GUI and submitting the files to editors. When the editor tries to edit the file, it says the the file is still locked by the author. How can I enable passing on the lock to the editor (who is the areaowner) when the author submits?
Rgds,
Nitin

Adam Stoller

When the editor tries to edit the file, it says the the file is still locked by the author. How can I enable passing on the lock to the editor (who is the areaowner) when the author submits?

Well, you could insert an externaltask that calls iwhome/local/bin/unlock.ipl near (or at) the beginning of the workflow and then use the lock="t" attribute on the task(s) following the externaltask -- this should allow the lock to be taken and transferred from task owner to task owner. (it can get a bit complicated though and ideally TS/WF would take care of this for you regardless of how the file was locked, but ...)

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com