Page History

For CS to run a task, the code for the task must of course be included with other deployed code (to {{\[DSDOCDEV:dspace\]/lib}}, WAR, etc) but it must also be declared and given a name. This is done via a configuration property in {{\[DSDOCDEV: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 {{\[DSDOCDEV:dspace\]/config/modules}}

Each of the above pages 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 {{\[DSDOCDEV:dspace\]/config/modules/curate.cfg}}:

The configuration of groups follows the same simple pattern as tasks, using properties in {{\[DSDOCDEV:dspace\]/config/modules/curate.cfg}}. The group is assigned a simple logical name, but also a localizable name that appears in the UI. For example

CS provides the ability to attach any number of tasks to standard DSpace workflows. Using a configuration file {{\[DSDOCDEV: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: {{\[DSDOCDEV:dspace\]/config/emails/flowtask_notify}}. This may be language-localized or otherwise modified like any other email template.

DSpace 1.8 introduces a new 'idiom' for tasks that require configuration data. It is available to any task whose implementation extends _AbstractCurationTask_, but is completely optional. There are a number of problems that task properties are designed to solve, but to make the discussion concrete we will start with a particular one: the problem of hard-coded configuration file names. A task that relies on configuration data will typically encode a fixed reference to a configuration file name. For example, the virus scan task reads a file called 'clamav.cfg', which lives in {{\[DSDOCDEV:dspace\]/config/modules}}. And thus in the implementation one would find:

then 'taskProperty()' will resolve to {{\[DSDOCDEV:dspace\]/config/modules/vscan.cfg}} when called from ClamAv task, but {{\[DSDOCDEV:dspace\]/config/modules/virusscan.cfg}} when called from ConflictTask's code. Note that the 'vscan' etc are locally assigned names, so we can always prevent the 'collisions'mentioned, and we make the tasks much more portable, since we remove the 'hard-coding' of config names.

Another use of task properties is to support multiple task profiles. Suppose we have a task that we want to operate in one of two modes. A good example would be a mediafilter task that produces a thumbnail. We can either create one if it doesn't exist, or run with '-force' which will create one regardless. Suppose this behavior was controlled by a property in a config file. If we configured the task as 'thumbnail', then we would have in {{\[DSDOCDEV:dspace\]/config/modules/thumbnail.cfg}}:

Support for scripted tasks does *not* include any DSpace pre-installation of the scripting language itself - this must be done according to the instructions provided by the language maintainers, and typically only requires a few additional jars on the DSpace classpath. Once one or more languages have been installed into the DSpace deployment, task support is fairly straightforward. One new property must be defined in {{\[DSDOCDEV:dspace\]/config/modules/curate.cfg}}:

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

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

An example configuration file can be found in \[DSDOCDEV:dspace\]/config/modules/translator.cfg.