| 71 | 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 |
| 72 | 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. |
| 73 | |
| 74 | 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. |
| 75 | |
| 76 | 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. |
| 77 | |
| 78 | Metadata in the Workspace table uses the same database primary key value as it's original version in the Metadata table. |
| 79 | |
| 80 | The Workspace contents are indexed in Lucene. |
| 81 | |
| 82 | 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. |
| 83 | |
| 84 | 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'''. |
| 85 | |
| 86 | 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. |
| 87 | |
| 88 | 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. |
| 89 | |
| 90 | |
| 91 | |