All Versions
- DSpace 7.x (Current Release)
- DSpace 8.x (Unreleased)
- DSpace 6.x (EOL)
- DSpace 5.x (EOL)
- More Versions...
...
Code Block |
---|
[dspace]/bin/dspace curate -t vscan -i 123456789/4 |
The complete list of argumentsoptions:
...
option | meaning |
---|---|
-t |
...
taskname |
...
name |
...
of |
...
task |
...
to |
...
perform |
...
. |
-T |
...
filename |
...
name |
...
of |
...
file |
...
containing |
...
a list |
...
of |
...
tasknames |
...
to be performed. |
-e |
...
epersonID |
...
(required) email |
...
address or netid of the E-Person performing the task | |
-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. |
-l limit | maximum number of objects in Context cache. If absent, unlimited objects may be added. |
-s scope | declare a scope for database transactions. Scope must be: (1) 'open' (default value), (2) 'curation' or (3) 'object'. |
-v | emit verbose output |
-r filename | emit reporting to the named file. '-r -' writes reporting to standard out. If not specified, report is discarded silently. |
-p name=value | set a runtime task parameter name to the value value . May be repeated as needed. See "Task parameters" below. |
As with other command-line 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.
...
[your-handle-prefix]/0
...
Code Block |
---|
curate.ui.statusmessages = -3 = Unknown Task curate.ui.statusmessages = -2 = No Status Set curate.ui.statusmessages = -1 = Error curate.ui.statusmessages = 0 = Success curate.ui.statusmessages = 1 = Fail curate.ui.statusmessages = 2 = Skip curate.ui.statusmessages = other = Invalid Status |
As the number of tasks configured for a system grows, a simple drop-down list of all tasks may become too cluttered or large. DSpace 1.8+ provides a way to address this issue, known as task groups. A task group is a simple collection of tasks that the Admin UI will display in a separate drop-down list. You may define as many or as few groups as you please. If no groups are defined, then all tasks that are listed in the ui.tasknames property will appear in a single drop-down list. If at least one group is defined, then the admin UI will display two drop-down lists. The first is the list of task groups, and the second is the list of task names associated with the selected group. A few key points to keep in mind when setting up task groups:
The configuration of groups follows the same simple pattern as tasks, using properties in [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:
Report output from tasks run in this way is collected by configuring a Reporter plugin. You must have exactly one Reporter configured. The default is to use the FileReporter, which writes a single report of the output of all tasks in the run over all of the selected objects, to a file in the reports directory (configured as report.dir). See [DSpace]/config/modules/submission-configuration
.cfg for the value of plugin.single.org.dspace.curate.Reporter
. Other Reporter implementations are provided, or you may supply your own.
As the number of tasks configured for a system grows, a simple drop-down list of all tasks may become too cluttered or large. DSpace 1.8+ provides a way to address this issue, known as task groups. A task group is a simple collection of tasks that the Admin UI will display in a separate drop-down list. You may define as many or as few groups as you please. If no groups are defined, then all tasks that are listed in the ui.tasknames property will appear in a single drop-down list. If at least one group is defined, then the admin UI will display two drop-down lists. The first is the list of task groups, and the second is the list of task names associated with the selected group. A few key points to keep in mind when setting up task groups:
The configuration of groups follows the same simple pattern as tasks, using properties in [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:
Code Block |
---|
# ui.taskgroups contains the list of defined groups, together with a pretty name for UI display
curate.ui |
Code Block |
# ui.taskgroups contains the list of defined groups, together with a pretty name for UI display
curate.ui.taskgroups = replication = Backup and Restoration Tasks
curate.ui.taskgroups = integrity = Metadata Integrity Tasks
.....
# each group membership list is a separate property, whose value is comma-separated list of logical task names
curate.ui.taskgroup.integrity = profileformats, requiredmetadata
....
|
...
Code Block | ||
---|---|---|
| ||
<taskset-map> <mapping collection-handle="default" taskset="cautious" /> </taskset-map> <tasksets> <taskset name="cautious"> <flowstep name="step1editstep"> <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 the "editstep" of workflow for any collection, and automatically reject any submissions with infected files. It would further notify (via email) both the reviewers (step 1 "editstep" role/group), and the collection administrators, if either of these are defined. If it could not perform the scan, the site administrator would be notified.
...
Tasks wired in this way are normally performed as soon as the workflow step is entered, and the outcome action (defined by the 'workflow' element) immediately follows. It is also possible to delay the performance of the task - which will ensure a responsive system - by queuing the task instead of directly performing it:
Code Block | ||
---|---|---|
| ||
... <taskset name="cautious"> <flowstep name="step1editstep" queue="workflow"> ... |
This attribute (which must always follow the "name" attribute in the flowstep element), will cause all tasks associated with the step to be placed on the queue named "workflow" (or any queue you wish to use, of course), and further has the effect of suspending the workflow. When the queue is emptied (meaning all tasks in it performed), then the workflow is restarted. Each workflow step may be separately configured,
Like configurable submission, you can assign these task rules per collection, as well as having a default for any collection.
As with task invocation from the administrative UI, workflow tasks need to have a Reporter configured in submission-configuration.cfg
.
If these pre-defined ways are not sufficient, you can of course manage curation directly in your code. You would use the CS helper classes. For example:
Code Block | ||
---|---|---|
| ||
Collection coll = (Collection)HandleManager.resolveToObject(context, "123456789/4"); Curator curator = new Curator(); curator.setReporter(System.out); curator.addTask("vscan").curate(coll); System.out.println("Result: " + curator.getResult("vscan")); |
would do approximately what the command line invocation did. the method "curate" just performs all the tasks configured (you can add multiple tasks to a curator).
The above directs report output to standard out. Any class which implements Appendable may be set as the reporter class.
...
For very fine-grained information, a task may write to a reporting stream. This stream is may be sent to a file or to standard out, so is only available when running a task from the command linefrom the command line. Tasks run from the administrative UI or a workflow use a configured Reporter class to collect report output. Your own code may collect the report using any implementation of the Appendable interface. Unlike the result string, there is no limit to the amount of data that may be pushed to this stream.
...
Consider what happens: when we perform the task "thumbnail
" (using taskProperties), it uses the thumbnail.*
properties and operates in "non-force" profile (since the value is false), but when we run the task "thumbnail.force
" the curation system uses the thumbnail.force.*
properties. Notice that we did all this via local configuration - we have not had to touch the source code at all to obtain as many "profiles" as we would like.See Curation Tasks: Task Properties for details of how properties are resolved in task code.as we would like.
See Task Properties in Curation Tasks for details of how properties are resolved in task code.
New in DSpace 7, you can pass parameters to a task at invocation time. These runtime parameters will be presented to the task as if they were task properties (see above) and, if present, will override the value of identically-named properties. Example:
Code Block | ||||
---|---|---|---|---|
| ||||
bin/dspace curate -t reticulate -i 123456789/36 -p foreground=red -p background=green |
Info |
---|
The procedure to set up curation tasks in Jython is described on a separate page: Curation tasks in Jython |
...