Unable to lock files in workflow

lcarr

Running Teamsite 5.5.2 on Windows 2000.

I have a <usertask> in my workflow. I would like to lock files in this task. If I set lock="t", the workflow hangs trying to lock files. The flow is: editor A imports the file into an "import" workarea. A file is attached to the task and moved to editor B's workarea using an <updatetask>. The file is copied to editor B's workarea, but owned by editor A. The workflow is started by a "editor A" who has write access to"editor B's" workarea.

I have also tried using a <locktask>, but this fails too. The locktask is owned by editor B, who owns the workarea containing the file to be locked. I can lock the file manually from the TeamSite webdesk interface when logged in as this user so why can't the workflow do the same?

<----- Workflow Code (work in progress) ------>
Note: editor A is a.k.a iw_user and editor B is a.k.a. iw_editor
<!-- ============================================================ -->
<!-- ======== Add files to task ========== -->
<!-- ======== area (e.g. import) and move task files ========== -->
<!-- ======== to iw_editor's work area ========== -->

<updatetask name="Update Editor Workarea"
owner="__TAG__('iw_editor');"
overwritemod="t"
start="t" lock="f">

__INSERT__("<areavpath v='$editor_wa'/>");

<successorset description="">
<succ v="Unlock Creator Lock"/>
</successorset>

__INSERT__("<srcareavpath v='$area_vpath'/>");


<template_script>
<![CDATA[
# insert file list if we have it
if (__ELEM__('iw_file'))
{
__INSERT__("<files>");
for (my $i=0; $i < @submit_file; ++$i) {
__INSERT__("
<file path='$submit_file[$i]' comment='task file'/>");
}
__INSERT__("\n\t</files>");
}
]]>
</template_script>

</updatetask>

<!-- ============================================================ -->
<!-- ========================== Unlock files ==================== -->

<externaltask name="Unlock Creator Lock"
owner="__TAG__('iw_user');">
__INSERT__("<areavpath v='$area_vpath'/>");
<successors>
<successorset>
<succ v="Author Lock"/>
</successorset>
</successors>
<command v="__INSERT__("$iwhome");/iw-perl/bin/iwperl __INSERT__("$iwhome");/local/bin/unlock.ipl"/>
<activation>
<pred v="Update Editor Workarea"/>
</activation>
</externaltask>

<!-- ============================================================ -->
<!-- ======================= Author Lock ======================== -->

<locktask name="Author Lock"
owner="__TAG__('iw_editor');"
description=""
start="f">

__INSERT__("<areavpath v='$editor_wa'/>");

<success>
<succ v="Author Work"/>
</success>

<failure>
<succ v="Editorial Review"/>
</failure>


</locktask>

<!-- ============================================================ -->
<!-- ======================= Author Work ======================== -->

<usertask name="Author Work"
owner="__TAG__('iw_editor');"
description=""
start="f" lock="f">

__INSERT__("<areavpath v='$editor_wa'/>");
<successors>
<successorset description="Update Files">
<!--succ v="Email Reviewers"/ -->
<succ v="Update Review Workarea"/>
</successorset>
</successors>

</usertask>



<!-- ============================================================ -->
<!-- ======== Move task files to iw_editor's work area ========= -->

<updatetask name="Update Review Workarea"
owner="__TAG__('iw_user');"
overwritemod="t"
start="f" lock="f">

__INSERT__("<areavpath v='$area_vpath'/>");

<successorset description="Editorial Review">
<succ v="Unlock Editor Lock"/>
</successorset>

__INSERT__("<srcareavpath v='$editor_wa'/>");

</updatetask>

Adam Stoller

My guess is that when you import the files, they are automatically locked by TeamSite - and there is a distinction between "TeamSite locks" and "Workflow locks" that has been present since Workflow first came into being.

I can think of two alternatives here - the first is simple, the second is a bit more complex:

1: externaltask that runs IWHOME/local/bin/unlock.ipl preceeding the usertask with lock="t"

2: locktask which upon failure calls the externaltask that runs IWHOME/local/bin/unlock.ipl and then transitions back to the locktask which upon success transitions to the usertask.

Thinking about this a bit more - I'd suggest having failure go to email notification and then to externaltask - just in case something goes wrong and you end up in a loop... or if you're industious, a locktask which goes to an externaltask that maintains state on how many times its been executed, and if it's executed more than once sends email and transitions to another usertask awaiting for someone to resolve the problem and start it back up.

However - I think option '1' should suffice in most cases.

--fish
(Interwoven Senior Technical Consultant)