Page History

...

Instructions for Enabling Configurable Reviewer Workflow in XMLUI

DOCUMENTATION NEEDED

Configuration

DSpace.cfg configuration

Currently, there are no workflow configuration options added to the DSpace.cfg configuration file.

Main workflow configuration

The workflow main configuration can be found in the workflow.xml file, located in {dspace.dir}/config. An example of this workflow configuration file can be found bellow.

The submission aspect has been split up into muliple aspects: one submission aspect for the submission process, one workflow aspect containing the code for the original workflow and one xmlworkflow aspect containing the code for the new XML configurable workflow framework. In order to enable one of the two aspects, either the workflow or xmlworkflow aspect should be enabled in the dspace-install-dir/config/xmlui.xconf configuration file. This means that the xmlui.xconf configuration for the original workflow is the following:

<aspect name="Submission and Workflow" path="resource://aspects/Submission/" />
<aspect name="Original Workflow" path="resource://aspects/Workflow/" />

And the xmlui.xconf configuration for the new XML configurable workflow is the following:

<aspect name="Submission and Workflow" path="resource://aspects/Submission/" />
<aspect name="XMLWorkflow" path="resource://aspects/XMLWorkflow/" />

Besides that, a workflow configuration file has been created that specifies the workflow that will be used in the back-end of the DSpace code. It is important that the option selected in this configuration file matches the aspect that was enabled. The workflow configuration file is available in dspace-install-dir/config/modules/workflow.cfg. This configuration file has been added because it is important that a CLI import process uses the correct workflow and this should not depend on the UI configuration. The workflow.cfg configration file contains the following property:

• workflow.framework: possible values are 'originalworkflow' for the original workflow or xmlworkflow for the new XML configurable workflow framework.

Configuration

DSpace.cfg configuration

Currently, there are no workflow configuration options added to the DSpace.cfg configuration file.

Main workflow configuration

The workflow main configuration can be found in the workflow.xml file, located in {dspace.dir}/config. An example of this workflow configuration file can be found bellow.

<?xml version="1.0" encoding="UTF-8"?>
<wf-config>
    <workflow-map>
        <!-- collection to workflow mapping -->
        <name-map collection="default" workflow="{workflow.id}"/>
        <name-map collection="123456789/0" workflow="{workflow.id2}"/>
    </workflow-map>

    <workflow start="{start.step.id}" id="{workflow.id}">

<?xml version="1.0" encoding="UTF-8"?>
<wf-config>
    <workflow-map>
        <!-- collection to workflow mapping -->
        <name-map collection="default" workflow="{workflow.id}"/>
        <name-map collection="123456789/0" workflow="{workflow.id2}"/>
    </workflow-map>

    <workflow start="{start.step.id}" id="{workflow.id}">
        <roles>
         <!-- Roles used in the workflow -->
        </roles>

            <!-- Steps come here-->
            <step id="ExampleStep1" nextStep="ExampleStep2" userSelectionMethod="{UserSelectionActionId}">
            <!-- Step1 config-->
            </step>
        <step id="ExampleStep2" userSelectionMethod="{UserSelectionActionId}">

        </step>
    </workflow>
    <workflow start="{start.step.id2}" id="{workflow.id}">
     <!-- Another workflow configuration-->
    </workflow>
</wf-config>

...

<?xml version="1.0" encoding="UTF-8"?>
<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"/>
.0.xsd">

    <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

Database changes - Original text

The changes made to the database can always be found in the {dspace.src.dir}/etc directory in the file //collection-workflow-changes.sql//.
The workflow uses a separate metadata schema named //workflow// the fields this schema contains can be found in the {dspace.dir}/registries directory and in the file //workflow-types.xml//.

The tables //collectionrole//, //workflowitemrole// where created and are used by the workflow system for the roles (the roles have been described above).
The //tasklistitem// table was altered to contain the step and the action identifiers so that the workflow system knows where in the workflow the item is.
The table //taskowner// was created so that multiple user can claim one item (this was not possible in the old workflow, there the owning user was a field in the workflowitem table).

Database additions

There are a number of important database changes in order to support the new reviewer workflow framework. The following tables have been added:

collectionrole

The collectionrole table stores the the groups that are assigned to one of the collection scope roles. A new entry in this table is created when an administrator creates a new collection role group in the Edit Collection interface. The table has the following columns:

• collectionrole_id (INTEGER): Unique ID for a row in the collectionrole table
• role_id: The (TEXT): Stores the name of this role as specified in the XML configuration document
• collection_id: (INTEGER, REFERENCES collection(collection_id)): The ID of the collection for which the role is defined.
• group_id: (INTEGER, REFERENCES epersongroup(eperson_group_id)): The ID of the group that contains the members of this role.

workflowitemrole

This table stores the the group or eperson that has been assigned to one of the workflow items to perform one of the steps in the workflow. This table stores the item scope workflow roles. For one item, multiple groups or epersons can be configured so multiple rows in this table can correspond to the same item, step and workflow. The selection of the members of these item roles is performed by another action earlier in the workflow. This table contains the following columns:

    <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

Database changes - Original text

The changes made to the database can always be found in the {dspace.src.dir}/etc directory in the file //collection-workflow-changes.sql//.
The workflow uses a separate metadata schema named //workflow// the fields this schema contains can be found in the {dspace.dir}/registries directory and in the file //workflow-types.xml//.

The tables //collectionrole//, //workflowitemrole// where created and are used by the workflow system for the roles (the roles have been described above).
The //tasklistitem// table was altered to contain the step and the action identifiers so that the workflow system knows where in the workflow the item is.
The table //taskowner// was created so that multiple user can claim one item (this was not possible in the old workflow, there the owning user was a field in the workflowitem table).

