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

Workflow question

SethHickel

Our users would like to be able to have a person in the role of Editor initiate a workflow that has a group task as its first task. FYI - Our users want each content contributor to have a private workarea. If the Editor starts a
new job does he/she need to select a workarea to associate with that job even if no files are attached? If I read correctly I think the answer is yes.

If so, then can the workflow association be changed to associate with the workarea of the author who takes ownership of the group task? Is the solution to have the workflow copy the files to the authors workarea? Will doing that copy cause the workflow to associate with those files in that authors workarea that they were copied to?

Now, task two is for another Author to tag the file. This is also a group task. Would we then need to copy those files into the second Authors workarea once an Author took the task? Would this then cause the workarea
assocation to change again?

I am considering suggesting that we have workareas for individual development efforts (not individuals) with all authors having access to it/them to eliminate the need of the workflow to be concerned about more then one workarea and all the file copying. So instead of each content contributor having a workarea we would have some number of them that would be re-purposed by the business as they need.

Any thoughts/suggestions appreciated.

Find more posts tagged with

Comments

santosh013

Our users would like to be able to have a person in the role of Editor initiate a workflow that has a group task as its first task. FYI - Our users want each content contributor to have a private workarea. If the Editor starts a
new job does he/she need to select a workarea to associate with that job even if no files are attached? If I read correctly I think the answer is yes.

If so, then can the workflow association be changed to associate with the workarea of the author who takes ownership of the group task? Is the solution to have the workflow copy the files to the authors workarea? Will doing that copy cause the workflow to associate with those files in that authors workarea that they were copied to?

Now, task two is for another Author to tag the file. This is also a group task. Would we then need to copy those files into the second Authors workarea once an Author took the task? Would this then cause the workarea
assocation to change again?

I am considering suggesting that we have workareas for individual development efforts (not individuals) with all authors having access to it/them to eliminate the need of the workflow to be concerned about more then one workarea and all the file copying. So instead of each content contributor having a workarea we would have some number of them that would be re-purposed by the business as they need.

Any thoughts/suggestions appreciated.

I would like to know some more things before commenting.
1)Are you using WFT or WFM?
2)The environment?

Thanks,

SethHickel

WFT, 6.71 on Windows server.

santosh013

Our users would like to be able to have a person in the role of Editor initiate a workflow that has a group task as its first task. FYI - Our users want each content contributor to have a private workarea. If the Editor starts a
new job does he/she need to select a workarea to associate with that job even if no files are attached? If I read correctly I think the answer is yes.

If so, then can the workflow association be changed to associate with the workarea of the author who takes ownership of the group task? Is the solution to have the workflow copy the files to the authors workarea? Will doing that copy cause the workflow to associate with those files in that authors workarea that they were copied to?

Now, task two is for another Author to tag the file. This is also a group task. Would we then need to copy those files into the second Authors workarea once an Author took the task? Would this then cause the workarea
assocation to change again?

I am considering suggesting that we have workareas for individual development efforts (not individuals) with all authors having access to it/them to eliminate the need of the workflow to be concerned about more then one workarea and all the file copying. So instead of each content contributor having a workarea we would have some number of them that would be re-purposed by the business as they need.

Any thoughts/suggestions appreciated.

Hi,
I work on WFM, so will not comment much on WFT, but I hope the basic
fundamentals remains the same.

To sum up,I can only say that in WFM we use to have a workflow configured for a particular workarea/branch.
I hope,this concept works with WFT as well.

Thanks,

ISCBorisB

Our users would like to be able to have a person in the role of Editor initiate a workflow that has a group task as its first task. FYI - Our users want each content contributor to have a private workarea. If the Editor starts a
new job does he/she need to select a workarea to associate with that job even if no files are attached? If I read correctly I think the answer is yes.

If so, then can the workflow association be changed to associate with the workarea of the author who takes ownership of the group task? Is the solution to have the workflow copy the files to the authors workarea? Will doing that copy cause the workflow to associate with those files in that authors workarea that they were copied to?

Now, task two is for another Author to tag the file. This is also a group task. Would we then need to copy those files into the second Authors workarea once an Author took the task? Would this then cause the workarea
assocation to change again?

I am considering suggesting that we have workareas for individual development efforts (not individuals) with all authors having access to it/them to eliminate the need of the workflow to be concerned about more then one workarea and all the file copying. So instead of each content contributor having a workarea we would have some number of them that would be re-purposed by the business as they need.

Any thoughts/suggestions appreciated.

