Page History
...
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 ) will be the superuser if unspecified.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. |
...
- From the "Curate" tab/button that appears on each "Edit Community/Collection/Item" page: this tab allows an Administrator, Community Administrator or Collection Administrator to run a Curation Task on that particular Community, Collection or Item. When running a task on a Community or Collection, that task will also execute on all its child objects, unless the Task itself states otherwise (e.g. running a task on a Collection will also run it across all Items within that Collection).
- NOTE: Community Administrators and Collection Administrators can only run Curation Tasks on the Community or Collection which they administer, along with any child objects of that Community or Collection. For example, a Collection Administrator can run a task on that specific Collection, or on any of the Items within that Collection.
- NOTE: Community Administrators and Collection Administrators can only run Curation Tasks on the Community or Collection which they administer, along with any child objects of that Community or Collection. For example, a Collection Administrator can run a task on that specific Collection, or on any of the Items within that Collection.
- From the Administrator's "Curation Tasks" page: This option is only available to DSpace Administrators, and appears in the Administrative side-menu. This page allows an Administrator to run a Curation Task across a single object, or all objects within the entire DSpace site.
- In order to run a task from this interface, you must enter in the handle for the DSpace object. To run a task site-wide, you can use the handle:
[your-handle-prefix]/0
- In order to run a task from this interface, you must enter in the handle for the DSpace object. To run a task site-wide, you can use the handle:
...
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.
...
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,
...