Page History

...

As of DSpace 7, Configurable Workflow is the only workflow system available in DSpace.  It has fully replaced the older "traditional/basic workflow" system. One major difference is that Configurable Workflow is dynamic – if a user is added to a workflow approval task after a workflow has already begun, they will immediately get access to any existing items in workflow.  Previously, this was not possible in the "traditional" workflow system.

The primary focus of the workflow framework is to create a more flexible solution for the administrator to configure, and even to allow an application developer to implement custom steps, which may be configured in the workflow for the collection through a simple configuration file. The concept behind this approach was modeled on the configurable submission system already present in DSpace.

...

Processing actions are configured similarly to the user selection actions. The only difference is that these processing action beans are implementations of the WorkflowActionConfig class instead of the UserSelectionActionConfig class.

User Interface configuration

Authorizations

Currently, the authorizations are always granted and revoked based on the tasks that are available for certain users and groups. The types of authorization policies that is granted for each of these is always the same:

• READ
• WRITE
• ADD
• DELETE

Database

The workflow uses a separate metadata schema named workflow.  The fields this schema contains can be found The configuration file for the workflow user interface actions is located in the [dspace]/config/spring/xmlui/ and is named "workflow-actions-xmlui.xml".  Each bean defined here has an id which is the action identifier and the class is a classpath which links to the class responsible for generating the User Interface side of the workflow action. Each of the class defined here must extend the org.dspace.app.xmlui.aspect.submission.workflow.AbstractXMLUIAction class, this class contains some basic settings for an action and has a method called addWorkflowItemInformation() which will render the given item with a show full link so you don't have to write the same code in each of your actions if you want to display the item. The id attribute used for the beans in the configuration must correspond to the id used in the workflow configuration. In case an action requires a User Interface class, the workflow framework will look for a UI class in this configuration file.

<beans
    xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:util="http://www.springframework.org/schema/util"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
                           http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.0.xsd">

    <bean id="{action.id}" class="{classpath}" scope="prototype"/>
    <bean id="{action.id.2}" class="{classpath}" scope="prototype"/>
</beans>

Authorizations

Currently, the authorizations are always granted and revoked based on the tasks that are available for certain users and groups. The types of authorization policies that is granted for each of these is always the same:

• READ
• WRITE
• ADD
• DELETE

Database

The workflow uses a separate metadata schema named workflow.  The fields this schema contains can be found in the [dspace]/config/registries directory and in the file workflow-types.xml. This schema is only used when using the score reviewing system at the moment, but one could always use this schema if metadata is required for custom workflow steps.

The following tables have been added to the DSpace database. All tables are prefixed with 'cwf_' to avoid any confusion with the existing workflow related database tables:

cwf_workflowitem

The cwf_workflowitem table contains the different workflowitems in the workflow. This table has the following columns:

• workflowitem_id: The identifier of the workflowitem and primary key of this table
• item_id: The identifier of the DSpace item to which this workflowitem refers.
• collection_id: The collection to which this workflowitem is submitted.
• multiple_titles: Specifies whether the submission has multiple titles (important for submission steps)
• published_before: Specifies whether the submission has been published before (important for submission steps)
• multiple_files: Specifies whether the submission has multiple files attached (important for submission steps)

cwf_collectionrole

registries directory and in the file workflow-types.xml. This schema is only used when using the score reviewing system at the moment, but one could always use this schema if metadata is required for custom workflow steps.

The following tables have been added to the DSpace database. All tables are prefixed with 'cwf_' to avoid any confusion with the existing workflow related database tables:

cwf_workflowitem

The cwf_workflowitem table contains the different workflowitems in the workflow. This The cwf_collectionrole table represents a workflow role for one collection. This type of role is the same as the roles that existed in the original workflow meaning that for each collection a separate group is defined to described the role. The cwf_collectionrole table has the following columns:

• collectionrolworkflowitem_id: The identifier of the collectionrole workflowitem and the primaty primary key of this table
• roleitem_id: The identifier /name used by the workflow configuration to refer to the collectionroleof the DSpace item to which this workflowitem refers.
• collection_id: The collection identifier for which this collectionrole has been defined
• group_id: The group identifier of the group that defines the collection role

cwf_workflowitemrole

• to which this workflowitem is submitted.
• multiple_titles: Specifies whether the submission has multiple titles (important for submission steps)
• published_before: Specifies whether the submission has been published before (important for submission steps)
• multiple_files: Specifies whether the submission has multiple files attached (important for submission steps)

cwf_collectionrole

