EDIT: Issueshttps://dev.e-taxonomy.eu/redmine/https://dev.e-taxonomy.eu/redmine/redmine/favicon.ico?14691914852021-07-05T17:50:20ZEDIT Project Management
Redmine feature request #9696 (New): Implement taxon concept additional parameter for Taxon details viewhttps://dev.e-taxonomy.eu/redmine/issues/96962021-07-05T17:50:20ZAndreas Müller
<p>... and show them if supportTaxonConcept (<a class="issue tracker-5 status-5 priority-10 priority-lowest closed" title="feature request: Implement a preference for supportsConcepts (Closed)" href="https://dev.e-taxonomy.eu/redmine/issues/9695">#9695</a>) preference is set.</p>
<p>If easy to implement you could also implement the setting of the preference in the local preferences experimental features section. But not obligatory as it is also possible to set the preference manually in the database (hmm, do we need it already as a DB preference?).</p>
feature request #9695 (Closed): Implement a preference for supportsConceptshttps://dev.e-taxonomy.eu/redmine/issues/96952021-07-05T17:43:06ZAndreas Müller
<p>this might be a preliminary preference which makes it possible to do some development on develop branch without beaking production databases. We may change to more detailed perference later when going into production.</p>
feature request #9692 (Closed): Add Operation class and link from TaxonRelationshiphttps://dev.e-taxonomy.eu/redmine/issues/96922021-07-02T10:59:53ZAndreas Müller
<p>The class for now can be versionable (maybe later annotatable).</p>
<p>Also we need an Enum for operation types (starting with merge and split).</p>
feature request #9619 (Closed): Model changes for taxon concept strategyhttps://dev.e-taxonomy.eu/redmine/issues/96192021-05-10T15:06:16ZAndreas Müller
<p>In the taxonId meeting 2021-03-21 we agreed on the following changes</p>
<p>Class: Taxon<br>
Attribute: conceptId<br>
Type: String<br>
Reason: s. email discussion, there are usecases where nameUsageIds have to stay stable when conceptsIds change and the other way round therefore a separate identifier is needed though we use the same class for handling concepts and nameUsages (instances of class Taxon with all available data attached)</p>
<p>Class: Taxon<br>
Attribute: isConcept<br>
Type: boolean<br>
Reason: workflow control available explicitly for concepts; maybe the existence of the conceptId is enough</p>
<p>Class: Taxon<br>
Attribute: isNameUsage<br>
Type: boolean<br>
Reason: workflow control available explicitly for name usages; the existance of the taxon.id (= nameUsage.id) is not enough as Taxon records used only as condepts will always hava a Taxon.id due to technical reasons</p>
<p>Class: Taxon<br>
Attribute: conceptDefinition<br>
Type: EnumSet<br>
Description: an enumset defining all data that define the concept (e.g. homotypic groups, descrptive data, secundum, ...); this may also include the rules when the concept is changing (e.g. automatically when a homotypic group is added, when HG is added but only after user feedbac, automatically if HG is moved from another concept to this concept or the other way round, ...). In future rules maybe become a separate attribute depending on the degree of detailedness needed</p>
<p>Class: Taxon<br>
Attribute: isPersistent<br>
Type: boolean<br>
Reason: defines if a concept will/should be available for long time; necessary e.g. for temporary concepts (e.g. Kew concepts in E+M usecase)</p>
<p>Class: Taxon<br>
Attribute: supportsProvenance<br>
Type: boolean<br>
Reason: defines if a concept supports provenance (guaranteed links to successor concepts when ever the concept is not the current concept anymore)</p>
<p>Class: Taxon<br>
Attribute: isCurrentConcept<br>
Type: boolean<br>
Reason: defines if the concept is the current concept in it's classification (maybe also computable by list of successors isEmpty or by position in classification)</p>
<p>Class: Taxon<br>
Attribute: currentConceptPeriod<br>
Type: TimePeriod<br>
Reason: time period when this concept was current (only start value if concept is still current)</p>