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

Delete folders in submittask

dazzlad

Hi,

I'm having some problems with folder deletion in workflow.

When I list modified and submit file deletions the changes occur fine in staging.

With folders they are still in staging and still appear in the workarea when choosing list modified.

Is there some trick or tip I am missing....

Thanks
Darren

Find more posts tagged with

Comments

james1

Submitting deleted folders requires overwrite. Your submittask is probably waiting for you to "resolve conflicts" or retry with overwrite.

-- James

--
James H Koh
Interwoven Engineering

dazzlad

Thanks James.

Works a treat.

megamala

I am having same problem. I am able to delete the files from staging using submit but not directories.
<submittask name="Submit" owner="$adminuser" start="$submitisstart" unlock="t" override="t" skiplocked="f" description="Submit work" savecomments="t" skipconflicts="t">

Do I need to change any thing to delete the folders from staging when the users submits the deleted folders.(Files its working fine but not folders.)

TIA
MM Guptha

megamala

Can any one help me in this?

TIA
MM Guptha

nipper

Regardless of what the docs say, I have noticed that when directories are deleted, conflicts
happen all the time.

You may want to look at an external perl script that will run iwsubmit (submit direct) which can
overwrite reliably.

HTH

Andy

apache log.png

streamserve log.png

NathansDIS

Hi Nipper-

I know this is an old post, but I thought I would try following up here before starting a new thread. Do you have some example code you can post that shows using an external task to call iwsubmit? I imagine you have to iterate through all the attached files in the task, but being a relative workflow newbie, an example of how this can be done would be very helpful. Let me know if you need any more information about this.

Regards,

Nathan
Washington DIS

Adam Stoller

You'll be better served, performance-wise to determine all the files and create a temporary file that contains the vpaths and file comments interspersed - and then calling iwsubmit once rather than calling it one time per file. The file format is:
----------------------
vpath-1
comment-1
vpath-2
comment-2
...
vpath-N
comment-N
----------------------
Once you have the file/comment list created (e.g. /tmp/foo.txt) you can use the '-f' flag with iwsubmit to reference it (see iwsubmit -h or the CLT manual for usage information).

Generating the list of files based on those assets attached to the task is relatively straight forward for simple files, and only a bit more complex for directories (where you have to recurse through the directories to find the files) this latter part can be done using File::Find or writing your own recursive directory processing subroutine.

If you're dealing with files or directories which have already been removed from the workarea, but not yet from staging (hence the need to submit) the directory processing you do should be done in STAGING, but the paths you use for the vpaths for iwsubmit should use the workarea path - you'll also probably want to include the actual directory names as well. Before you dump all this information into the filelist for iwsubmit - do a reverse sort of the entries so that the directories show up *after* the files contained within the directories (I'm not sure it matters, but it's probably safer and more reliable).

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

app log.png

NathansDIS

Fish-

Thx for the info. I did find some external task logic in one of our workflows that seems similar to what you are suggesting. However, in the meantime, I found a suggestion to skip conflicts, skip locks and override in the submittask in another post that should work for us without going to an external task. We only have one workarea, so the only conflicts that arise are when a folder that is in staging is deleted from the workarea and submitted. This single workarea configuration is the only reason we are able to override conflicts w/o having to worry about code getting clobbered in the case of conflict caused due to the lack of a get latest.

Anyway, here is the workflow code. If anyone notices anything inherently wrong with the code or my above assumptions, please let me know. Thanks for your time.

Regards,

Nathan
Washington DIS

*snip*

<workflow name="Author_Submit"
owner="__TAG__('iw_areaowner');"
creator="__TAG__('iw_areaowner');"
description="__TAG__('iw_submit_comment');">

<externaltask name="Email_Review"
owner="__TAG__('iw_user');"
description="Send Email"
start="t">

<areavpath v="__TAG__('iw_workarea');"/>
<successors>
<successorset description="Review">
<succ v="Review"/>
</successorset>
</successors>
__INSERT__("<command v='$perl_cmd $mail_cmd -t $review_email' />");
<template_script><![CDATA[
if (@submit_file != 0)
{
__INSERT__("<files>\n");
for (my $i=0; $i < @submit_file; ++$i)
{
__INSERT__("
<file path='$submit_file[$i]' " .
"comment='__TAG__(File_comment_$i);'/>");
}
__INSERT__("</files>\n");
}

]]></template_script>
</externaltask>

<grouptask name="Review"
owner="__TAG__('iw_areaowner');"
description="Content Review"
start="f"
readonly="t">
<areavpath v="__TAG__('iw_workarea');"/>
<successors>
<successorset description="7:30am Deploy">
<succ v="Submit"/>
</successorset>
<successorset description="Emergency Deploy">
<succ v="SubmitDeploy"/>
</successorset>
<successorset description="Reject">
<succ v="AuthorWork"/>
</successorset>
</successors>
<sharedby>
__INSERT__("<group v='$approver_group' />");
<user v="dshs/colsoc" />
</sharedby>