The cwf_collectionrole table represents a workflow role for one collection. This type of role is the same as the roles that existed in the original workflow meaning that for each collection a separate group is defined to described the role. The cwf_collectionrole The cwf_workflowitemrole table represents roles that are defined at the level of an item. These roles are temporary roles and only exist during the execution of the workflow for that specific item. Once the item is archived, the workflowitemrole is deleted. Multiple rows can exist for one workflowitem with e.g. one row containing a group and a few containing epersons. All these rows together make up the workflowitemrole The cwf_workflowitemrole table has the following columns:

• workflowitemrolecollectionrol_id: The identifier of the workflowitemrole collectionrole and the primaty key of this table
• role_id: The identifier/name used by the workflow configuration to refer to the workflowitemrolecollectionrole
• workflowitemcollection_id: The cwf_workflowitem collection identifier for which this workflowitemrole collectionrole has been defined
• group_id: The group identifier of the group that defines the workflowitemrole collection role
• eperson_id: The eperson identifier of the eperson that defines the workflowitemrole role

cwf_pooltask

cwf_workflowitemrole

The cwf_pooltask workflowitemrole table represents the different task pools that exist for a workflowitem. These task pools can be available at the beginning of a step and contain all the users that are allowed to claim a task in this steproles that are defined at the level of an item. These roles are temporary roles and only exist during the execution of the workflow for that specific item. Once the item is archived, the workflowitemrole is deleted. Multiple rows can exist for one task pool containing multiple groups and epersons. one workflowitem with e.g. one row containing a group and a few containing epersons. All these rows together make up the workflowitemrole The cwf_pooltask workflowitemrole table has the following columns:

• pooltaskworkflowitemrole_id: The identifier of the pooltask workflowitemrole and the primaty key of this tableworkflowitem
• role_id: The identifier of the workflowitem for which this task pool exists
• workflow_id: The identifier of the workflow configuration used for this workflowitem
• /name used by the workflow configuration to refer to the workflowitemrole
• workflowitemstep_id: The cwf_workflowitem identifier of the step for which this task pool was createdworkflowitemrole has been defined
• groupaction_id: The group identifier of the action that needs to be displayed/executed when the user selects the task from the task poolgroup that defines the workflowitemrole role
• eperson_id: The eperson identifier of an the eperson that is part of the task poolgroup_id: The identifier of a group that is part of the task pooldefines the workflowitemrole role

cwf_

...

pooltask

The cwf_claimtask pooltask table represents a the different task that has been claimed by a user. Claimed tasks can be assigned to users or can be the result of a claim from the task pool. Because a step can contain multiple actions, the claimed task defines the action at which the user has arrived in a particular step. This makes it possible to stop working halfway the step and continue later. The cwf_claimtask table contains pools that exist for a workflowitem. These task pools can be available at the beginning of a step and contain all the users that are allowed to claim a task in this step. Multiple rows can exist for one task pool containing multiple groups and epersons. The cwf_pooltask table has the following columns:

• claimtaskpooltask_id: The identifier of the claimtask pooltask and the primary primaty key of this table
• workflowitem_id: The identifier of the workflowitem for which this task pool exists
• workflow_id: The id identifier of the workflow configuration that was used for this workflowitem
• step_id: The step that is currenlty processing the workflowitemidentifier of the step for which this task pool was created
• action_id: The identifier of the action that should needs to be executed by the owner of this claimtask
• owner_id: References the eperson that is responsible for the execution of this task

cwf_in_progress_user

• displayed/executed when the user selects the task from the task pool
• eperson_id: The identifier of an eperson that is part of the task pool
• group_id: The identifier of a group that is part of the task pool

cwf_claimtask

The cwf_claimtask table represents a task that has been claimed by a user. Claimed tasks can be assigned to users or can be the result of a claim from the task pool. Because a step can contain multiple actions, the claimed task defines the action at which the user has arrived in a particular step. This makes it possible to stop working halfway the step and continue later. The cwf_claimtask The cwf_in_progess_user table keeps track of the different users that are performing a certain step. This table is used because some steps might require multiple users to perform the step before the workflowitem can proceed. The cwf_in_progress_user table contains the following columns:

• in_progressclaimtask_user_id: The identifier of the in progress user claimtask and the primary key of this table
• workflowitem_id: The identifier of the workflowitem for which the user is performing or has performed the step.userthis task exists
• workflow_id: The identifier id of the eperson that is performing or has performe the task
• finished: Keeps track of the fact that the user has finished the step or is still in progress of the execution

Additional workflow steps/actions and features

Optional workflow steps: Select single reviewer workflow

This workflow makes it possible to assign a single user to review an item. This workflow configuration skips the task pool option meaning that the assigned reviewer no longer needs to claim the task. The configuration consists of  the following 2 steps.

