Project

General

Profile

feature request #6655

Updated by Andreas Kohlbecker almost 6 years ago

## RegistrationManager 

  **UPDATE: this idea has been rejected in favour of granting per entity permissions to submitters.** (see #6867, #7520, ...?) 

 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.   

Back