feature request #6655
Updated by Andreas Kohlbecker over 6 years ago
# Reasons why a RegistrationManager is needed
## 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. Genreal 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 might open up options for arbitrary state changes
* Once a Registration has left the state `PREPARATION` the per entity permission must be revoked. Once the curator decides to give the Registration back to the submitter the state will change again to PREPARATION` and the submitter will again be able to add typeDesignations.
## State changes
We need a `RegistrationManager` which can change the RegistrationState on behalf of the user, since 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`.