Delete workflow

Hi everyone,

I want to implement a delete workflow, which require editor's approval to remove content from the web.

I have a High Level Design for Delete workflow:

Author create new job and attach the DCR of the content which he wanted to remove from portal.
Editor approve or reject the request.
If the request is approved, then External task will call a perl script to delete both the DCR and the file that generated by this DCR, and then remove the database record.
End of workflow.
If the request is rejected, then End of Workflow.

attach is the workflow diagram:

I have a doubt, because the author can delete the DCR in the Content Center using submit workflow. Is there anyway that we can restrict them to not doing so? because that will defeat the purpose of creating this Delete workflow.

Find more posts tagged with

Comments

Adam Stoller

Hi everyone,

I want to implement a delete workflow, which require editor's approval to remove content from the web.

I have a High Level Design for Delete workflow:
Author create new job and attach the DCR of the content which he wanted to remove from portal.
Editor approve or reject the request.
If the request is approved, then External task will call a perl script to delete both the DCR and the file that generated by this DCR, and then remove the database record.
End of workflow.
If the request is rejected, then End of Workflow.
attach is the workflow diagram:

I have a doubt, because the author can delete the DCR in the Content Center using submit workflow. Is there anyway that we can restrict them to not doing so? because that will defeat the purpose of creating this Delete workflow.

The workflow that the Author receives for deleting work should be the same as the one they use for submitting work (at least initially) - both of which are kicked off via the Author clicking on the Submit button/link.

If you're using CCPro exclusively, you could remove the out-of-the-box Delete option(s) and replace them with your own custom Delete option that fired off a specific workflow for delete requests - but I think that's a lot more work and thus likely to take much longer than using a submit workflow (and/or new_job workflow with pre-selected files) to handle it.

You do seem to be missing one part though - unless all your content is handled via a DB (which you mention you wanted to clear the related entry) - which is to delete the file(s) which were deployed to your web server(s) - but that can also be achieved in your externaltask script through the use of OpenDeploy (or similar).

waikong

The workflow that the Author receives for deleting work should be the same as the one they use for submitting work (at least initially) - both of which are kicked off via the Author clicking on the Submit button/link.

If you're using CCPro exclusively, you could remove the out-of-the-box Delete option(s) and replace them with your own custom Delete option that fired off a specific workflow for delete requests - but I think that's a lot more work and thus likely to take much longer than using a submit workflow (and/or new_job workflow with pre-selected files) to handle it.

You do seem to be missing one part though - unless all your content is handled via a DB (which you mention you wanted to clear the related entry) - which is to delete the file(s) which were deployed to your web server(s) - but that can also be achieved in your externaltask script through the use of OpenDeploy (or similar).

Thanks for the resolution.

before I proceed any further, can I ask a sidetrack question here?
it is regarding the configuration in the available_templates.cfg file, I dun understand the following configurations:

element <command_list>
what is the attribute value means?
what is the attribute include means?
<role_list>
what is the attribute alluser?

do anyone mind to give some brief explaination here?
[html]

[/html]

hope guys can to tell me more about that, thanks in advance. Smiley Happy

additionally I found this article, but I dun think it explains my question...

kaalraa

element
what is the attribute value means?
what is the attribute include means?

command_list defines the value of command through which the workflows can be initiated. Some of the possible values are - new_job, submit, assign, tt_data etc. include is being used to specify whether the particular command value would be used to initiate the worklfow or not.

what is the attribute alluser?

role_list defines the TS roles who are being authorised to initiate the workflow, however if allusers=yes is been specified then all the users assigned to that role are authorised. If allusers=no is being specified then you must have to specify the list of users within user_list element.

Adam Stoller

Thanks for the resolution.

before I proceed any further, can I ask a sidetrack question here?
it is regarding the configuration in the available_templates.cfg file, I dun understand the following configurations:
element <command_list>
what is the attribute value means?
what is the attribute include means?
<role_list>
what is the attribute alluser?
do anyone mind to give some brief explaination here?
[html]

[/html]

hope guys can to tell me more about that, thanks in advance.

additionally I found this article, but I dun think it explains my question...

The KB article is, unfortunately, badly written as it uses perl-style comment characters embedded within XML code examples - and the unsuspecting reader of such an article might try to copy/paste the code into their own available_templates.cfg file and end up with a broken system (sigh).

One could also point to the documentation in the TeamSite Workflow Developer's Guide - unfortunately I think it depends on which version of TS you are using as to whether the documentation is accurate or not. The 6.5 manual (e.g.: p. 26) references (as do you) the attribute named value for these elements like

command, role, user

, etc. - but the 6.7 manual (e.g.: p. 29) seems to refer to this attribute as name - and I'm pretty sure it's supposed to be value.

The 6.5 manual, starting around page 30, provides a pretty reasonable description / explanation of the various elements used within the available_templates.cfg file.

Most of the same information (though a bit suspect as noted above) is included in the 6.7.0 manual starting around page 25, however if you're using 6.7.1 you'll want to make sure you carefully read the release notes section as they apparently caught one mistake in their 6.7.0 workflow documentation.

waikong

command_list defines the value of command through which the workflows can be initiated. Some of the possible values are - new_job, submit, assign, tt_data etc. include is being used to specify whether the particular command value would be used to initiate the worklfow or not.role_list defines the TS roles who are being authorised to initiate the workflow, however if allusers=yes is been specified then all the users assigned to that role are authorised. If allusers=no is being specified then you must have to specify the list of users within user_list element.

Thanks kaalraa, it was a very detail answer, and that helps a lot ^^"