There is no "workflow association [...] with the workarea". Only Task Object has areavpath attribute. Job Object doesn't. What it means is that:

a) You can create a Workflow operating across multiple Areas (one per Task at any given moment).
b) You can modify Tasks' areavpath from external/cgi/url Tasks, see for example TeamSite::WFtask::setArea Method.
c) If the task is "read only", User/Group Task's areavpath may refer to the STAGING or an Edition (eg, "read only" Areas),
not only Workarea. You can not declare a Task without valid areavpath.

So, depending on your WF logic you can identify/set Tasks' associated Areas upfront during WFT Instantiation and/or
change them dynamically using *executable* Tasks

Faizi

As per my understanding it will not worth full, if each content contributor to have a private workarea. If your purpose is maintaining the files backup or file track, behind this then Teamsite already maintaining the file versions and edition. So its not a matter. You can design brach or workarea according to the development to production stages. Lets you can divide into Devlopment, Testing (if there is a testing team) and Production branches/workareas (depends the architecture).
All the production work perform within Production branch and submitted to STAGING. After that using workflow or run IWUPDATE from src to dest (particular branch/workarea). It will updates any TeamSite file, directory, or workarea with the latest version of any file system element. This command acts like the Copy To or (if vpath_from specifies the staging area on that branch) the Get Latest command.
Implementation might be different but hope this will give some pointer.

SethHickel

So, ISCBorisB, it sounds like you are saying that I could have a workflow initiated by an Editor to initially create a group task for a group of Authors. (Does a group task require areavpath?) And this group task can apply to one workarea or to multiple (all Author's ) workareas. But when an Author takes ownership of the task then the areavpath for that task would be set to that Author's workarea. Do we "declare" the task and therefore have the requirement of providing an areavpath at the time that ownership is taken of the group task? (How would this work if you had individual workareas and the editor wanted to attach files to the workflow - would we then need to use something like IWUPDATE to get the attached files from staging for the workarea of the person taking the task?)

And, Faizi, it sounds like in my next step after the first Author has returned the work to a group task that we could use "IWUPDATE from src to dest" to update the Author's workarea who takes ownership of the "tag" task with the file(s) from the original Authors workarea and then set the areavpath for the task to this second Authors workarea.

As a side note: the idea of providing each content contributor with a workarea is a consideration so that we can allow multiple content contributors to work on the same file at the same time.

Thank you. I look forward to your replies. (and others)

Adam Stoller

it sounds like you are saying that I could have a workflow initiated by an Editor to initially create a group task for a group of Authors. (Does a group task require areavpath?)

Yes - a group task requires an areavpath - I believe the only two tasks which do not require an areavpath are dummytask's and endtask's

And this group task can apply to one workarea or to multiple (all Author's ) workareas.

The task can only refer to a single workarea on a single branch at any particular point in time - and the area it refers to would have to be accessible by all the Author's in order for them to be able to take ownership of the task (an Author cannot take ownership of a task associated with an area for which they do not have access)

But when an Author takes ownership of the task then the areavpath for that task would be set to that Author's workarea.

Not quite - you might be able to do this with an iwat trigger script that fires off on the event of the group task being taken, but it is unclear if you can change the areavpath associated with an active task (you might, I'm just not sure)

Do we "declare" the task and therefore have the requirement of providing an areavpath at the time that ownership is taken of the group task?

You have to declare the areavpath in the definition of the task, and although that declaration can get resolved at job instantiation time - it still needs to be declared before the task becomes activated

(How would this work if you had individual workareas and the editor wanted to attach files to the workflow - would we then need to use something like IWUPDATE to get the attached files from staging for the workarea of the person taking the task?)

There are a number of things you might be able to do - not the least of which is to completely re-think your design strategy - but without a better understanding of the actual requirements and process to be implemented, it's all just speculation.

And, Faizi, it sounds like in my next step after the first Author has returned the work to a group task that we could use "IWUPDATE from src to dest" to update the Author's workarea who takes ownership of the "tag" task with the file(s) from the original Authors workarea and then set the areavpath for the task to this second Authors workarea.

As a side note: the idea of providing each content contributor with a workarea is a consideration so that we can allow multiple content contributors to work on the same file at the same time.

Unless you have reasonably tech-savvy contributors I'd say you're heading for a major training exercise - if you allow multiple users to edit the same file at the same time in different workareas you need to train your users about using Get Latest, with and without override, and how to handle merges and conflict resolution. In my experience - most customers want to avoid all of that and generally find it much better to use a single shared workarea on each branch.

SethHickel

Thank you Ghoti. This is very helpful information.