EDIT: Issueshttps://dev.e-taxonomy.eu/redmine/https://dev.e-taxonomy.eu/redmine/redmine/favicon.ico?14691914852017-11-06T14:01:07ZEDIT Project Management
Redmine 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>
feature request #7044 (Closed): Migrate themehttps://dev.e-taxonomy.eu/redmine/issues/70442017-11-02T07:30:46ZPatrick Plitznerfeature 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>
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>
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>
feature request #7005 (Closed): Migrate import wizardshttps://dev.e-taxonomy.eu/redmine/issues/70052017-10-05T05:40:48ZPatrick Plitzner
<ul>
<li><del>BioCASE/GBIF</del></li>
<li><del>ABCD</del></li>
<li><del>Excel Distribution Data Update</del></li>
<li><del>Excel Normal Explicit Taxa</del></li>
<li><del>RIS Reference</del></li>
<li><del>SDD</del></li>
<li><del>Specimen CDM Excel</del></li>
<li><del>TCS</del></li>
</ul>
feature request #6999 (Closed): RegistrationUI: Enable, disable editor buttons according to the ...https://dev.e-taxonomy.eu/redmine/issues/69992017-09-29T12:31:23ZAndreas Kohlbeckerfeature request #6997 (Closed): RegistrationUI: Show authenticated user in toolbar with option to...https://dev.e-taxonomy.eu/redmine/issues/69972017-09-28T08:22:08ZAndreas Kohlbeckerfeature request #6990 (Closed): Migrate search result viewhttps://dev.e-taxonomy.eu/redmine/issues/69902017-09-27T16:48:05ZPatrick Plitznerfeature request #6989 (Closed): Migrate concept graph viewhttps://dev.e-taxonomy.eu/redmine/issues/69892017-09-27T08:56:45ZPatrick Plitznerfeature request #6985 (Closed): display Registration metadata in footnoteshttps://dev.e-taxonomy.eu/redmine/issues/69852017-09-26T09:55:42ZAndreas Kohlbecker
<p>in <a class="issue tracker-5 status-5 priority-10 priority-lowest closed" title="feature request: Block to display Registration metadata (Closed)" href="https://dev.e-taxonomy.eu/redmine/issues/6959">#6959</a> the display of Registration metadata in a Drupla block has been implemented.</p>
<p>Since a Taxon page can contain multiple Registrations the approach to display this data in a block is not reallay appropriate.<br>
Therefore we decided to show the Registration metadata together with the reference footnote.</p>
<p><a href="https://www.phycobank.org/cdm_dataportal/taxon/f48b4b22-0625-4820-ad82-abf12e20859a" class="external">Planothidium victori</a> is a good example since it has two nomenclatoral acts a registration for each.</p>
<p>The Registration metadata will be appended to the reference:</p>
<pre>{footnoteky} {reference} Registration: {Registration.identifier} {Registration.registrationDate as ISO-Date}
</pre> feature request #6974 (Resolved): improve the io wizardshttps://dev.e-taxonomy.eu/redmine/issues/69742017-09-22T12:48:49ZKatja Luther
<p>die Export-Assistenten (CDM light, DwC-A, …) haben derzeit folgenden Workflow:</p>
<p>1) Auswahl Export-Typ<br>
2) Konfigurationsdetails<br>
3) Export Ziel /Dateiname und Auswahl der zu exportierenden Daten</p>
<p>2 und 3 sollten wir umdrehen denke ich. Insbesondere auch, da in Zukunft die Auswahl der zu exportierenden Daten, nach einer Analyse der Daten die zur Verfügung stehenden Konfigurationsmöglichkeiten beeinflussen könnte.</p>
<p>Aber auch, weil es mir von der allgemeinen Logik her sinnvoller erscheint.</p>
<p>Noch dazu kommt, dass es derzeit möglich ist, bereits nach 2) über Finish den Import zu starten, ohne die Daten unter 3 anzusehen oder zu ändern. Das halte ich nicht für so sinnig. Dadurch kann es im schlimmsten Fall dazu kommen, dass Daten einfach überschrieben werden, ohne dass das gewollt war.</p>
<p>Könntest du das anpassen oder ggf. ein Ticket mit hoher Dringlichkeit anlegen?</p>