EDIT: Issueshttps://dev.e-taxonomy.eu/redmine/https://dev.e-taxonomy.eu/redmine/redmine/favicon.ico?14691914852018-10-23T15:49:19ZEDIT Project Management
Redmine bug #7855 (Closed): PersonField modifies the nomenclaturalTitle forcing users to have the UPDATE ...https://dev.e-taxonomy.eu/redmine/issues/78552018-10-23T15:49:19ZAndreas Kohlbecker
<p>User with role submitter creates a new specimen typedesignation and adds an existing collector for which the submitter is not having the UPDATE permission.<br>
Saving the new specimen typedesignation is blocked by the system due to:</p>
<p><img src="https://dev.e-taxonomy.eu/redmine/attachments/download/1414/picture734-1.png" alt="" /> </p>
bug #7845 (Closed): NamePopupEditor new Genus button should clear the genus name field in the new...https://dev.e-taxonomy.eu/redmine/issues/78452018-10-23T11:42:41ZAndreas Kohlbecker
<p>Clicking on the new button at the genus field in a NamePopupEditor opens a new NamePopupEditor with the genus name prefilled with the genus name of the previous editor. The Genus field should be empty if the genus name in the previous editor is not in the options list of the combobox</p>
bug #7842 (Closed): TaxonNamePopEditor: adding new name as replaced synonym to name with basionym...https://dev.e-taxonomy.eu/redmine/issues/78422018-10-23T09:26:16ZAndreas Kohlbecker
<p>This case is not expected to occur often in real live situations:</p>
<p>A name has a basionym with authorship <em>A</em>. Adding <strong>replaced synonym for which a new name is created</strong> whereas the replaced synonym shares the same authorteam <em>A</em> with the basionym leads to a NonUniqueObjectException when saving.</p>
<p>Adding an existing name with the the same authorteam <em>A</em> is not causing the exception</p>
<pre>Caused by: org.hibernate.NonUniqueObjectException: A different object with the same identifier value was already associated with the session : [eu.etaxonomy.cdm.model.agent.Team#277]
at org.hibernate.engine.internal.StatefulPersistenceContext.checkUniqueness(StatefulPersistenceContext.java:648)
at org.hibernate.event.internal.DefaultSaveOrUpdateEventListener.performUpdate(DefaultSaveOrUpdateEventListener.java:284)
at org.hibernate.event.internal.DefaultSaveOrUpdateEventListener.entityIsDetached(DefaultSaveOrUpdateEventListener.java:227)
at org.hibernate.event.internal.DefaultSaveOrUpdateEventListener.performSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:92)
at org.hibernate.event.internal.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:73)
at org.hibernate.internal.SessionImpl.fireSaveOrUpdate(SessionImpl.java:648)
at org.hibernate.internal.SessionImpl.saveOrUpdate(SessionImpl.java:640)
at org.hibernate.engine.spi.CascadingActions$5.cascade(CascadingActions.java:218)
at org.hibernate.engine.internal.Cascade.cascadeToOne(Cascade.java:398)
at org.hibernate.engine.internal.Cascade.cascadeAssociation(Cascade.java:323)
at org.hibernate.engine.internal.Cascade.cascadeProperty(Cascade.java:162)
at org.hibernate.engine.internal.Cascade.cascade(Cascade.java:111)
at org.hibernate.engine.internal.Cascade.cascade(Cascade.java:61)
at org.hibernate.event.internal.DefaultSaveOrUpdateEventListener.cascadeOnUpdate(DefaultSaveOrUpdateEventListener.java:358)
at org.hibernate.event.internal.DefaultSaveOrUpdateEventListener.performUpdate(DefaultSaveOrUpdateEventListener.java:332)
at org.hibernate.event.internal.DefaultSaveOrUpdateEventListener.entityIsDetached(DefaultSaveOrUpdateEventListener.java:227)
at org.hibernate.event.internal.DefaultSaveOrUpdateEventListener.performSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:92)
at org.hibernate.event.internal.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:73)
at org.hibernate.internal.SessionImpl.fireSaveOrUpdate(SessionImpl.java:648)
at org.hibernate.internal.SessionImpl.saveOrUpdate(SessionImpl.java:640)
at org.hibernate.engine.spi.CascadingActions$5.cascade(CascadingActions.java:218)
at org.hibernate.engine.internal.Cascade.cascadeToOne(Cascade.java:398)
at org.hibernate.engine.internal.Cascade.cascadeAssociation(Cascade.java:323)
at org.hibernate.engine.internal.Cascade.cascadeProperty(Cascade.java:162)
</pre>
<p><img src="https://dev.e-taxonomy.eu/redmine/attachments/download/1412/picture729-1.png" alt="" /></p>
bug #7835 (Closed): taxonGraph search block implementedhttps://dev.e-taxonomy.eu/redmine/issues/78352018-10-17T15:03:28ZAndreas Kohlbeckerbug #7831 (Closed): VALIDATE_AGAINST_HIGHER_NAME_PART specific epithet name is not exluded when c...https://dev.e-taxonomy.eu/redmine/issues/78312018-10-17T11:02:04ZAndreas Kohlbecker
<p>Example: </p>
<p>Species <em>Navicula bahusiensis</em> being edited in TaxonNamePopupeditor with mode <code>VALIDATE_AGAINST_HIGHER_NAME_PART</code> (was originally implemented in <a class="issue tracker-6 status-5 priority-10 priority-lowest closed" title="task: Validate taxon name against the higher taxon name (Closed)" href="https://dev.e-taxonomy.eu/redmine/issues/7338">#7338</a>)</p>
<p>Chaning the rank to subspecies will correctly change the specific epithet field to a combobox. But the epithet <em>bahusiensis</em> is selectable even if the name will no longer exist as species once the editor is saved.</p>
<p>The same problem might also exist for genera</p>
<p>Soulution:</p>
<ul>
<li>exclude the name being edited from the results in the comboboxes.</li>
</ul>
bug #7830 (Closed): VALIDATE_AGAINST_HIGHER_NAME_PART specific epithet is not being reset to test...https://dev.e-taxonomy.eu/redmine/issues/78302018-10-17T10:55:36ZAndreas Kohlbecker
<p>For ranks below species when mode <code>VALIDATE_AGAINST_HIGHER_NAME_PART</code> is enabled the "specific epithet" field restricted to existing species epithet names in the according genus. Changing the rank to Species does not reset the "specific epithet" to a plain test field.</p>
<p>the VALIDATE_AGAINST_HIGHER_NAME_PART was originally implemented in <a class="issue tracker-6 status-5 priority-10 priority-lowest closed" title="task: Validate taxon name against the higher taxon name (Closed)" href="https://dev.e-taxonomy.eu/redmine/issues/7338">#7338</a></p>
bug #7824 (Closed): PopupViewRegistration not removing registered views causes memleakhttps://dev.e-taxonomy.eu/redmine/issues/78242018-10-14T17:16:32ZAndreas Kohlbecker
<p>The PopupViewRegistration registers <code>ApplicationView</code>s and PopupViews. Alt least the <code>ApplicationView</code> are not removed from the internal maps. This causes a memleak</p>
bug #7814 (Closed): Section in Name and section in Basionym, usabilityhttps://dev.e-taxonomy.eu/redmine/issues/78142018-10-09T11:22:02ZWolf-Henning Kusber
<p>Bedienungsfehler möglich, wenn neuer Name und Basionym jeweils eine In-Zitierung haben.</p>
<p>Vorgehen: Referenz eingeben, neuen Namen eingeben, aus der nomenklatorischen Referenz heraus Sektion anlegen (richtig).</p>
<p>Basionym<br>
Vorgehen: Neuen Namen eingeben, neue Referenz als Artikel eingeben, abspeichern, Record wieder aufmachen, Section anlegen wollen: Falsch, damit kann nur die korrekte bibliographische Referenz abgehängt werden (Screen shot)</p>
<p><img src="https://dev.e-taxonomy.eu/redmine/attachments/download/1403/picture811-1.png" alt="" /></p>
<p>Korrektes Vorgehen:<br>
Neuen Namen eingeben, neue Referenz mit Section-Autoren als Section eingeben und von da aus die neue Referenz eingeben.</p>
<p><img src="https://dev.e-taxonomy.eu/redmine/attachments/download/1404/picture811-2.png" alt="" /></p>
<p>Das ist genau andersrum als von neuen Namen her gewohnt und kann zu Fehlern führen.</p>
feature request #7788 (Closed): Registration page shows registration date and officehttps://dev.e-taxonomy.eu/redmine/issues/77882018-09-24T09:45:06ZAndreas Kohlbecker
<p>Registration page needs to show the registration date and office</p>
task #7785 (Closed): CdmUserHelper caches permission informationhttps://dev.e-taxonomy.eu/redmine/issues/77852018-09-21T14:25:25ZAndreas Kohlbecker
<p>CdmUserHelper has been identified being hostspot in the cpu time analysis:</p>
<p><img src="https://dev.e-taxonomy.eu/redmine/attachments/download/1388/picture159-1.png" alt="" /> </p>
<p>Caching entities or permsisson check results may help improving the performance.</p>
<p>In the analyzed case it takes 12 seconds in total to build the RegistrationWorkingsetView. 8,3 seconds of that are only used to find entities which are needed to do permission checks. Finding these entities involves querying the database which naturally takes some time. But these roundtrips to the DB are completely dispensable since the entities needed for the checks have been loaded already. They are stored in the <code>CdmTransientEntityCache</code> which is used by the <code>CachingPresenters</code>. Therefore this performance overhead culd be completely cropped off by using the cached enities.</p>
<p>When the permission check is being done, the entityType and UUID are known, but with this information it is not possible to query the <code>CdmTransientEntityCache</code> for a cached object. The cache uses the entity.ID instead of the uuid. In <a class="issue tracker-4 status-4 priority-10 priority-lowest" title="bug: CdmTransientEntityCacher cannot handle multiple unpersisted entities of the same type (Feedback)" href="https://dev.e-taxonomy.eu/redmine/issues/7709">#7709</a> the idea of using the <code>uuid</code> instead of the <code>id</code> is being discussed.</p>
<hr>
<p>We (AK & AM) decided for the following solution:</p>
<p>A subclass of the <code>CdmTransientEntityCache</code> will complements the <code>CdmTransientEntityCache</code> by the ability to get CDM entities from the cache by the UUID. Internally a Map will be used to store the entity UUID together with the CdmEntityCacheKey of each entity being put into the cache.</p>
bug #7783 (Closed): NamePopupEditor new buttons for genus and specieshttps://dev.e-taxonomy.eu/redmine/issues/77832018-09-21T11:25:32ZAndreas Kohlbecker
<p>For species the genus can only be selected from existing genera. In order to use a not existing genus it is currently required to start a new registration from scratch. Having a new button at the combobox would be much more convenient and is easier for inexperienced users. The same accounts for the species combobox.</p>
<p>A registration for the new name needs to be create also automatically. This registration should be a blocking registration to the registration being edited currently. </p>
bug #7778 (Closed): identifier links missing in taxon relations footnoteshttps://dev.e-taxonomy.eu/redmine/issues/77782018-09-20T10:12:27ZAndreas Kohlbecker
<p>identifier links missing when a footnote is created for taxon relations</p>
<p>see e.g.: <a href="http://caryophyllales.org/nepenthaceae/cdm_dataportal/taxon/90d47d8d-0f76-47d9-a0c8-20b4361080a4">http://caryophyllales.org/nepenthaceae/cdm_dataportal/taxon/90d47d8d-0f76-47d9-a0c8-20b4361080a4</a></p>
bug #7777 (Closed): NPE on login attempt after logouthttps://dev.e-taxonomy.eu/redmine/issues/77772018-09-20T09:14:15ZAndreas Kohlbecker
<p>login attempt after logging out</p>
<pre>Caused by: java.lang.NullPointerException
at eu.etaxonomy.cdm.vaadin.view.LoginPresenter.onEvent(LoginPresenter.java:133)
at org.vaadin.spring.events.internal.EventBusListenerWrapper.publish(EventBusListenerWrapper.java:55)
at org.vaadin.spring.events.internal.ListenerCollection.publish(ListenerCollection.java:167)
at org.vaadin.spring.events.internal.ScopedEventBus.publish(ScopedEventBus.java:116)
at org.vaadin.spring.events.internal.ScopedEventBus.publish(ScopedEventBus.java:131)
at org.vaadin.spring.events.internal.ScopedEventBus.publish(ScopedEventBus.java:133)
at org.vaadin.spring.events.internal.ScopedEventBus.publish(ScopedEventBus.java:121)
at eu.etaxonomy.cdm.vaadin.view.LoginViewBean.handleLoginClick(LoginViewBean.java:69)
at eu.etaxonomy.cdm.vaadin.view.LoginViewBean.lambda$initContent$61446b05$1(LoginViewBean.java:56)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.vaadin.event.ListenerMethod.receiveEvent(ListenerMethod.java:510)
... 76 more
</pre> bug #7723 (Closed): PhycoBank unpublished data must not be visible in Portalhttps://dev.e-taxonomy.eu/redmine/issues/77232018-09-04T16:03:27ZWolf-Henning Kusber
<p>Unpublished data visible in Portal, not in scientific name search, but as list under a reference including published names.</p>
<p>Also: The reference page currently shows rejected and other unpublished Registrations, this must not happen!</p>
<p>Example: <a href="http://test.e-taxonomy.eu/cdmserver/phycobank_production/app/registration#!workingset/305e2983-f7c2-4d62-9418-1706edb895c2">http://test.e-taxonomy.eu/cdmserver/phycobank_production/app/registration#!workingset/305e2983-f7c2-4d62-9418-1706edb895c2</a></p>
<p>Unpublished Scientific name: "lacusbaicalensis", (genus name not filled, editorial notice)</p>
<p>Problem: Reference with published names already in PhycoBank pulished.<br>
Name search for string "lacusbaicalensis" not possible (=correct, <a href="http://phycobank.org/100301">http://phycobank.org/100301</a>)</p>
<p>Name search for "Staurosirella sigara" ist possible (=correct, <a href="http://phycobank.org/100296">http://phycobank.org/100296</a>), Reference for both names is: Kulikovskiy, M. & Lange-Bertalot, H. - in Kulikovskiy, M., Lange-Bertalot, H. & Kuznetsova, I. V., Lake Baikal: Hotspot of endemic diatoms II.Iconographia Diatomologica, 26: [1]-656. 2015</p>
<p><a href="http://test.e-taxonomy.eu/dataportal/preview/phycobank/cdm_dataportal/reference/305e2983-f7c2-4d62-9418-1706edb895c2">http://test.e-taxonomy.eu/dataportal/preview/phycobank/cdm_dataportal/reference/305e2983-f7c2-4d62-9418-1706edb895c2</a></p>
<p>Under this reference all names (published AND unpublished) are listed (unpublished see arrows in screen shot).</p>
<p>How big is the problem? At the moment only References which are published and in the process of post publication registration are affected.<br>
<img src="https://dev.e-taxonomy.eu/redmine/attachments/download/1358/picture319-1.png" alt="" /></p>
feature request #7648 (Resolved): Create taxonrelation to genus or species when subordinate names...https://dev.e-taxonomy.eu/redmine/issues/76482018-08-13T13:20:57ZAndreas Kohlbecker
<p>When creating a species a new Taxon needs to be created for this species and the new taxon needs to be related to the genus via INCLUDED_IN.</p>
<p><strong>Q1:</strong> </p>
<p>According to <a class="issue tracker-6 status-5 priority-11 priority-default closed" title="task: Concept for a useful algae registry taxon classification (Closed)" href="https://dev.e-taxonomy.eu/redmine/issues/6173">#6173</a> <strong>6) [N1T] 2.</strong> <em>there should always only be one taxon per name for the higher classification.</em> </p>
<p>Does this also account for genera? In the same ticket we wrote:</p>
<p><em>The search process primarily aims in finding genera, all species and subspecies which fall under each genus found are to be displayed independently of the higher classification information associated with the individual names. Practically this will be solved by creating for each TaxonName an includenIn relation to the Taxon for the name used in the uninomialOrGenus and in the specificEpithet field.</em><br>
<em>Ranks like e.g. variety and subgenus can not be associated automatically, so their relation to the genus or species respectively must be created manually if this information is available or if it is required in a specific case. It also should be considered to associate e.g. species to the according subgenera.</em></p>
<hr>
<p>The relation needs to be updated or deleted when</p>
<ul>
<li>a higher ranked name part is changed</li>
</ul>