Project

General

Profile

task #6258

AlgenRegistrierung - task #6044: cdm model changes/entensions for algea registry

Add Registration to cdm model

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

Status:
Closed
Priority:
Highest
Category:
cdm
Target version:
Start date:
03/15/2017
Due date:
% Done:

100%

Severity:
critical
Tags:

Description

For the Algea-Registry the model needs to be extended by a Registration class (for the detailed discussion see #6044)

The class Registration:


class Registration {

private String(255) identifier;

private String(255) specificIdentifier;   //id without http-domain

private org.joda.time.DateTime registrationDate;

private Enum status;

private Institution institution;

private TaxonNameBase name;

private Set<TypeDesignationBase> typeDesignations;

private Set<Registration> blockedBy;

private User submitter;

}

The class will have n-1 relation to TaxonNameBase and an n-m associations to TypeDesignationBase:

TaxonNameBase [1]--------
                         \
                          ----[m] Registration
                         /
TypeDesignationBase [n]--

RegistrationStatus
see cdm-vaadin:src/main/java/eu/etaxonomy/cdm/mock/RegistrationStatus.java

public enum RegistrationStatus {

    preparation,// A new record which is being edited by the Author
    curation, //A record ready for the curator to be validated.
    ready, //The record has passed the validation by the curator and is ready for publication.
    published, //The name or typification has finally been published.
    rejected //The registration has been rejected, the process is aborted and the record is preserved.
}

Related issues

Related to AlgenRegistrierung - task #6168: Full registration workflow model In Progress 07/25/2016 09/23/2016
Related to AlgenRegistrierung - task #6513: RegistrationWorkingSet to be modeled explicitely? Rejected 03/15/2017
Related to Edit - bug #6842: NPE in Registration constructor when name is null Closed 07/21/2017
Precedes (7 days) Edit - task #6612: Implement dao and service class for Registrations Closed 03/23/2017 03/23/2017

Associated revisions

Revision 09c24be2 (diff)
Added by Andreas Müller over 1 year ago

ref #6258 first imcomplete version of Registration class

Revision 2ac4df70 (diff)
Added by Andreas Müller over 1 year ago

ref #6258 add Registration to hibernate mapping and make in Annotatable and add update script

Revision d4aa7f24 (diff)
Added by Andreas Müller over 1 year ago

ref #6258 add Audited to Registration

Revision b10eca3b (diff)
Added by Andreas Müller over 1 year ago

ref #6258 , ref #6529 adapt test dll for Registration and WorkingSet

Revision b66167fa (diff)
Added by Andreas Müller over 1 year ago

ref #6529, ref #6258 improve MN TableCreator and missing ForeignKey handling (add index instead)

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

ref #6258 satisfying @NonNull annotations for collection properties

Revision 4c8dfa57 (diff)
Added by Andreas Müller over 1 year ago

ref #6258 add RegistrationStatus to EnumUserType

Revision a82850a1 (diff)
Added by Andreas Müller over 1 year ago

ref #6258 Added basic bidirectionality for Registration.name and typeDesignation

Revision e43aa1df (diff)
Added by Andreas Müller over 1 year ago

ref #6258 fix update script and tests for bidirectional type-registration

Revision 126e4675 (diff)
Added by Andreas Müller over 1 year ago

ref #6258, #6535, #3734 some updates to CdmUpdater after checking against H2

Revision c98bc251 (diff)
Added by Andreas Müller about 1 year ago

ref #6258 add cascading for registration in TaxonName and TypeDesignationBase

Revision 6fac03ea (diff)
Added by Andreas Müller 7 months ago

ref #6258 add Registration.blockedBy Adder and Remover

History

#1 Updated by Andreas Kohlbecker about 2 years ago

  • Project changed from AlgenRegistrierung to Edit
  • Category set to cdm
  • Target version set to Release 4.5
  • Severity set to critical

For the Algea-Registry the model needs to be extended by a Registration class (for the detailed discussion see #6044)

The class Registration:


class Registration {

private String(255) identifier;

private String(255) specificIdentifier;   //id without http-domain

private org.joda.time.DateTime registrationDate;

private Enum status;

private Institution institution;

private TaxonNameBase name;

private Set<TypeDesignationBase> typeDesignations;

}

The class will have n-1 relation to TaxonNameBase and an n-m associations to TypeDesignationBase:

TaxonNameBase [1]--------
                         \
                          ----[m] Registration
                         /
TypeDesignationBase [n]--

#2 Updated by Andreas Kohlbecker about 2 years ago

  • Assignee set to Andreas Müller

#3 Updated by Andreas Müller about 2 years ago

  • Target version changed from Release 4.5 to CDM UML 4.7

#4 Updated by Andreas Müller about 2 years ago

  • Related to task #6168: Full registration workflow model added

#5 Updated by Andreas Müller about 2 years ago

We also need a new Enum RegistrationStatus, with instances defined in #6168

#6 Updated by Andreas Müller about 2 years ago

  • Status changed from New to In Progress
  • Priority changed from New to Highest

#7 Updated by Andreas Kohlbecker almost 2 years ago

  • Description updated (diff)

A registration in progress can be dependant on another registration which needs to be completed before it is possible to advance.
Therefore the Registration class should be extended to be able to reflect this dependency. I suggest adding a Collection field:

private Set<Registration> dependsOn;

#8 Updated by Andreas Kohlbecker almost 2 years ago

We need to be able to associate Registrations with Users and CRUD of Registrations need to be controlled via GrantedAuthorities. Therefore the Registration needs to be sub class of CdmBase.

#9 Updated by Andreas Müller almost 2 years ago

  • Description updated (diff)

Andreas Kohlbecker wrote:

A registration in progress can be dependant on another registration which needs to be completed before it is possible to advance.
Therefore the Registration class should be extended to be able to reflect this dependency. I suggest adding a Collection field:

private Set<Registration> dependsOn;

We decided to call it blockedBy, not dependsOn

#10 Updated by Andreas Kohlbecker almost 2 years ago

Andreas Kohlbecker wrote:

We need to be able to associate Registrations with Users and CRUD of Registrations need to be controlled via GrantedAuthorities. Therefore the Registration needs to be sub class of CdmBase.

In a follow up discussion on the above considerations we concluded that the Registration should have an association to User, so that the person being responsible for the registration is clearly related to the registration. Naming suggestions for this property:

  • editor
  • author
  • originator
  • initiator

#11 Updated by Andreas Kohlbecker almost 2 years ago

  • Description updated (diff)

#12 Updated by Andreas Müller almost 2 years ago

Andreas Kohlbecker wrote:

Andreas Kohlbecker wrote:

We need to be able to associate Registrations with Users and CRUD of Registrations need to be controlled via GrantedAuthorities. Therefore the Registration needs to be sub class of CdmBase.

In a follow up discussion on the above considerations we concluded that the Registration should have an association to User, so that the person being responsible for the registration is clearly related to the registration. Naming suggestions for this property:

  • editor
  • author
  • originator
  • initiator

Can you please define semantics of the new attribute a bit more. Is the person the one who "applied" for the new name or is it the person who works on the registration process (in this case usually WHK). The translations I found for originator http://dict.leo.org/englisch-deutsch/originator do not make this clear (it is both "Antragsteller" and "Bearbeiter"). Therefore this term might not be the best.

#13 Updated by Andreas Kohlbecker almost 2 years ago

Andreas Müller wrote:

Can you please define semantics of the new attribute a bit more. Is the person the one who "applied" for the new name or is it the person who works on the registration process (in this case usually WHK). The translations I found for originator http://dict.leo.org/englisch-deutsch/originator do not make this clear (it is both "Antragsteller" and "Bearbeiter"). Therefore this term might not be the best.

This is the person who initiated the registration process. This is either the author (or one of a team) of the according publication or someone who is doing a post publication registration on behalf of the actual author. I would not use the verb "apply" in this context. I think talking of submissions is more appropriate, since this is also what is happening at the publishers side. The author submits the publication of a new name and it submits in the same sense the data for registration. WHK is only the person doing the data curation. Data curation is a manual validation of the data entered of the submitter . A data curator is not working on the registration process.

Maybe submitter is better than originator.

#14 Updated by Andreas Müller almost 2 years ago

  • Description updated (diff)

Andreas Kohlbecker wrote:

Andreas Müller wrote:

Maybe submitter is better than originator.

Yes I agree, if WHK also agrees we can fix this. Already changed the label in the above description.

#15 Updated by Andreas Kohlbecker almost 2 years ago

[Henning wrote]

Hallo Andreas,

ich habe grundsätzlich immer Schwierigkeiten mit solchen Substantiven.

Erst nach Leo-Befragung, kann ich mich dem „originator“ halbwegs anschließen, nach LEO passt das sogar besser. In bezug auf diese ganzen Substantive des Englischen habe ich überhaupt kein Spachgefühl. [Provider würde hier wegen des Gebrauchs in der GBIF-Welt nicht passen]

Echte Frage: Warum denn nicht einfach „ProvidedBy“ oder „SubmittedBy“ ? [originated by würde schon wieder schlechter passen]

Viele Grüße,
Henning

#16 Updated by Andreas Kohlbecker almost 2 years ago

Also submittedBy?

Alle einverstanden?

#17 Updated by Wolf-Henning Kusber almost 2 years ago

ist mein Favorit, Henning

#18 Updated by Andreas Müller almost 2 years ago

it is a bit against our CDM conventions. At other places we say collector and not collected by, or combinationAuthor not xxxBy, etc. The only by that we use is createdBy and updatedBy for the first and the last user who worked on a record.

But if you prefer submittedBy I can live with it.

#19 Updated by Andreas Müller almost 2 years ago

Can you please add the Enum states required for the status?

Is it ok to call the enum class RegistrationStatus?

#20 Updated by Andreas Müller almost 2 years ago

Should submitted(By) really be of type "User", not of type Person, Team or Agent? Is it always necessary that a submitter has access rights? Currently a User can only be Person, so this prevents teams or institutions to become submitters.

#21 Updated by Andreas Müller almost 2 years ago

Can you please add information about bidirectionality.

So, should a name link to it's registrations (probably yes)
Should a submitter link to it's registrations (probably no),
...

For all bidirectional relationships please add the name and type of the attribute at the other side (e.g

Set<Registration> registrations 

in TaxonNameBase

#22 Updated by Andreas Müller almost 2 years ago

Andreas Müller wrote:

Can you please add the Enum states required for the status?

Is it ok to call the enum class RegistrationStatus?

What should be the default state? Or is NULL allowed and the default?

#23 Updated by Andreas Kohlbecker almost 2 years ago

A Registration without a state makes not much sense. A new Registration should have the state preparation`.
The states are listed in #6168

#24 Updated by Andreas Kohlbecker almost 2 years ago

Andreas Kohlbecker wrote:

A Registration without a state makes not much sense. A new Registration should have the state preparation.
preparation will therefore the default State.
The states are listed in #6168

#25 Updated by Andreas Kohlbecker almost 2 years ago

  • Description updated (diff)

Andreas Müller wrote:

Can you please add the Enum states required for the status?

Is it ok to call the enum class RegistrationStatus?

The enum states are now added to the issue description. The enum already exists in the source code, see cdm-vaadin:src/main/java/eu/etaxonomy/cdm/mock/RegistrationStatus.java

#26 Updated by Andreas Kohlbecker almost 2 years ago

Andreas Müller wrote:

it is a bit against our CDM conventions. At other places we say collector and not collected by, or combinationAuthor not xxxBy, etc. The only by that we use is createdBy and updatedBy for the first and the last user who worked on a record.

But if you prefer submittedBy I can live with it.
The votes for this decision are:

  • AM: +1 for submitter
  • AK: +1 for submitter
  • WHK: +1 for submittedBy

So it is 2:1 for submitter. Consistency in the model naming convention is important, for the UI we always can change the 'submitter' into 'submittedBy'. Therefore let's name it submitter

#27 Updated by Andreas Kohlbecker almost 2 years ago

Andreas Müller wrote:

Can you please add information about bidirectionality.

So, should a name link to it's registrations (probably yes)
Should a submitter link to it's registrations (probably no),
...

For all bidirectional relationships please add the name and type of the attribute at the other side (e.g

Set<Registration> registrations 

in TaxonNameBase

  • name: should link to its Registration
  • submitter: I think that we don't need a back reference here
  • typeDesignation: since the name links to its Registration the typeDesignation also should

Does everybody agree?

#28 Updated by Andreas Kohlbecker almost 2 years ago

Andreas Müller wrote:

Should submitted(By) really be of type "User", not of type Person, Team or Agent? Is it always necessary that a submitter has access rights? Currently a User can only be Person, so this prevents teams or institutions to become submitters.

Ich denke, dass Agent die besser Wahl wäre. Damit wären wir am flexibelsten. Andererseits würde dadurch aber auch das "Einsammeln" der Registrierungen für einen Nutzer aufwändiger da zwei Fälle berücksichtigt werden müssen:

User->Person->Registration
User->Person->Team->Registration

Andreas

#29 Updated by Andreas Müller almost 2 years ago

  • Related to task #6513: RegistrationWorkingSet to be modeled explicitely? added

#30 Updated by Andreas Kohlbecker almost 2 years ago

Ja, das wäre ein bisschen aufwendiger. Aber sicherlich lösbar. Ein bisschen schwieriger ist der Fall bei Institutionen. Da ist der Zusammenhang zum User ja noch unschärfer.
Aber auch das wäre lösbar denke ich.

Grundsätzlich stellt sich aber vor allem die Frage, welches die Hauptgründe sind, warum wir überhaupt einen Submitter brauchen.
Geht es v.a. darum anzuzeigen, wenn ich eingeloggt bin, wie es meinen Registrierungen geht oder geht es darum, der Außenwelt etwas über den Submitter der Registrierung was zu erzählen. Wenn nur ersteres, wäre „User“ richtig, wenn auch Zweiteres wichtig, dann halte ich Agent für sinniger.

AM

#31 Updated by Andreas Kohlbecker almost 2 years ago

Rein inhaltlich:

  1. Ist es wichtig zu unterscheiden, zwischen Registrierungen von neuen Namen und alten Basionymen, die mitregistriert werden.
  2. Ist es ein Qualitätskriterium, wenn Autoren der Namen auch Submitter des Eintrags sind.
  3. Später ist dann auch wichtig, ob es sich um einen menschlichen Eintrag oder eine „Maschinenregistrierung“ handelt

#32 Updated by Andreas Kohlbecker almost 2 years ago

Aus technischer und organisatorischer Sicht ist der Submitter vor allem wichtig um die Registrierungen die zu einem User gehören herausfiltern zu können.
Die Berechtigungen sind in dieser Situation irrelevant. Es geht hierbei nur um die Zuordnung. Der Submitter wird in den meisten Fällen auch immer der Creator sein, es sei denn eine Registrierung wird auf einen anderen User übertragen, weil einer der Autoren eines Teams die Durchführung der Registrierung an jemand andren abgibt.
Die Basis einer jeden Registrierung ist immer eine Publikation, also entweder die nomenklatorische Referenz des neuen Namens oder die 'citation' der TypeDesignation. Falls eine Registrierung mehrere TypeDesignations umfasst müssen alle die selbe citation und citationMicroreference haben. Über diese 'Referenzen' besteht schon eine Relation zu dem Autor/AutorenTeam. Bei post-publication Registrierungen aber wird der Submitter/User in vielen Fällen nicht dem Autorenteam angehören. Wir brauchen also auf jeden Fall eine separate Relation zu der Person, welche die Registrierung aktuell bearbeitet. Hier stellt sich die Frage ob das nicht auch mehrere Personen sein können? Sollten wir den Fall berücksichtigen, dass es ein Team also mehrere Personen geben kann, die gemeinsam die Registrierung bearbeiten? Bei Massenpublikationen von vielen Namen in ein und der selben Publikation ist es durchaus vorstellbar, dass das Team sich die Arbeit teilen möchte. In diesem Fall gäbe es mehrere User.

Es gibt in CDM-Java gesprochen also folgende Möglichkeiten:

A) Set<User> submitters;

oder

B) User submitter;

oder

C) Agent submitter;

Mit scheint (A) mittlerweile am sinnvollsten zu sein.

Andreas

#33 Updated by Andreas Kohlbecker almost 2 years ago

Nach abschließender Diskussion mit Henning ist klar geworden, dass der Fall mehrerer User eigentlich irrelevant ist. Wir können davon ausgehen dass es immer nur ein User sein wird der sich um die Registrierung aller Namen und Typen in einer Publikation kümmert. Sollte der Fall auftreten, dass ein Team gemeinsam die Registrierungen bearbeiten will muss sich das Team einen Useraccount anlegen dessen Credentials dem gesamten Team bekannt gemacht werden so dass alle zugriff haben. Übrigens wollen

Publisher auch immer mit genau einer Person, dem Corresponding Author kommunizieren.

Also: "The winner is ...."

User submitter;

Ta da da daaaaaaa!!!!

#34 Updated by Andreas Müller over 1 year ago

What class should Registration inherit from? CdmBase, VersionableEntity, AnnotatableEntity, IdentifiableEntity?

#35 Updated by Andreas Müller over 1 year ago

  • Priority changed from New to Highest

#36 Updated by Andreas Kohlbecker over 1 year ago

Andreas Müller wrote:

What class should Registration inherit from? CdmBase, VersionableEntity, AnnotatableEntity, IdentifiableEntity?

AnnotatableEntity is the right one!

#37 Updated by Andreas Kohlbecker over 1 year ago

After the discussion this week I am thinking about renaming the Registration class to NomenclaturalAct, this term would be less application purpose oriented an the more correct term from the process in the scientific process.

#38 Updated by Andreas Müller over 1 year ago

I think NomenclaturalAct is a broader term then Registration. It is also valid for existing NomenclaturalActs in published publications which are obviously not covered by the current class while many attributes of the class are not usefull for existing Nomenclatural acts (specificIdentifier, Identifier, Institution, maybe even status).

#39 Updated by Andreas Müller over 1 year ago

  • Status changed from In Progress to Resolved
  • Assignee changed from Andreas Müller to Andreas Kohlbecker

#40 Updated by Andreas Kohlbecker over 1 year ago

  • Tags set to phycobank

#41 Updated by Andreas Kohlbecker over 1 year ago

  • Precedes task #6612: Implement dao and service class for Registrations added

#42 Updated by Andreas Kohlbecker over 1 year ago

  • Status changed from Resolved to Feedback
  • Assignee changed from Andreas Kohlbecker to Andreas Müller

when accessing persisted Registration I get this error:

java.lang.IllegalArgumentException: EnumType RegistrationStatus not supported by EnumUserType.
    at eu.etaxonomy.cdm.hibernate.EnumUserType.nullSafeGet(EnumUserType.java:109)
    at eu.etaxonomy.cdm.hibernate.EnumUserType.nullSafeGet(EnumUserType.java:1)
    at org.hibernate.type.CustomType.nullSafeGet(CustomType.java:110)
    at org.hibernate.type.AbstractType.hydrate(AbstractType.java:85)
    at org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2727)
    at org.hibernate.loader.Loader.loadFromResultSet(Loader.java:1728)
    at org.hibernate.loader.Loader.instanceNotYetLoaded(Loader.java:1654)
    at org.hibernate.loader.Loader.getRow(Loader.java:1543)
    at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:727)
    at org.hibernate.loader.Loader.processResultSet(Loader.java:972)
    at org.hibernate.loader.Loader.doQuery(Loader.java:930)
    at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:336)
    at org.hibernate.loader.Loader.doList(Loader.java:2611)
    at org.hibernate.loader.Loader.doList(Loader.java:2594)
    at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2423)
    at org.hibernate.loader.Loader.list(Loader.java:2418)
    at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:109)
    at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1774)
    at org.hibernate.internal.CriteriaImpl.list(CriteriaImpl.java:363)
    at eu.etaxonomy.cdm.persistence.dao.hibernate.common.CdmEntityDaoBase.list(CdmEntityDaoBase.java:836)
    at eu.etaxonomy.cdm.persistence.dao.hibernate.common.VersionableDaoBase.list(VersionableDaoBase.java:184)
    at eu.etaxonomy.cdm.api.service.ServiceBase.list(ServiceBase.java:161)

this happens at:

TransactionStatus tx = repo.startTransaction(true);
List<Registration> allRegs = repo.getRegistrationService().list(null, null, null, null, null); 

#43 Updated by Andreas Müller over 1 year ago

Andreas Kohlbecker wrote:

when accessing persisted Registration I get this error:

should be fixed with 4c8dfa574

#44 Updated by Andreas Müller over 1 year ago

  • Status changed from Feedback to Resolved
  • Assignee changed from Andreas Müller to Andreas Kohlbecker

#45 Updated by Andreas Müller over 1 year ago

Andreas Müller wrote:

Andreas Kohlbecker wrote:

when accessing persisted Registration I get this error:

should be fixed with 4c8dfa574

But be careful, there are new model changes. Need to run update script from scratch.

#46 Updated by Andreas Müller over 1 year ago

can this be closed?

#47 Updated by Andreas Kohlbecker over 1 year ago

  • Status changed from Resolved to Closed

#48 Updated by Andreas Kohlbecker over 1 year ago

  • Related to bug #6842: NPE in Registration constructor when name is null added

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 40 MB)