Page History
...
- apply a virus scan to item bitstreams (this will be our example below)
- profile a collection based on format types - good for identifying format migrations
- ensure a given set of metadata fields are present in every item, or even that they have particular values
- call a network service to enhance/replace/normalize an itemsitem's metadata or content
- ensure all item bitstreams are readable and their checksums agree with the ingest values
Since tasks have access to, and can modify, DSpace content, performing tasks is considered an administrative function to be available only to knowledgeable collection editors, repository administrators, sysadmins, etc. No tasks are exposed in the public interfaces.
Activation
For CS to run a task, the code for the task must of course be included with other deployed code (to {{\ Wiki Markup [dspace
\]/lib
}}, WAR, etc) but it must also be declared and given a name. This is done via a configuration property in {{\[dspace
\]/config/modules/curate.cfg
}} as follows:
Code Block |
---|
plugin.named.org.dspace.curate.CurationTask = \ org.dspace.curate.ProfileFormats = profileformats, \ org.dspace.curate.RequiredMetadata = requiredmetadata, \ org.dspace.curate.ClamScan = vscan |
For each activated task, a key-value pair is added. The key is the fully qualified class name and the value is the taskname 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 'add-ons' to the basic system 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 note that these task-specific configuration property files also reside in {{\[dspace\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 Wiki Markup [dspace]/config/modules
}}
Writing your own tasks
A task is just a java class that can contain arbitrary code, but it must have 2 properties:
...
Code Block |
---|
-t taskname: name of task to peformperform -T filename: name of file containing list of tasknames -e epersonID: (email address) will be superuser if unspecified -i identifier: Id of object to curate. May be (1) a handle (2) a workflow Id or (3) 'all' to operate on the whole repository -q queue: name of queue to process - -i and -q are mutually exclusive -v emit verbose output -r - emit reporting to standard out |
As with other command-line tools, these invocations could be placed in a cron table and run on a fixed schedule, or run on demand by an administrator.
In the admin UI
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 {{\resides in Wiki Markup [dspace
\]/config/modules/curate.cfg
}}:
Code Block |
---|
ui.tasknames = \ profileformats = Profile Bitstream Formats, \ requiredmetadata = Check for Required Metadata |
When a task is selected from the drop-down list and performed, the tab displays both a phrase interpreting the 'status code' of the task execution, and the 'result' message if any has been defined. When the task has been queued, an acknowlegement acknowledgement appears instead. You may configure the words used for status codes in curate.cfg (for clarity, language localization, etc):
Code Block |
---|
ui.statusmessages = \ -3 = Unknown Task, \ -2 = No Status Set, \ -1 = Error, \ 0 = Success, \ 1 = Fail, \ 2 = Skip, \ other = Invalid Status |
In workflow
...
CS provides the ability to attach any number of tasks to standard DSpace workflows. Using a configuration file {{\[dspace
\]/config/workflow-curation.xml
}}, you can declaratively (without coding) wire tasks to any step in a workflow. An example:
Code Block |
---|
<taskset-map> <mapping collection-handle="default" taskset="cautious" /> </taskset-map> <tasksets> <taskset name="cautious"> <flowstep name="step1"> <task name="vscan"> <workflow>reject</workflow> <notify on="fail">$flowgroup</notify> <notify on="fail">$colladmin</notify> <notify on="error">$siteadmin</notify> </task> </flowstep> </taskset> </tasksets> |
This markup would cause a virus scan to occur during step one of workflow for any collection, and automatically reject any submissions with infected files. It would further notify (via email) both the reviewers (step 1 group), and the collection administrators, if either of these are defined. If it could not perform the scan, the site administrator would be notified.
The notifications use the same procedures that other workflow notifications do - namely email. There is a new email template defined for curation task use: {{\ Wiki Markup [dspace
\]/config/emails/flowtask_notify
}}. This may be language-localized or otherwise modified like any other email template.
Like configurable submission, you can assign these task rules per collection, as well as having a default for any collection.
...
The task with the taskname 'formatprofiler' (in the admin UI it is labelled labeled "Profile Bitstream Formats") examines all the bitstreams in an item and produces a table ("profile") which is assigned to the result string. It is activated by default, and is configured to display in the administrative UI. The result string has the layout:
...
The profiler will operate on any DSpace object. If the object is an item, then only that item's bitstreams are profiled; if a collection, all the bitsteams bitstreams of all the items; if a community, all the items of all the collections of the community.
...
This plugin requires a ClamAV daemon installed and configured for TCP sockets. Instructions for installing ClamAV (http://www.clamav.net/doc/latest/clamdoc.pdf )
NOTICE: The following directions assume there is a properly installed and configured clamav daemon. Refer to links above for more information about ClamAV.
The Clam anti-virus database must be updated regularly to maintain the most current level of anti-virus protection. Please refer to the ClamAV documentation for instructions about maintaining the anti-virus database.
DSpace Configuration
In {{\ Wiki Markup [dspace
\]/config/modules/curate.cfg
}}, activate the task:
- Add the plugin to the comma separated list of curation tasks.
...
Code Block |
---|
ui.tasknames = \ profileformats = Profile Bitstream Formats, \ requiredmetadata = Check for Required Metadata, \ vscan = Scan for Viruses |
In {{\ Wiki Markup [dspace
\]/config/modules
}}, edit configuration file clamav.cfg:
Code Block |
---|
service.host = 127.0.0.1 Change if not running on the same host as your DSpace installation. service.port = 3310 Change if not using standard ClamAV port socket.timeout = 120 Change if longer timeout needed scan.failfast = false Change only if items have large numbers of bitstreams |
...