Page History

For CS to run a task, the code for the task must of course be included with other deployed code (to {{\[DSDOC:dspace\]/lib}}, WAR, etc) but it must also be declared and given a name. This is done via a configuration property in {{\[DSDOC:dspace\]/config/modules/curate.cfg}} as follows:

For many tasks, this activation configuration is all that will be required to use it. But for others, the task needs specific configuration itself. A concrete example is described below, but note that these task-specific configuration property files also reside in {{\[DSDOC:dspace\]/config/modules}}

In the XMLUI, there is a 'Curate' tab (appearing within the 'Edit  Community/Collection/Item') that exposes a drop-down list of configured tasks, with a button to 'perform' the task, or queue it for later operation (see section below). Not all activated tasks need appear in the Curate tab - you filter them by means of a configuration property. This property also permits you to assign to the task a more user-friendly name than the PluginManager _taskname_. The property resides in {{\[DSDOC:dspace\]/config/modules/curate.cfg}}:

CS provides the ability to attach any number of tasks to standard DSpace workflows. Using a configuration file {{\[DSDOC:dspace\]/config/workflow-curation.xml}}, you can declaratively (without coding) wire tasks to any step in a workflow. An example:

The notifications use the same procedures that other workflow notifications do - namely email. There is a new email template defined for curation task use: {{\[DSDOC:dspace\]/config/emails/flowtask_notify}}. This may be language-localized or otherwise modified like any other email template.

In {{\[DSDOC:dspace\]/config/modules/curate.cfg}}, activate the task:

In {{\[DSDOC:dspace\]/config/modules}}, edit configuration file clamav.cfg: