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

"Where" works a workflow

meikel

Hi,
Imagine you have a simple workflow. One is editing a DCR another one is checking it and submits it.
Where does this workflow work?
I mean: This is in the working area. And after the submit the DCR is copied into the staging area.
You don't use workflows in the staging area.

Is that right? Help me to convinve my supervisor.
Regards meikel

Find more posts tagged with

Comments

Migrateduser

What problem are you trying to solve? Do you have any experience with TeamSite workflow? You mention one workflow, but then in the next sentence you break it into two. Consider taking workflow training from Interwoven.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

meikel

Nonono,
not one "workflow". I meant one "person" :-)
Background is: I have a discussion with my supervisor. He means that the submit workflow works in the staging area.
I know he isn't right,but he is still my supervisor. So I need some arguments.

meikel

Migrateduser

It's still not clear what you are talking about. Does he think the workflow could possibly corrupt the STAGING area? What is he afraid the workflow is going to do?

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

meikel

I only need help for the argueing.
HE compares TS with CVS. And says you can only make versions from a file, when you are doing workflows in the staging area.
I mean you only can make version, when you submit it into staging area and create a edition.

maybe i can describe it not good enough in english.

Migrateduser

Yes I think something is getting lost in the translation. I am sorry I simply don't understand. Perhaps someone else will be able to jump in here and understand what argument you are trying to make.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

mogoo

Lemme take a crack at this...
If, by CVS, you mean Concurrent Versions System, then it's a process similar to teamsite... minus the workflow.

Staging is a read-only area that brings together edited content from workareaA, workareaB, etc. Workflows can have editing effects only on files in workareas and version/deploy effects only on files in staging. A workflow like the one you described would go something like this...

Let's say user "Elroy" edits a DCR in his workarea, called eOne. After all edits are made, Elroy closes the DCR, and a prompt asks him if he wants to submit the page for approval. He does, which starts a workflow. The job appears in the ToDo list, waiting for Elroy's supervisor, "George" to review and approve. When George looks at the DCR attached to the job, he is still looking at the file in the eOne workarea. George may make further edits to the DCR, which will edit the version in the eOne workarea. Upon approval, the DCR gets submitted to staging...

(As a side note, once the DCR gets submitted to staging, a version is made of the DCR. You can view past versions on an individual file by selecting the file, then choosing View-->History.)

From there, you can use command line tools in the workflow to create editions and/or deploy. These 2 functions work on the staging area, just like they do through the GUI. An edition is a snapshot of whatever's in staging at that moment. When you deploy to another server, you're deploying from the staging area.

Generally, I don't think it's common practice to cut editions as a result of a submit workflow... though I'm sure there are instances of that out there. I believe it is more common to cut an edition via a cron job once a day, or once a week. So VERSIONS are made of each individual file when they get submitted to staging, but an EDITION is something that has to be cut via the gui or clt.

Does this help clarify at all?
maureen

Migrateduser

My hero...

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Adam Stoller

Let's say user "Elroy" edits a DCR in his workarea, called eOne. After all edits are made, Elroy closes the DCR, and a prompt asks him if he wants to submit the page for approval. He does, which starts a workflow. The job appears in the ToDo list, waiting for Elroy's supervisor, "George" to review and approve. When George looks at the DCR attached to the job, he is still looking at the file in the eOne workarea. George may make further edits to the DCR, which will edit the version in the eOne workarea. Upon approval, the DCR gets submitted to staging...

This was pretty much the kind of description I was thinking of when reading the original post - though I probably would also consider having tasks to generate output files from the DCR and/or handling rejections, etc. built into the workflow so that it would represent a complete process for developing a DCR and its [usually] associated page.

Generally, I don't think it's common practice to cut editions as a result of a submit workflow... though I'm sure there are instances of that out there. I believe it is more common to cut an edition via a cron job once a day, or once a week. So VERSIONS are made of each individual file when they get submitted to staging, but an EDITION is something that has to be cut via the gui or clt.

Actually, in 5.5.2, editions are cut on every submit operation - they're just "hidden" editions (do an iwlist -k branchvpath/EDITION to see an example)

--fish
(Interwoven Senior Technical Consultant)