Database additions

There are a number of important database changes in order to support the new reviewer workflow framework. The following tables have been added:

collectionrole

The collectionrole table stores the the groups that are assigned to one of the collection scope roles. A new entry in this table is created when an administrator creates a new collection role group in the Edit Collection interface. The table has the following columns:

• collectionroleworkflowitemrole_id (INTEGER): Unique ID for a row in the workflowitemrole collectionrole table.
• role_id: The (TEXT): Stores the name of this role as specified in the XML configuration document.
• collectionworkflow_item_id (INTEGER, REFERENCES workflowitem(workflow_id)): The workflow item for which the role has been configured.eperson_id (INTEGER, REFERENCES epersoncollection(epersoncollection_id)): The eperson that has been configured for this workflow item role. This value can be empty in case a group has been configuredID of the collection for which the role is defined.
• group_id: (INTEGER, REFERENCES epersongroup(eperson_group_id)): The ID of the group that has been configured for this workflow item contains the members of this role. This value can be empty in case an eperson has been configured.

taskowner

workflowitemrole

This table stores the the group or eperson that has been assigned to one of the workflow items to perform one of the steps in the workflow. This table stores the item scope workflow roles. For one item, multiple groups or epersons can be configured so multiple rows in this table can correspond to the same item, step and workflow. The selection of the members of these item roles is performed by another action earlier in the workflow. This This table contains all the tasks that belong to an eperson. Entries in this table are created when a user claims a certain task from the task pool or can be automatically created when automated action assigns the user to a task. The taskowner table contains the following columns:

• taskownerworkflowitemrole_id (INTEGER): Unique ID for a row in the taskowner tableworkflowitemrole table.
• role_id (TEXT): Stores the name of this role as specified in the XML configuration document.
• workflow_item_id (INTEGER, REFERENCES workflowitem(workflow_id)): The ID of the workflow item for which an eperson has a task assigned/claimed.
• action_id (TEXT): The ID of the action the eperson has claimed or has been assigned to.
• step_id (TEXT): The ID of the step that contains the action.
• workflow_id (TEXT): The ID of the workflow process that contains the step.
• owner_id (INTEGER, REFERENCES eperson(eperson_id)): The ID of the eperson who owns the task.

Database changes

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

xmlwf_workflowitem

The xmlwf_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)

xmlwf_collectionrole

The xmlwf_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 xmlwf_collectionrole table has the following columns:

• collectionrol_id: The identifier of the collectionrole and the primaty key of this table
• role_id: The identifier/name used by the workflow configuration to refer to the collectionrole
• 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

xmlwf_workflowitemrole

The xmlwf_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 xmlwf_workflowitemrole table has the following columns:

• the role has been configured.
• eperson_id (INTEGER, REFERENCES eperson(eperson_id)): The eperson that has been configured for this workflow item role. This value can be empty in case a group has been configured.
• group_id (INTEGER REFERENCES epersongroup(eperson_group_id)): The group that has been configured for this workflow item role. This value can be empty in case an eperson has been configured.

taskowner

This table contains all the tasks that belong to an eperson. Entries in this table are created when a user claims a certain task from the task pool or can be automatically created when automated action assigns the user to a task. The taskowner table contains the following columns:

• taskowner_id (INTEGER): Unique ID for a row in the taskowner table.
• workflow_item_id (INTEGER, REFERENCES workflowitem(workflow_id)): The ID of the workflow item for which an eperson has a task assigned/claimed.
• action_id (TEXT): The ID of the action the eperson has claimed or has been assigned to.
• step_id (TEXT): The ID of the step that contains the action.
• workflow_id (TEXT): The ID of the workflow process that contains the step.
• owner_id (INTEGER, REFERENCES eperson(eperson_id)): The ID of the eperson who owns the task.

Database changes

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

xmlwf_workflowitem

The xmlwf_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)

xmlwf_collectionrole

The xmlwf_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 xmlwf_collectionrole table has the following columns:

• collectionrol_id: The identifier of the collectionrole workflowitemrole_id: The identifier of the workflowitemrole 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 xmlwf_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

...

xmlwf_workflowitemrole

The xmlwf_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 xmlwf_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 xmlwf_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

xmlwf_

...

pooltask

The xmlwf_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 xmlwf_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 xmlwf_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

xmlwf_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

xmlwf_claimtask

The xmlwf_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 xmlwf_claimtask The xmlwf_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 xmlwf_in_progress_user table contains the following columns:

• in_progress_userclaimtask_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

Backwards compatibility

Aspects and configuration files

In order to be backwards compatible with previous versions of DSpace, a number of changes have been made to the existing submission/workflow aspect. The submission aspect has been split up into muliple aspects: one submission aspect for the submission process, one workflow aspect containing the code for the original workflow and one xmlworkflow aspect containing the code for the new XML configurable workflow framework. In order to enable one of the two aspects, either the workflow or xmlworkflow aspect should be enabled in the dspace-install-dir/config/xmlui.xconf configuration file. Besides that, a workflow configuration file has been created that specifies the workflow that will be used in the back-end of the DSpace code. It is important that the option selected in this configuration file matches the aspect that was enabled. The workflow configuration file is available in dspace-install-dir/config/modules/workflow.cfg. This configuration file has been added because it is important that a CLI import process uses the correct workflow and this should not depend on the UI configuration. The workflow.cfg configration file contains the following propertu:

...

• 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

xmlwf_in_progress_user

The xmlwf_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 xmlwf_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

Backwards compatibility

Workflowitem conversion/migration scripts

...