Difference between revisions of "Old:Workflow State in Database"

From Dryad wiki
Jump to: navigation, search
Line 4: Line 4:
  
 
= Workspace Processing  =
 
= Workspace Processing  =
 +
 +
== State of item in workspace ==
  
 
*DescribePublicationStep  
 
*DescribePublicationStep  
Line 20: Line 22:
 
After the file specification page is completed (and the submission overview page is displayed), the stage_reached field in the workspaceitem row is set to 3, and page_reached remains 1.  
 
After the file specification page is completed (and the submission overview page is displayed), the stage_reached field in the workspaceitem row is set to 3, and page_reached remains 1.  
  
When the submitter submits the item, the row in workspace item is removed and a row in workflowitem is added.  
+
When the submitter submits the item, the row in workspace item is removed and a row in workflowitem is added.
  
 
= Workflow Processing<br>  =
 
= Workflow Processing<br>  =

Revision as of 15:50, 22 March 2012

Overview

This page describes how the progress of a submitted item is reflected in the Postgres database tables.  This occurs in two phases: an item is in the workspace while a submitter is editing the item, and in the workflow while a curator is reviewing the submission. It may be useful to refer to the DSpace database schema (links to page for Dspace 1.7).

Workspace Processing

State of item in workspace

  • DescribePublicationStep
  • SelectPublicationStep
  • CompletedPublicationStep
  • CompletedDataStep



The item first appears when the submitter completes the publication metadata page.

At this point, the item is represented in the tables item and workspaceitem. The item row specifies the item_id, submitter_id, and false for in_archive and withdrawn. The owning collection is null. The workspace row specifies the workspace_item_id, item_id, and the collection_id (which seems to be a default). The stage_reached is set to 1, as is the page_reached value. The multiple_titles, published_before, and multiple_files fields are null.

After the file specification page is completed (and the submission overview page is displayed), the stage_reached field in the workspaceitem row is set to 3, and page_reached remains 1.

When the submitter submits the item, the row in workspace item is removed and a row in workflowitem is added.

Workflow Processing

State of an item in the workflow

The state of the item in the workflow is stored in the taskowner table which contains the following columns:

  • taskowner_id - row identifier
  • workflow_item_id - id of the workflow_item
  • step_id - string specifying the step (see below)
  • action_id - string specifying the action for the step (needs discussion)
  • workflow_id - string specifying the workflow (seems to be 'default' by default)
  • owner_id - id of the eperson owning the task (e.g., the curator who claimed it)

This table does not appear in the dspace schema mentioned above.

Steps

The workflow consists of a series of steps.  These are defined in {dspace-dir}/config/workflow.xml.  As of Dryad 1.11, these are:

  • requiresReviewStep
  • reviewStep
  • dryadAcceptEditReject
  • pendingPublicationStep
  • pendingdelete

These are the database changes associated with each step:

requiresReviewStep

Curator decides whether the submission requires review.  It reads and then deletes any metadata tagged with "workflow.submit.skipReviewStage".

reviewStep

Activate action Adds a reviewer key to the metadata (workflow.step.reviewerkey, data = <uuid>).  Reads metadata from workflow.review.mailUsers to find reviewers, apart from curators, to review the submission.

Execute action checks for a workflow.step.approved metadata entry to pass the workflow item onto the next step. 

dryadAcceptEditReject

The curator can accept or reject the submission at this step.  If the entry is approved, a dc.description.provenance metadata record, with data "Approved for entry into archive by <curator> on <time>" is added to the item's metadata (metadatavalue table).  If the item is rejected, a dc.description.provenance record, with data "Rejected by <curator>, reason: <reason> " on " <date/time>" is added to the item.  Then the item is returned to the workspace (meaning a new row in workspaceitem is created and filled from the workflowitem row, which is then deleted).

pendingPublicationStep

Handles publication blackouts by putting the workflowitem review_required step if the journal uses blackouts. (this needs verification).

pendingdelete

This handles the case where the item was rejected by reviewers.  It adds a dc.description.provenance metadata record with data "<startid> rejected by <curator or null> reason: rejected by reviewers on <date/time>".  It then pushes the item back into the submitter's workspace.

General Discussion

The new workflowitem row has workflow_id and item_id specified, as is the collection_id.  The fields multiple_titles, published_before, and multiple_files are set.  The state and owner fields are null.  The item row appears to be unaltered at this point.  


When the item is approved, the workflowitem row is deleted, and the item row is updated: in_archive is set true and the item's owning collection is set (it was previously null).  

What an accepted item should look like