Project

General

Profile

feature request #6655

Implement a RegistrationManager with state machine

Added by Andreas Kohlbecker over 2 years ago. Updated over 1 year ago.

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

0%

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 Registrations Closed 05/19/2017
Related to Edit - feature request #7026: RegistrationVoter evaluates CdmAuthorities with RegistrationStatus properties Closed 10/19/2017
Related to Edit - bug #7520: Restore GrantedAuthorities removed by GrantedAuthorityRevokingRegistrationUpdateLister when the regsitration state returns to PREPARATION New 06/27/2018
Related to Edit - bug #7528: Allow changing the Registration status in the RegistrationWorkingsetEditor Closed 08/03/2018
Related to Edit - bug #7995: Registration.registrationDate not set when status is set PUBLISHED Closed 01/15/2019
Blocked by PhycoBank - task #6168: Full registration workflow model Closed 07/25/2016 09/23/2016
Precedes Edit - feature request #6867: explicitely assign and revoke UPDATE & DELETE permission per enitity in the registration workflow Closed 12/21/2017

Associated revisions

Revision 5ce3b66a (diff)
Added by Andreas Kohlbecker over 1 year ago

ref #7528 ref #6655 introducing RegistrationStatusTransitions to provide a matrix of allowed RegistrationStatus transitions

History

#1 Updated by Andreas Kohlbecker over 2 years ago

  • Description updated (diff)

#2 Updated by Andreas Kohlbecker over 2 years ago

  • Description updated (diff)

#3 Updated by Andreas Kohlbecker over 2 years ago

#4 Updated by Andreas Kohlbecker over 2 years ago

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

#5 Updated by Andreas Kohlbecker about 2 years ago

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

#6 Updated by Andreas Kohlbecker about 2 years ago

  • Description updated (diff)

#7 Updated by Andreas Kohlbecker about 2 years ago

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

#8 Updated by Andreas Kohlbecker almost 2 years ago

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

#9 Updated by Andreas Kohlbecker almost 2 years ago

  • Description updated (diff)

#10 Updated by Andreas Kohlbecker almost 2 years ago

  • Description updated (diff)

#11 Updated by Andreas Kohlbecker almost 2 years ago

  • Description updated (diff)

#12 Updated by Andreas Kohlbecker almost 2 years ago

  • Description updated (diff)

#13 Updated by Andreas Kohlbecker almost 2 years ago

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

#14 Updated by Andreas Kohlbecker over 1 year ago

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

#15 Updated by Andreas Kohlbecker over 1 year ago

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

#16 Updated by Andreas Kohlbecker over 1 year ago

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

#17 Updated by Andreas Kohlbecker over 1 year ago

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

#18 Updated by Andreas Kohlbecker over 1 year ago

  • Description updated (diff)

#19 Updated by Andreas Kohlbecker over 1 year ago

  • Description updated (diff)

#20 Updated by Andreas Kohlbecker over 1 year ago

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

#21 Updated by Andreas Kohlbecker 9 months ago

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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 40 MB)