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

How to unlock the parent DCR for generated pages?

motlnt

Hi,
It might be a basic question but here is the scenario.
Basically user is generating CFM files from the DCRs and submitting them.
When User edits the cfm by launching it in teamsite that time the parent DCR gets locked under templatdata folder.now after editing the file the user submits the cfm thru the workflow.The CFM file gets submitted well and then gets unlocked.but what happens is that the parent DCR still remains unlocked so if another user comes in and tries editing the CFM file he gets a message saying the file is locked.

I am using the OOTB Teamsite workflow.

any hint how to resolve this so that once the generated CFM file gets submitted it should unlock the parent DCR also?

thx in advance,
==============================
Interwoven certified consultant
TS 6.7.1 on RedHat Linux

Find more posts tagged with

Comments

nipper

Your explanation is not quite clear,

Joe edits foo.cfm which opens foo the DCR.

I assume Joe saves and regenerates the CFM. If the WF was invoked from tt_data, then the DCR and generated page will be submitted. Locks will be maintained by the WF and removed when complete.

If you cannot do that, then you need to add an external task to the WF and attach DCRs when the associated generated page is submitted.

HTH

Andy

motlnt

Let me explain this.
The user does not submit the WF from tt_data but selects the generated page from WA and submits it thru WF.
I think I need to go with your 2nd suggetion and add additional task to handle this.

thx a lot.
==============================
Interwoven certified consultant
TS 6.7.1 on RedHat Linux

Your explanation is not quite clear,

Joe edits foo.cfm which opens foo the DCR.

I assume Joe saves and regenerates the CFM. If the WF was invoked from tt_data, then the DCR and generated page will be submitted. Locks will be maintained by the WF and removed when complete.

If you cannot do that, then you need to add an external task to the WF and attach DCRs when the associated generated page is submitted.

HTH

Andy

nipper

Why not use the tt_data ? That is the easiest.

motlnt

Why not use the tt_data ? That is the easiest.

Thats the whole dilemma.The users are not used to that kind of practice.The tt_dta feature is already enabled for them but they edit the CFM file and then close window w/o submitting it.Which basically locks both CFM and the DCR.Then after couple of days they come and try to submit the edited CFM thru WF which then submits and unlocks only that CFM.
is there any other way beside having external task in WF?

==============================
Interwoven certified consultant
TS 6.7.1 on RedHat Linux

nipper

If threats of violence do not work, then yes and external task would be the easiest

motlnt

If threats of violence do not work, then yes and external task would be the easiest

Certainly, but out of curiosity, isn't it a TS bug?
logically shouldn't TS take care of unlocking/submitting DCRs when the associated generated output files are getting submitted/unlocked?

==============================
Interwoven certified consultant
TS 6.7.1 on RedHat Linux

nipper

Certainly, but out of curiosity, isn't it a TS bug?
logically shouldn't TS take care of unlocking/submitting DCRs when the associated generated output files are getting submitted/unlocked?

==============================
Interwoven certified consultant
TS 6.7.1 on RedHat Linux

I certainly would not consider it a bug. I would be unhappy if IWOV put that into the code. tt_data does what you need, your users don't want to use it.

I happen to edit by hand generated HTML and submit them. I would lose my changes if I the DCR was included (because I have WF regenerate the page).

Another example is I have done a full site regen when TPLs were changed. Then I submitted only the generated pages. Speed was the desire then, since I did not need to have WF invoke datadeploy or query mediabin for updated images.

motlnt

I certainly would not consider it a bug. I would be unhappy if IWOV put that into the code. tt_data does what you need, your users don't want to use it.

I happen to edit by hand generated HTML and submit them. I would lose my changes if I the DCR was included (because I have WF regenerate the page).

Another example is I have done a full site regen when TPLs were changed. Then I submitted only the generated pages. Speed was the desire then, since I did not need to have WF invoke datadeploy or query mediabin for updated images.

But then why is the behavior different for Standard and professional interfaces?
In standard when I try to submit the updated CFM file(generated output file) I am offred an option of 'Submit Additional files' which basically allows me to submit the CFM along with the DCR also.
Why Professional interface does not have that feature?.

==============================
Interwoven certified consultant
TS 6.7.1 on RedHat Linux

nipper

That I cannot answer as I do not touch cc_std.

An option to include additional files would not be unreasonable, but you can do this in the WF easily.

motlnt

That I cannot answer as I do not touch cc_std.

An option to include additional files would not be unreasonable, but you can do this in the WF easily.

Do you have any example of how that is done or any RTFM?

==============================
Interwoven certified consultant
TS 6.7.1 on RedHat Linux

nipper

No sample code, but it should be pretty easy to write an external task.

foreach attached file

if there is a PrimaryDCR EA, then get the DocumentType and build the DCR name from those 2 items and attach it to the task.

Do you have an external task that builds the CFM or do you assume the use did that ? You could add these statements before the iwpt_compile

Andy

motlnt

No sample code, but it should be pretty easy to write an external task.

foreach attached file

if there is a PrimaryDCR EA, then get the DocumentType and build the DCR name from those 2 items and attach it to the task.

Do you have an external task that builds the CFM or do you assume the use did that ? You could add these statements before the iwpt_compile

Andy

I do have an external task in the WF to auto generate the CFMs.

Thanks for the inputs.
==============================
Interwoven certified consultant
TS 6.7.1 on RedHat Linux

nipper

Then easy, in the beginning of that loop through the files that are attached and, if there is a DCR EA but no DCR attached, then attach it.

Also, one point (since I have lived through this before) you probably have something like

@iwfiles = $task->getFiles();

in the beginning, which puts the files into that array. Since you are adding files to the task later, what will not be in @iwfiles, so you can either reread the files attached or use a statement like this (after the AddFile):

$task->AddFile($DCR, "Added DCR");
push(@iwfiles, $DCR);

motlnt

Then easy, in the beginning of that loop through the files that are attached and, if there is a DCR EA but no DCR attached, then attach it.

Also, one point (since I have lived through this before) you probably have something like

@iwfiles = $task->getFiles();

in the beginning, which puts the files into that array. Since you are adding files to the task later, what will not be in @iwfiles, so you can either reread the files attached or use a statement like this (after the AddFile):

$task->AddFile($DCR, "Added DCR");
push(@iwfiles, $DCR);

Great.that was a very useful tip.
I really appreciate.

==============================
Interwoven certified consultant
TS 6.7.1 on RedHat Linux

Adam Stoller

Great.that was a very useful tip.
I really appreciate.

==============================
Interwoven certified consultant
TS 6.7.1 on RedHat Linux

As another tip - since you want to extract two EAs from each file - make use of the '

-r

' flag for iwextattr so you can do so in one system call per file instead of two per file.