Improvements to Metadata workflow

Date	2012/09/21
Contact(s)	Heikki Doeleman, Jose García, Steven Smolders
Last edited
Status	Proposed for vote
Assigned to release	2.9
Resources	from AGIV ​http://www.agiv.be
Ticket #	TBD

Overview

The current support for workflow in GeoNetwork is somewhat limited. Metadata can be in one of a number of workflow-related states, but state transitions are not restricted. When a metadata is public, an editor who makes changes and saves, cannot prevent those changes to become visible to the public unless the metadata is made invisible to the public. This proposal introduces somewhat more strict lifecycle transitions along with a mechanism where metadata remains publicly visible even when an editor is in the process of changing it and saving his changes.

Proposal Type

• Module: ALL

Links

• Documents
• Email discussions:
• Other wiki discussions:

Voting History

---

Motivations

• A well-defined workflow helps increase quality of the metadata.
• Keeping the original public version of a metadata public, while an editor is taking time to makes changes to it, helps increase quality of the catalogue.
• This proposal introduces better pessimistic locking: compatible with clustered GeoNetwork catalogues, and editors no longer lose their work.

Proposal

stricter state transitions

The only state transitions that are allowed, are:

DRAFT -> SUBMITTED

SUBMITTED -> REJECTED

SUBMITTED -> APPROVED

REJECTED -> DRAFT

APPROVED -> DRAFT

(the status RETIRED and UNKNOWN are not considered here).

Note that Administrator users are able to make any state transition anyway.

better state awareness through icons

To make immediately clear what the state is of a metadata, colourful icons (and the state name) indicate this in the search results and in the metadata view. This information is only displayed to users who are logged in to GeoNetwork.

This is a screenshot of how this looks like in search results in the classic GUI:

This is a screenshot of how this looks like in one of the Ext GUIs:

workspace

In order to allow a metadata to remain publicly visible (in its original state) while it is being edited, we introduce the concept of Workspace. The workspace is a table in the database that has exactly the same structure as the table Metadata. When a metadata transitions to state DRAFT (i.e. an Editor user starts to make changes to it), a copy of the metadata in the Metadata table is inserted in the Workspace table.

The GeoNetwork editor operates on this Workspace table. So, the Editor user can save as many times, even for an extended period, but the original un-modified metadata remains publicly visible.

When the Editor user is finished he changes the metadata status to SUBMITTED. A Reviewer user now must decide whether the changes are accepted. If not, the Reviewer sets the metadata status to REJECTED and the metadata is waiting for the Editor user to start editing it again. If on the other hand, the changes are accepted, the Reviewer changes the metadata status to APPROVED. In this case, the version of the metadata in the Workspace table is copied over the same metadata in the Metadata table, and removed from the Workspace table. Now the changes have become publicly visible.

Metadata in the Workspace table uses the same database primary key value as it's original version in the Metadata table.

The Workspace contents are indexed in Lucene.

Editor users who are logged in, will retrieve the Workspace versions of metadata in their search results, if they are in a Group that is allowed to edit this metadata.

Metadata that is in DRAFT state is 'locked'. This means that only the user who owns the lock (i.e., started the edit session) is allowed to open it for editing. This is a muh better implementation of pessimistic locking than currently in GeoNetwork, where a second user could start editing the same metadata that's already being edited by another user, only to get an error message when he tries to save and lose his work.

In order to prevent endless locking, if an editor who owns a lock goes on holidays or such, Reviewer users have the option to change the owner of the lock to themselves or to any other Editor or Reviewer user in the groups that are allowed to edit this metadata.

If the system configuration setting 'Symbolic Locking' is enabled, also Editor users (in groups that are allowed to edit this metadata) can transfer ownership of the lock.

Backwards Compatibility Issues

None.

New libraries added

Nope.

Risks

Participants

Heikki Doeleman, Jose García, Steven Smolders