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 Content Workflow

frogman

Hi,

More learning on the fly.....

I am putting a "Delete With Approval" Workflow together.

When a Generated Content page is deleted, for good housekeeping I want to be able to delete the associated DCR.

My conundrum is obvious: Once the user has hit Delete in CC, the file is 'gone' - I no longer have access to the PrimaryDCR Extended Attribute to get the parent DCR.

I am not up to speed with UI Customisation yet, so I have put in place a DCR Index XML that is updated when content is generated (and deleted). The XML has nodes:

<dcr path="[PATH TO DCR" content="[PATH TO GENERATED CONTENT]" />

I can access this file to find the DCR for the deleted content.

My question is:

Is there a way to 'capture' the Delete before Teamsite deletes the file?

If not is there any better way to find the DCR?

Thanks.
AAAHGA.

Find more posts tagged with

Comments

iwovGraduate

Is there a way to 'capture' the Delete before Teamsite deletes the file?

I don't think so.... but you probably won't need to.

If not is there any better way to find the DCR?

Sure. Just query the same file for extended attributes in STAGING area. (provided the file was submitted earlier)

iwovGraduate

On second thought -
if you are writing a workflow for deletes, you might want your workflow (externaltask) to actually remove the file from workarea . In other words, instead of users deleting a file and then starting the delete workflow, let them select (not delete) the file they want to delete and start the workflow.

frogman

Thanks iwovGraduate,

That's a great answer (and one which I really wish I'd thought of myself!!).

This fits with our model because, in our system, content can only be generated via our submit workflow, which also submits/deploys the content so the file will always be in STAGING.

Many Thanks

nico

So mabey i'm not following but how does this answer the requirement of deleting both the generated page and it's related dcr? Are you saying let the user browse to both the page and it's dcr within the templatedata directory then select them as part of a delete workflow?

iwovGraduate

... Are you saying let the user browse to both the page and it's dcr within the templatedata directory then select them as part of a delete workflow? ...

Well, thats one way.
However, if the user can find the generated page and its DCR to select and start the workflow, then the user might be better off just deleting them himself/herself. No need for a separate delete workflow in that case.

I think the original query comes from an environment where users mostly deal with generated pages and are not aware of (or don't want to bother about) relation with a DCR. So, users just delete generated pages and submit.

In the proposed solution, users don't delete files, but just select the files they want to delete, and start the workflow. A workflow external task would find the DCR based on ext attr and delete the DCR as well as the generated page (and submit and whatever the wft needs to do).

Does that answer your question ?

nico

yes thanks that does answer my question.

Now if anyone has a code example of how you do this I would appreciate it so I could modify it for my use as well.

Rockin,
Nico

iwovGraduate

It should be quite straight forward. For workflows you can take any of the OOTB workflow. The logic of your externaltask would be something like -


...
foreach my $task_file (@task_files){
    if( $task_file is template generated page ) {
        find $dcr for $task_file
        check for special conditions, locks, other dependencies, etc. (if any)
        delete $dcr, $task_file from workarea
        attach (deleted) $dcr, $task_file to workflow
}
...
callback if no errors.

Adam Stoller

To be a little less cryptic - if you look at the EAs on a generated file (using iwextattr) you can find information that can be used to piece together the path to the DCR from whence the page was generated - and thus have a handle on both.

One place where this process breaks down, however, is when you have DCRs that generate multiple output pages -- in which case you need to provide your own mechanism for tracking all generated pages either from one-another or from the DCR -- and that takes a bit more forethought / design / planning.

If all you're dealing with are single-page-generations - then you have all the information you need from the single generated page to find the DCR and be able to delete, submit, and even deploy those [deletions] files where you need.

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

frogman

Our users do not go near DCRs - As far as they are concerned, they simply complete a DCT Form in CCSTD and submit the result via either a No Approval or a With Approval workflow. Both these workflows generate content and submit and deploy. This means that any content for deletion will be in STAGING so my Delete workflow just checks the STAGING version to get the DCR details when user submits content for Deletion.

The only hole in this at present is that when the user hits Delete, they still get offered all three Workflows: No Approval, Approval and Delete!

So I guess the question is, is there a way to only display the Delete Workflow option if a user has hit Delete? I'm looking at the UI Customisation docs but time is a'tickin - deadline 21/03/05!!!!

Thanks for all the advice.

frogman

And finally, I just found the answer: command_list in available_templates.cfg

I really should RTM more often!