Page History

...

As of release 1.7, DSpace includes support for running curation tasks, which are described in this section. DSpace 1.7 and subsequent distributions will bundle (include) several useful tasks, but the system also is designed to allow new tasks to be added between releases, both general purpose tasks the that come from the community, and locally written and deployed tasks.

...

The goal of the curation system ('CS') is to provide a simple, extensible, way to manage routine content operations on a repository. These operations are known to CS as 'tasks', and they can operate on any DSpaceObject (i.e. subclasses of DSpaceObject) - which means Communities, Collections, and Items - viz. core data model objects. Tasks may elect to work on only one type of DSpace object - typically an Item - and in this case they may simply ignore other data types (tasks have the ability to 'skip' objects for any reason). The DSpace core distribution will provide a number of useful tasks, but the system is designed to encourage local extension - tasks can be written for any purpose, and placed in any java package. This gives a DSpace site sites the ability to customize the behavior of their repository without having to alter - and therefore manage - the DSpace source code. What sorts of activities are appropriate for tasks?

...

For each activated task, a 'class'='taskname' line is added. The taskname is used elsewhere to configure the use of the task, as will be seen below. Note that the curate.cfg configuration file, while in the config directory, is located under 'modules'. The intent is that tasks, as well as any configuration they require, will be optional or 'add-on' to the basic configuration. Adding or removing tasks has no impact on dspace.cfg.

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 here note that these configuration property files also reside in {{\[dspace\]/config/modules}}

Writing your own tasks

A task is just a java class that can contain arbitrary code, but the class implementing it must have 2 properties:

First, it must provide a no argument constructor, so it can be loaded by the PluginManager. Thus, all tasks are 'named' plugins, meaning that each must be configured in dspace.cfg as:The 'plugin name'(vscan, req-metadata, etc) is called the task name, and is used instead of the qualified class name wherever it is needed (on the command line, etc) - the CS always dereferences it, with the taskname being the plugin name.

Second, it must implement the interface 'org.dspace.curate.CurationTask'

...

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 Youall mayactivated filtertasks outneed someappear ofin the definedCurate taskstab (not- appropriateyou forfilter UIthem use), by means of a configuration property. This property also permits you to assign to the task a 'prettier' name than the PluginManager task name. The property resides in {{\[dspace\]/config/modules/curate.cfg}}:

...

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

...