EDIT: Issueshttps://dev.e-taxonomy.eu/redmine/https://dev.e-taxonomy.eu/redmine/redmine/favicon.ico?14691914852017-11-23T11:10:06ZEDIT Project Management
Redmine bug #7088 (Closed): Media can not be saved in TaxEditorhttps://dev.e-taxonomy.eu/redmine/issues/70882017-11-23T11:10:06ZAndreas Müllerbug #7062 (Closed): combo box for hierarchically sorted ranks select wrong termshttps://dev.e-taxonomy.eu/redmine/issues/70622017-11-07T10:37:10ZKatja Luther
<p>if the ranks are hierarchically ordered the selection in the combo box is wrong, for example selecting infradivision results in Superclass.</p>
feature request #7056 (Resolved): Media View should show Previewhttps://dev.e-taxonomy.eu/redmine/issues/70562017-11-06T14:01:07ZKatja Luther
<p>The media view should provide a preview of the image. the default should be no preview but it should be turned on by the preferences.</p>
bug #7053 (Closed): TeamOrPersonField disabled state inconsistenthttps://dev.e-taxonomy.eu/redmine/issues/70532017-11-03T16:34:20ZAndreas Kohlbecker
<p>A couple of button and fields in the TeamOrPersonField are not correctly disabled when the user is not granted with the authority to edit the team or persons</p>
bug #7046 (Closed): replace open session per view pattern by DTO strategyhttps://dev.e-taxonomy.eu/redmine/issues/70462017-11-02T09:35:41ZAndreas Kohlbecker
<p>In <a class="issue tracker-4 status-5 priority-10 priority-lowest closed" title="bug: Multiple representations of the same entity merge problem (Closed)" href="https://dev.e-taxonomy.eu/redmine/issues/6687">#6687</a> the open session per view pattern has been implemented for the cdm-vaadin mvp framework. </p>
<p>It turned out that this approach is causing problems since a session opened in one view needs to be reused in multiple request threads. In order to accomplish this it is always required to have a transaction open for the whole lifetime of the view which causes an open database connection for the same time. The database connection pool is limited to a maximum amount of open connections and can thus run out of available connections when too many views are opened at the same time. This situation is becoming worse if vaadin views are not destroyed fast enough so that the resource are being freed quickly (<a class="issue tracker-4 status-5 priority-10 priority-lowest closed" title="bug: Vaadin UI and View scope beans are not always destroyed correctly (Closed)" href="https://dev.e-taxonomy.eu/redmine/issues/7047">#7047</a>). </p>
<p>As explained in <a class="wiki-page" href="https://dev.e-taxonomy.eu/redmine/projects/edit/wiki/VaadinNotes#Managing-Hibernate-sessions">VaadinNotes</a> the best way to avoid LazyInitializytionExceptions is to use DTOs or entity bean initialization strategies. This will not only allow to free database connections as quickly as possible but also avoids managing long transactions logs at in the database itself.</p>
<p>TODO:</p>
<ul>
<li>remove all open session per view pattern code</li>
<li>use bean init-strategies to avoid LazyInitializytionExceptions</li>
<li>in order to save edited entities, open a new clean session, merge the modified entity and flush and commit
<ul>
<li>In future we may want to check for intermediate modifications of the entity by other users. I case a modification by someone else is detected the application will present a dialog to inform the user that someone else work will be overwritten. The dialog should present a table of all conflicting properties allowing the user to resolve the conflict. <a class="issue tracker-5 status-4 priority-11 priority-default" title="feature request: conflicting modification check on save and conflict resolution dialog (Feedback)" href="https://dev.e-taxonomy.eu/redmine/issues/7050">#7050</a></li>
</ul></li>
</ul>
feature request #7044 (Closed): Migrate themehttps://dev.e-taxonomy.eu/redmine/issues/70442017-11-02T07:30:46ZPatrick Plitznerbug #7041 (Closed): D&D for classifications should not be possible and corrupts datahttps://dev.e-taxonomy.eu/redmine/issues/70412017-10-27T21:23:30ZAndreas Müller
<p>Currently classification allows drag&drop on another classification. This should not be allowed as the expected result is not clear.<br>
Also it seems to corrupt data and throw exceptions. E.g. because now there are non-root nodes with no taxon attached.</p>
<p>Also D&D from Classifications to TaxonNodes should not be possible for the same reason.</p>
<p>Or we may clearly define what the expected result is. What do we expect to happen with the old classification and the old root node.</p>
feature request #7028 (Closed): make available distribution status configurable in vaadin distrib...https://dev.e-taxonomy.eu/redmine/issues/70282017-10-20T08:38:50ZAndreas Müller
<p>this is partly a cdmlib, partly a vaadin ticket</p>
bug #7027 (Closed): GrantedAuthorityImpl.authority entities inconsistenthttps://dev.e-taxonomy.eu/redmine/issues/70272017-10-19T15:57:04ZAndreas Kohlbecker
<p>The operation part in the CdmAuthorities appear to be created inconsistently. Originally the single CRUD entries concatenated with a comma only, by now it is comma + space, this leads to inconsistent data:</p>
<pre>REGISTRATION.[CREATE,READ,UPDATE,DELETE]
REGISTRATION.[CREATE,READ]
TAXONNAME.[UPDATE,DELETE]{3747ffff-e6a3-4daa-90fd-120ca058dc03}
TAXONNAME.[UPDATE,DELETE]{0d363647-f866-424d-ae27-4f0afa318b10}
TAXONNAME.[CREATE,READ]
TAXONNAME.[UPDATE, DELETE]{73c99d6e-113f-4802-ae6a-930e7abc0bd1}
TAXONNAME.[UPDATE, DELETE]{0d363647-f866-424d-ae27-4f0afa318b10}
</pre>
<p>it is unknown since when this is happening, but it is for sure due to changes in the toString method of EnumSet which is used by the CdmAuthorities.toString() method.</p>
<p>The stringification of CdmAuthorities must be independent an robust!</p>
feature request #7026 (Closed): RegistrationVoter evaluates CdmAuthorities with RegistrationStatu...https://dev.e-taxonomy.eu/redmine/issues/70262017-10-19T14:23:49ZAndreas Kohlbecker
<ol>
<li>Registration Stage changes will be triggered via the REST services, (see <a class="issue tracker-6 status-2 priority-11 priority-default" title="task: Workflow with Pensoft (In Progress)" href="https://dev.e-taxonomy.eu/redmine/issues/7012">#7012</a>) 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)</li>
<li>Once a Registration has left the state PREPARATION a per entity permission for this registration 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 again needs to be able to add typeDesignations. This is rather complicated and 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 authoritiy is only applicable as long as the Registration is in the named status.</li>
</ol>
<p>(both statements copied from <a class="issue tracker-5 status-6 priority-10 priority-lowest closed" title="feature request: Implement a RegistrationManager with state machine (Rejected)" href="https://dev.e-taxonomy.eu/redmine/issues/6655">#6655</a>)</p>
bug #7021 (Resolved): CREATE permission not sufficient to save new TaxonName entityhttps://dev.e-taxonomy.eu/redmine/issues/70212017-10-17T15:57:21ZAndreas Kohlbecker
<p>Saving a newly created name entity fails if the authenticated use is only having the <code>TAXONNAME.[CREATE,READ]</code> authority.</p>
<p>in the <code>cdm-vaadin:eu.etaxonomy.cdm.service.CdmStore.saveBean(..)</code> method the the bean is saved by doing a merge:</p>
<pre><code class="java syntaxhl"><span class="kd">public</span> <span class="nc">EntityChangeEvent</span> <span class="nf">saveBean</span><span class="o">(</span><span class="no">T</span> <span class="n">bean</span><span class="o">)</span> <span class="o">{</span>
<span class="nc">Type</span> <span class="n">changeEventType</span><span class="o">;</span>
<span class="k">if</span><span class="o">(</span><span class="n">bean</span><span class="o">.</span><span class="na">getId</span><span class="o">()</span> <span class="o">></span> <span class="mi">1</span><span class="o">){</span>
<span class="n">changeEventType</span> <span class="o">=</span> <span class="nc">Type</span><span class="o">.</span><span class="na">MODIFIED</span><span class="o">;</span>
<span class="o">}</span> <span class="k">else</span> <span class="o">{</span>
<span class="n">changeEventType</span> <span class="o">=</span> <span class="nc">Type</span><span class="o">.</span><span class="na">CREATED</span><span class="o">;</span>
<span class="o">}</span>
<span class="nc">Session</span> <span class="n">session</span> <span class="o">=</span> <span class="n">getSession</span><span class="o">();</span>
<span class="n">logger</span><span class="o">.</span><span class="na">trace</span><span class="o">(</span><span class="k">this</span><span class="o">.</span><span class="na">_toString</span><span class="o">()</span> <span class="o">+</span> <span class="s">".onEditorSaveEvent - session: "</span> <span class="o">+</span> <span class="n">session</span><span class="o">.</span><span class="na">hashCode</span><span class="o">());</span>
<span class="k">if</span><span class="o">(</span><span class="n">txNonConversational</span> <span class="o">==</span> <span class="kc">null</span> <span class="o">||</span> <span class="o">(</span><span class="n">conversationHolder</span> <span class="o">!=</span> <span class="kc">null</span> <span class="o">&&</span> <span class="o">!</span><span class="n">conversationHolder</span><span class="o">.</span><span class="na">isTransactionActive</span><span class="o">())){</span>
<span class="c1">// no running transaction, start one ...</span>
<span class="n">startTransaction</span><span class="o">();</span>
<span class="o">}</span>
<span class="c1">// merge the changes into the session, ...</span>
<span class="no">T</span> <span class="n">mergedBean</span> <span class="o">=</span> <span class="n">mergedBean</span><span class="o">(</span><span class="n">bean</span><span class="o">);</span>
<span class="n">session</span><span class="o">.</span><span class="na">flush</span><span class="o">();</span>
<span class="n">commitTransction</span><span class="o">();</span>
<span class="k">return</span> <span class="k">new</span> <span class="nf">EntityChangeEvent</span><span class="o">(</span><span class="n">mergedBean</span><span class="o">.</span><span class="na">getClass</span><span class="o">(),</span> <span class="n">mergedBean</span><span class="o">.</span><span class="na">getId</span><span class="o">(),</span> <span class="n">changeEventType</span><span class="o">);</span>
<span class="o">}</span>
</code></pre>
<p>The <code>session.flush()</code> after the merge causes a <code>scheduleUpdate()</code> which in fact is requiring the authenticated user being granted with the <code>UPDATE</code> authority. Below is the according stack trace: </p>
<pre>eu.etaxonomy.cdm.database.PermissionDeniedException: [UPDATE] not permitted for 'andreas' on TaxonName[uuid:b93e9a49-5016-48d0-93ef-38c12ba3886e', toString:'TaxonName#2343<b93e9a49-5016-48d0-93ef-38c12ba3886e>']
at eu.etaxonomy.cdm.persistence.hibernate.CdmSecurityHibernateInterceptor.checkPermissions(CdmSecurityHibernateInterceptor.java:158)
at eu.etaxonomy.cdm.persistence.hibernate.CdmSecurityHibernateInterceptor.onFlushDirty(CdmSecurityHibernateInterceptor.java:116)
at org.hibernate.event.internal.DefaultFlushEntityEventListener.invokeInterceptor(DefaultFlushEntityEventListener.java:348)
at org.hibernate.event.internal.DefaultFlushEntityEventListener.handleInterception(DefaultFlushEntityEventListener.java:325)
at org.hibernate.event.internal.DefaultFlushEntityEventListener.scheduleUpdate(DefaultFlushEntityEventListener.java:276)
at org.hibernate.event.internal.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:143)
at org.hibernate.event.internal.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:216)
at org.hibernate.event.internal.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:85)
at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:38)
at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1282)
at eu.etaxonomy.cdm.service.CdmStore.saveBean(CdmStore.java:206)
</pre> feature request #7018 (Closed): implement a CdmPermissionVoter and default authorities for Specim...https://dev.e-taxonomy.eu/redmine/issues/70182017-10-16T13:49:03ZAndreas Kohlbecker
<p>SpecimenOrObservationBase need to be protected by a SpecimenOrObservationBaseVoter which evaluates CRUD permissions given to users or Groups.</p>
<a name="Permissions-and-the-derivation-hierachy"></a>
<h2 >Permissions and the derivation hierachy<a href="#Permissions-and-the-derivation-hierachy" class="wiki-anchor">¶</a></h2>
<p>If a per entity authority for a SpecimenOrObservationBase is given to a user the hierarchy of the DerivedUnits becomes important</p>
<p>In case of the Phycobank project a per entity authority is given for the FieldUnit and this permission will intrinsically be propagated to all children in the the derivation tree.</p>
<p>This approach seems to be sufficient for most project workflows. If user is not having the permission to edit the whole derivation tree it can be granted to edit a specific DerivedUnit and will then be able to create and modify all units which are derivatives of the one he is allowed to edit. But this might not be appropriate in all cases:</p>
<p>DerivedUnits and DerivationEvents can form graphs with multiple roots. </p>
<pre>fuA -- duA
\
duAB -- du2
/
fuB -- duB
</pre>
<p>In order to modify <code>du2</code> it is either necessary to have the per entity authority for </p>
<ul>
<li>(1) <code>duAB</code>, as mentioned above, or </li>
<li>(2) for <code>fuA</code> AND <code>fuB</code>. </li>
</ul>
<p>This second (2) approach is however not feasible with the current <code>CdmAuthorities</code> and the <code>CdmPermissionVoter.furtherVotingDescisions((CdmAuthority cdmAuthority, Object object, Collection<ConfigAttribute> attributes, ValidationResult validationResult)</code> which is only able to operate on one CdmAuthority at the same time. To make it possible to validate permissions as in (2) it would be needed to pass all <code>CdmAuthority</code> for which the voter is responsible for to the furtherVotingDescisions method. ==> handled in <a class="issue tracker-5 status-1 priority-11 priority-default" title="feature request: Allow SpecimenOrObservationBaseVoter to make futher voting decision on base of multiple authorities (New)" href="https://dev.e-taxonomy.eu/redmine/issues/7020">#7020</a></p>
feature request #7016 (Rejected): implement a CdmPermissionVoter for TypeDesignationshttps://dev.e-taxonomy.eu/redmine/issues/70162017-10-13T13:27:53ZAndreas Kohlbecker
<p>TypeDesignations need to be protected by a TypeDesignationsVoter which evaluates CRUD permissions given to users or Groups.</p>
feature request #7011 (Closed): Migrate group authority editorhttps://dev.e-taxonomy.eu/redmine/issues/70112017-10-09T14:25:14ZPatrick Plitznerfeature request #7006 (Closed): Migrate preferenceshttps://dev.e-taxonomy.eu/redmine/issues/70062017-10-05T13:16:51ZPatrick Plitzner
<p>This can be done with a copy of the plugin provided by OPCoach (<a href="https://github.com/opcoach/e4Preferences">https://github.com/opcoach/e4Preferences</a>).</p>
<p>This might also give us the possibility to handle where and how preferences are stored.</p>
<p>Later on we should use Annotation to handle preferences (@Preference)</p>