Versions Compared

Old Version 3

changes.mady.by.user Unknown User (bramdeschouwer@atmire.com)

Saved on

compared with

New Version 4

changes.mady.by.user Unknown User (bramdeschouwer@atmire.com)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Database changes

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

tasklistitem

Entries in this table represent tasks in a task pool. The changes to this existing database table are the following:

  • Column action_id (ADD, TEXT): This column stores the action ID for which the pool tasks exist
  • Column step_id (ADD, TEXT): This column stores the step ID of the step that contains the action
  • Column workflow_id (ALTER to TEXT): This column stores the workflow process ID for the workflow that contains the step
  • Column workflow_item_id (ADD, INTEGER, REFERENCES workflowitem(workflow_id)): Contains the ID of the workflow item. This column replaces the previous workflow_id column.
  • Column group_id (ADD, INTEGER, REFERENCES epersongroup(eperson_group_id)): Because tasks in a tasks pool can be created for both groups and epersons, an additional group_id column has been added. The eperson_id column existed.

In order to make these changes backwards compatible and in order to maintain support for the old workflow in the JSPUI, the change from the workflow_id column to workflow_item_id must be addressed.

Required to support the old workflow

A number of columns in the existing workflow tables are no longer used by the new workflow framework but should probably not be removed in case the JSPUI still uses the old workflow. These columns are the following:

workflowitem

  • state
  • owner
  • multiple_titles (required for back to submission?)
  • multiple_files (required for back to submission?)
  • published_before (required for back to submission?)

Currently, these changes can be found in the {dspace.src.dir}/etc directory in the file //collection-workflow-changes.sql//. They will have to be moved to the database upgrade and creation scripts for both Oracle and PostgreSQL.

Metadata Schema

The new reviewer workflow framework uses a number of internal metadata fields to store temporary information. This information is used to keep track of the number of people who are performing their task on a workflow item and the number of people who have finished their task. This allows the workflow framework to offer the ability to require multiple people to perform the same action on one workflow item at the same time. The different metadata fields are configured in the //{dspace.dir}/registries/workflow-types.xml// file. Currently, the following metadata fields are used:

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:

  • 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 workflowitemrole
  • workflowitem_id: The xmlwf_workflowitem identifier for which this workflowitemrole has been defined
  • group_id: The group identifier of the group that defines the workflowitemrole role
  • eperson_id: The eperson identifier of the eperson that defines the workflowitemrole role

xmlwf_pooltask

The xmlwf_pooltask 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 step. Multiple rows can exist for one task pool containing multiple groups and epersons. The xmlwf_pooltask table has the following columns:

  • pooltask_id: The identifier of the pooltask and the primaty key of this table
  • workflowitem_id: The identifier of the workflowitem for which this task pool exists
  • workflow_id: The identifier of the workflow configuration used for this workflowitem
  • step_id: The identifier of the step for which this task pool was created
  • action_id: The identifier of the action that needs to be 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 table contains the following columns:

  • claimtask_id: The identifier of the claimtask and the primary key of this table
  • workflowitem_id: The identifier of the workflowitem for which this task exists
  • workflow_id: The id of the 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
  • workflow.step.inProgressUsers: Contains the userIds of the users who are performing a step
  • workflow.step.finishedUsers: Contains the userIds of the users who are performed a step

Other issues

Backwards compatibility

...