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

Update Task - Maybe I'm just stupid

MrShake

Ok, here is what I'm trying to accomplish:

I want a workflow, that allows a user to attach files in one Branch, and the workflow copies the files to another branch (prod to test or test to prod as an example) and sets appropriate extended attributes.

I was going to write an external task in perl to do that, but the workflow modeler has a task called "Update Task" that says it will do a "Copy to Area" on files attached to the job.

Maybe I'm just stupid, but its confusing me. I see a source vpath variable, but no where to tell it where to PUT the files... no destination vpath.

How does this get set? Basically, how does this Update Task work? the WFM Guides are no help.

Find more posts tagged with

Comments

Rick Poulin

Maybe I'm just stupid, but its confusing me. I see a source vpath variable, but no where to tell it where to PUT the files... no destination vpath.

How does this get set? Basically, how does this Update Task work? the WFM Guides are no help.

The destination path is computed based on the current workarea (within which the workflow is running) and the area-relative paths are taken to be the same as in the source. So basically, your workflow would be a pull from another branch rather than a copy to. Obviously, this only works if the files already exist in the destination branch (otherwise you have nothing to select), and it's probably not all that useful if you're looking to add it as part of a 'publish' type workflow.

If you're still scratching your head, consider that the UpdateTask was intended as the opposite operation of the SubmitTask, i.e. to pull content back from staging to update the workarea.

Migrateduser

Obviously, this only works if the files already exist in the destination branch (otherwise you have nothing to select), and it's probably not all that useful if you're looking to add it as part of a 'publish' type workflow.

Not sure that I agree with this statement. You can set the areavpath to any area to be the destination path - not necessarily the same workarea that is in any other task in the workflow. What's important is that the files exist in the source area.

ISCBorisB

The destination path is computed based on the current workarea (within which the workflow is running) and the area-relative paths are taken to be the same as in the source. So basically, your workflow would be a pull from another branch rather than a copy to. Obviously, this only works if the files already exist in the destination branch (otherwise you have nothing to select), and it's probably not all that useful if you're looking to add it as part of a 'publish' type workflow.

If you're still scratching your head, consider that the UpdateTask was intended as the opposite operation of the SubmitTask, i.e. to pull content back from staging to update the workarea.

To elaborate a little on what Rick said... With this task "areavpath" is task's Target Location.
"srcareavpath" is the source. If the source is areavpath's Branch Staging the Task works like
"Get Latest". If not - like "CopyTo".

Adam Stoller

Perhaps a little clearer than Rick's answer - or maybe not ...

The updateTask updates the contents of the task's areavpath from the task's srcareavpath.

If you want to "push" content from the workarea in which you initiated the job into a different workarea - then just alter that specific task's areavpath and srcareavpath settings (assuming the owner of the task has sufficient rights in both areas.

Examples:

Okay?

MrShake

Ok... that makes sense... basically the missing part I need was the areavpath