• AssignStep: During the assignstep, a user has the ability to select a responsible user to review the workflowitem. This means that for each workflowitem, a different user can be selected. Because a user is assigned, the task pool is no longer required.
• ReviewStep: The start of the reviewstep is different than the typical task pool. Instead of having a task pool, the user will be automatically assigned to the task. However, the user still has the option to reject the task (in case he or she is not responsible for the assigned task) or review the item. In case the user rejects the task, the workflowitem will be sent to the another step in the workflow as an alternative to the default outcome.

Optional workflow steps: Score review workflow

The score review system allows reviewers to give the reviewed item a rating. Depending on the results of the rating, the item will be approved to go to the next workflow step or will be sent to an alternative step. The scrore review workflow consists of the following 2 steps.

• ScoreReviewStep: The group of responsible users for the score reviewing will be able to claim the task from the taskpool. Dependingn on the configuration, a different number of users can be required to execute the task. This means that the task will be available in the task pool until the required number of users has at least claimed the task. Once everyone of them has finished the task, the next (automatic) processing step is activated.
• EvaluationStep: During the evaluationstep, no user interface is required. The workflow system will automatically execute the step that evaluates the different scores. In case the average score is more than a configurable percentage, the item is approved, otherwise it is rejected.  (The minimum average score is set by adjusting the minimumAcceptanceScore property passed to evaluationactionAPI in config/spring/api/workflow-actions.xml.)

Workflow overview features

A new features has been added to the XML based workflow that resembles the features available in the JSPUI of DSpace that allows administrators to abort workflowitems. The feature added to the XMLUI allows administrators to look at the status of the different workflowitems and look for workflowitems based on the collection to which they have been submitted. Besides that, the administrator has the ability to permanently delete the workflowitem or send the item back to the submitter.

Known Issues

Curation System

The DSpace 1.7 version of the curation system integration into the original DSpace workflow only exists in the WorkflowManager.advance() method. Before advancing to the next workflow step or archiving the Item, a check is performed to see whether any curation tasks need to be executed/scheduled. The problem is that this check is based on the hardcoded workflow steps that exist in the original workflow. These hardcoded checks are done in the WorkflowCurator and will need to be changed.

Existing issues

...

• workflow configuration that was used for this workflowitem
• step_id: The step that is currenlty processing the workflowitem
• action_id: The action that should be executed by the owner of this claimtask
• owner_id: References the eperson that is responsible for the execution of this task

cwf_in_progress_user

The cwf_in_progess_user table keeps track of the different users that are performing a certain step. This table is used because some steps might require multiple users to perform the step before the workflowitem can proceed. The cwf_in_progress_user table contains the following columns:

• in_progress_user_id: The identifier of the in progress user and the primary key of this table
• workflowitem_id: The identifier of the workflowitem for which the user is performing or has performed the step.
• user_id: The identifier of the eperson that is performing or has performe the task
• finished: Keeps track of the fact that the user has finished the step or is still in progress of the execution

Additional workflow steps/actions and features

Optional workflow steps: Select single reviewer workflow

This workflow makes it possible to assign a single user to review an item. This workflow configuration skips the task pool option meaning that the assigned reviewer no longer needs to claim the task. The configuration consists of  the following 2 steps.

• AssignStep: During the assignstep, a user has the ability to select a responsible user to review the workflowitem. This means that for each workflowitem, a different user can be selected. Because a user is assigned, the task pool is no longer required.
• ReviewStep: The start of the reviewstep is different than the typical task pool. Instead of having a task pool, the user will be automatically assigned to the task. However, the user still has the option to reject the task (in case he or she is not responsible for the assigned task) or review the item. In case the user rejects the task, the workflowitem will be sent to the another step in the workflow as an alternative to the default outcome.

Optional workflow steps: Score review workflow

The score review system allows reviewers to give the reviewed item a rating. Depending on the results of the rating, the item will be approved to go to the next workflow step or will be sent to an alternative step. The scrore review workflow consists of the following 2 steps.

• ScoreReviewStep: The group of responsible users for the score reviewing will be able to claim the task from the taskpool. Dependingn on the configuration, a different number of users can be required to execute the task. This means that the task will be available in the task pool until the required number of users has at least claimed the task. Once everyone of them has finished the task, the next (automatic) processing step is activated.
• EvaluationStep: During the evaluationstep, no user interface is required. The workflow system will automatically execute the step that evaluates the different scores. In case the average score is more than a configurable percentage, the item is approved, otherwise it is rejected.  (The minimum average score is set by adjusting the minimumAcceptanceScore property passed to evaluationactionAPI in config/spring/api/workflow-actions.xml.)

Workflow overview features

The DSpace UI also provides a feature to allow Administrators to see & administer all active workflows (workitems). This feature is provided in the "Administer Workflow" menu option.  Currently, the Administrator has the ability to permanently delete the workflowitem, or to send it back to the original submitter.

...