Project

General

Profile

Actions

feature request #6655

closed

Implement a RegistrationManager with state machine

Added by Andreas Kohlbecker almost 7 years ago. Updated over 5 years ago.

Status:
Rejected
Priority:
Highest
Category:
cdm-vaadin
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Severity:
major

Description

RegistrationManager

UPDATE: this idea has been rejected in favour of granting per entity permissions to submitters. (see #6867, #7520, #7528 with 5ce3b66a by which the RegistrationStatusTransitions has been introduced, ...?)

The RegistrationManager will perform updates on the Registration entities on behalf of the submitter and curator

A RegistrationManager is needed ...

  • to control state changes (state machine?)
  • because the submitter needs to add typeDesignations after the Registration has been created.

These reasons are discussed in detail below.

Stage changes will also be triggered via the REST services, (see #7012) this will require the remote user to be granted with the CdmAuthoritiy (REGISTRATION.[UPDATE]{${uuid}}) or with REGISTRATION(${RegistrationStatusTypes}).[UPDATE]{${uuid}} whereas ${RegistrationStatusTypes is a comma separated list of status types (see also below and #7026 where this is implemented).

Adding TypeDesignations to an existing Registration

In the workflow as implemented currently a Registration is initially created without associated type designations. That is the user will need to add type designations after the creation of the Registration entity. This would require the user to be granted with the according per entity CdmAuthority. But for security reasons it seems undesirable to grant UPDATE permissions even for specific Registrations being in the state of PREPARATION to the user. Genereal UPDATE permissions on Registrations are too dangerous, this general permission should never be given to any submitter. Therefore only potential issues related to per entity CdmAuthorities (REGISTRATION.[UPDATE]{${uuid}}) are being discussed:

  • Bugs in the UI (Vaadin, Taxeditor) might open up options for arbitrary state changes
  • Once a Registration has left the state PREPARATION the per entity permission must be revoked. UPDATE: This has been implemented in #6867 with the `GrantedAuthorityRevokingRegistrationUpdateLister', which however misses to support the next point ...
  • Once the curator decides to give the Registration back to the submitter the state will change again to PREPARATION` and the submitter again needs to be able to add typeDesignations. UPDATE: This does not work at the moment, see #7520 for details

    • this could rather easily be achieved by extending the Registration authorities by an optional property which refers to the state of the Registration: REGISTRATION(${RegistrationStatusTypes}).[UPDATE]{${uuid}}, whereas ${RegistrationStatusTypes is a comma separated list of status types. The authority is only applicable as long as the Registration is in the named status. (see #7026 where this is implemented).
  • Write access to Registrations may become possible via the REST services. In this case a user could apply arbitrary modifications to a Registration.

  • Arbitrary modifications are also possible via the HTTPInvoker service

State changes

We need a RegistrationManager which can change the RegistrationState on behalf of the user, if the user is not permitted to change the Registration again (see #6654, see first step and second step --> this issue only is needed for the second step!!!). The user can request the RegistrationManager for state changes by sending a RegistrationStateEvent.

The RegistrationStateEvent can transport the following messages to which the RegistrationManager will react accordingly to the current state, the users permission sending the event:

The RegistrationManager uses the following internal permission tests:

  • isRegistrationCurator: user.hasGrantedAuthority("Registration.[UPDATE]")
  • isAllowedSumbitter: user = Registration.submitter AND user.hasGrantedAuthority("Registration.[CREATE]")
RegistrationStateEvent RegistrationManager
Event message tests state to check new state
WITHDRAW isAllowedSumbitter OR isRegistrationCurator not PUBLISHED REJECTED
DATA_VALID isRegistrationCurator not PUBLISHED OR REJETCED READY
DATA_INCOMPLETE isRegistrationCurator not PUBLISHED OR REJETCED PREPARATION
PUBLISHED isRegistrationCurator && publication.datePublished != null READY PUBLISHED
  • Walter suggested automatic setting of PUBLISHED: When the registration state is READY the RegistrationManager could listen for changes of the datePublished of the related citation. Once the datePublished is set to a non null value the RegistrationState will automatically be set to PUBLISHED. UPDATE: This would shortcut the curatorial process and must be rejected therefore.

Related issues

Related to EDIT - feature request #6654: implement a CdmPermissionVoter for RegistrationsClosedAndreas Kohlbecker

Actions
Related to EDIT - feature request #7026: RegistrationVoter evaluates CdmAuthorities with RegistrationStatus propertiesClosedAndreas Kohlbecker

Actions
Related to EDIT - bug #7520: Restore GrantedAuthorities removed by GrantedAuthorityRevokingRegistrationUpdateLister when the regsitration state returns to PREPARATIONNewAndreas Kohlbecker

Actions
Related to EDIT - bug #7528: Allow changing the Registration status in the RegistrationWorkingsetEditorClosedAndreas Kohlbecker

Actions
Related to EDIT - bug #7995: Registration.registrationDate not set when status is set PUBLISHEDClosedAndreas Kohlbecker

Actions
Blocked by PhycoBank - task #6168: Full registration workflow modelClosedWolf-Henning Kusber

Actions
Precedes EDIT - feature request #6867: explicitely assign and revoke UPDATE & DELETE permission per enitity in the registration workflow ClosedAndreas Kohlbecker

Actions
Actions #1

Updated by Andreas Kohlbecker almost 7 years ago

  • Description updated (diff)
Actions #2

Updated by Andreas Kohlbecker almost 7 years ago

  • Description updated (diff)
Actions #3

Updated by Andreas Kohlbecker almost 7 years ago

Actions #4

Updated by Andreas Kohlbecker almost 7 years ago

  • Description updated (diff)
  • Target version changed from Release 4.9 to Unassigned CDM tickets
Actions #5

Updated by Andreas Kohlbecker over 6 years ago

  • Precedes feature request #6867: explicitely assign and revoke UPDATE & DELETE permission per enitity in the registration workflow added
Actions #6

Updated by Andreas Kohlbecker over 6 years ago

  • Description updated (diff)
Actions #7

Updated by Andreas Kohlbecker over 6 years ago

  • Subject changed from Implement a RegistrationStateManager to Implement a RegistrationManager with state machine
  • Description updated (diff)
Actions #8

Updated by Andreas Kohlbecker over 6 years ago

  • Tags changed from phycobank to phycobank, permission, security
  • Description updated (diff)
Actions #9

Updated by Andreas Kohlbecker over 6 years ago

  • Description updated (diff)
Actions #10

Updated by Andreas Kohlbecker over 6 years ago

  • Description updated (diff)
Actions #11

Updated by Andreas Kohlbecker over 6 years ago

  • Description updated (diff)
Actions #12

Updated by Andreas Kohlbecker over 6 years ago

  • Description updated (diff)
Actions #13

Updated by Andreas Kohlbecker over 6 years ago

  • Related to feature request #7026: RegistrationVoter evaluates CdmAuthorities with RegistrationStatus properties added
Actions #14

Updated by Andreas Kohlbecker over 5 years ago

  • Priority changed from Priority14 to Highest
  • Target version changed from Unassigned CDM tickets to Release 5.2
Actions #15

Updated by Andreas Kohlbecker over 5 years ago

  • Description updated (diff)
  • Status changed from New to Rejected
  • Target version deleted (Release 5.2)
Actions #16

Updated by Andreas Kohlbecker over 5 years ago

  • Related to bug #7520: Restore GrantedAuthorities removed by GrantedAuthorityRevokingRegistrationUpdateLister when the regsitration state returns to PREPARATION added
Actions #17

Updated by Andreas Kohlbecker over 5 years ago

  • Blocked by task #6168: Full registration workflow model added
Actions #18

Updated by Andreas Kohlbecker over 5 years ago

  • Description updated (diff)
Actions #19

Updated by Andreas Kohlbecker over 5 years ago

  • Description updated (diff)
Actions #20

Updated by Andreas Kohlbecker over 5 years ago

  • Related to bug #7528: Allow changing the Registration status in the RegistrationWorkingsetEditor added
Actions #21

Updated by Andreas Kohlbecker about 5 years ago

  • Related to bug #7995: Registration.registrationDate not set when status is set PUBLISHED added
Actions

Also available in: Atom PDF