</grouptask>

<usertask name="AuthorWork"
owner="__TAG__('iw_user');"
description="Author Work">
<areavpath v="__TAG__('iw_workarea');"/>
<successors>
<successorset description="Changes Complete">
<succ v="Email_Review"/>
</successorset>
</successors>
</usertask>

<submittask name="Submit"
owner="__TAG__('iw_areaowner');"
description="Content Submission"
unlock="t"
savecomments="t">
<areavpath v="__TAG__('iw_workarea');"/>
<success>
<succ v="End"/>
</success>
<failure>
<succ v="Submit2"/>
</failure>
<variables>
<variable key="submit_cmt" value="__TAG__('iw_submit_comment');"/>

</variables>
</submittask>

<submittask name="Submit2"
owner="__TAG__('iw_areaowner');"
description="Content Submission 2 Override no deploy"
skipconflicts="t"
skiplocked="t"
override="t"
unlock="t"
savecomments="t">
<areavpath v="__TAG__('iw_workarea');"/>
<successorset>
<succ v="End"/>
</successorset>
<variables>
<variable key="submit_cmt" value="__TAG__('iw_submit_comment');"/>

</variables>
</submittask>

<submittask name="SubmitDeploy"
owner="__TAG__('iw_areaowner');"
description="Content Submission"
unlock="t"
savecomments="t">
<areavpath v="__TAG__('iw_workarea');"/>
<success>
<succ v="Deploy"/>
</success>
<failure>
<succ v="SubmitDeploy2"/>
</failure>
<variables>
<variable key="submit_cmt" value="__TAG__('iw_submit_comment');"/>

</variables>
</submittask>

<submittask name="SubmitDeploy2"
owner="__TAG__('iw_areaowner');"
description="Content Submission 2 Override"
skipconflicts="t"
skiplocked="t"
override="t"
unlock="t"
savecomments="t">
<areavpath v="__TAG__('iw_workarea');"/>
<successorset>
<succ v="Deploy"/>
</successorset>
<variables>
<variable key="submit_cmt" value="__TAG__('iw_submit_comment');"/>

</variables>
</submittask>

<externaltask name="Deploy"
__INSERT__("owner='$external_task_owner'");
description="Deploy"
>

<areavpath v="__TAG__('iw_workarea');"/>
<successors>
<successorset description="Done">
<succ v="End"/>
</successorset>
</successors>
__INSERT__("<command v='$perl_cmd $od_cmd' />");
</externaltask>

<endtask name="End">
</endtask>

</workflow>

Adam Stoller

The only concern I would have would be with respect to a problem that some folks have reported in 6.x - in which files within the directories that are being deleted may be modified / locked by someone and the deletion of the directory does not remove those locks from those files - which ends up leaving some bizarre conflict situations down the line where TS will complain about locks on files that no longer exist.

I believe the problem is being addressed (perhaps it already has been?) - so it the override when submitting deleted directories may be sufficient.

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

NathansDIS

Fish-

I tested this scenario, where a file in the folder to be deleted was locked. This caused the workflow to hang on 'resolve conflicts' in the submittask and registered the following comment in the task details: Checked out files prevent submitting.

Even as master, I could not resolve the conflict as has been documented in other threads in this forum. FYI, here are the steps I have to take to get the folder deleted. Let me know if I am missing something here or doing something that could cause problems down the road. Thx for your help.

End the job with the conflicting submit task.
Select ‘view deleted files’ and do a get latest to bring the folder I tried to delete back into the workarea.
Select ‘view locked files’ and unlock any locked files in the folder.
Select ‘view all files’ and delete and submit the deleted folder.
If necessary, resolve the conflict in the resulting new workflow as you would normally do.

Rgds,

Nathan
Washington State DIS
~~~

Adam Stoller

Sounds like the right work-around process. Personally I think that you should be given the option to have the submit process take care of removing the locks on files that will be deleted as part of the directory deletion process without having to go through all those manual steps (a confirmation dialog box kind of thing) - but until then - I think you've got the correct process.

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

cc error.png

cc.rar

NathansDIS

If interwoven is listening, it would be nice to be able to configure the submit in this case to either not remove locks, to always remove locks or to prompt in the workflow as you suggested. Just a thought. Thx for your help.

-Nathan
Washington DIS

gzevin

I was pleading about this with IWOV already, both in this forum and thru the support. They say that the issue with locked files will be resolved. I would also want to know when.

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU