Project

General

Profile

Actions

bug #7390

closed

possible permission clash when adding basionym

Added by Andreas Kohlbecker about 6 years ago. Updated about 6 years ago.

Status:
Duplicate
Priority:
New
Category:
cdmlib
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Severity:
normal
Found in Version:
Tags:

Description

When a user is only having per entity grants to UPDATE TaxonNames adding a basionym to a taxonname may fail:

  • TaxonName "Beta exemplaris" for which the user has the UPDATE authority
  • TaxonName "Alpha exemplaris" for which the user is not having the update permission.

Adding "Alpha exemplaris" as basionym to "Beta exemplaris" will fail in this situation during the hibernate session flush since the new basionym name relationships will be added to both of the taxon names. This operation should be possible, though. The scientific name at the from-side (that is the basionym) of the name relation is not altered by using it as a basionym for another name.

The same issue exists also replaced synonym relations!

Possible solutions:

  • General solution:
    • Skip the permission check for name relations at the from-side for basionym and replaced-synonym relations. How about other relations? (This can be reached e.g. by removing the according Cascade)
    • Introduce a new permission concept like privileged access for updates: priviledged update? (see SAP)
  • Application specific: Temporarily grant the UPDATE authority to the user performing the operations in the client application. Grant before flushing the session and remove the grant afterwards. Use a try-catch-finally clause where the withdrawal of the temporary permission is done in the finally clause. --> #7391

see also WorkshopRightsAndRoles2017-11


Related issues

Related to EDIT - bug #7391: grant UPDATE for taxonnames temporarily when using a name as basionym RejectedAndreas Kohlbecker

Actions
Related to EDIT - bug #7392: Remove Cascade from relationsClosedAndreas Müller

Actions
Actions #1

Updated by Andreas Kohlbecker about 6 years ago

  • Related to bug #7391: grant UPDATE for taxonnames temporarily when using a name as basionym added
Actions #2

Updated by Andreas Kohlbecker about 6 years ago

  • Tags changed from phycobank to permission
Actions #3

Updated by Andreas Kohlbecker about 6 years ago

  • Description updated (diff)
Actions #4

Updated by Andreas Müller about 6 years ago

  • Status changed from New to In Progress
  • Target version changed from Unassigned CDM tickets to Release 5.0

I think we should first check if removing Cascade from RelationBase.from and RelationBase.to may solve the problem. This is something we are planning anyway to improve performance.
Only we need to check if some explicit saves need to be handled within running applications (TaxEditor, VaadinEditor, imports, ...). First expectation is that only imports may need to be adapted at some points.

Actions #5

Updated by Andreas Müller about 6 years ago

  • Description updated (diff)

Andreas Müller wrote:

I think we should first check if removing Cascade from RelationBase.from and RelationBase.to may solve the problem. This is something we are planning anyway to improve performance.

This actually is equivalent with the "general solution"

Actions #6

Updated by Andreas Kohlbecker about 6 years ago

  • Description updated (diff)
Actions #7

Updated by Andreas Kohlbecker about 6 years ago

  • Description updated (diff)
Actions #8

Updated by Andreas Kohlbecker about 6 years ago

I did some further examination of an concrete example for this issue. The problem actually only occurs when adding a second basionym to a name B which already is having a basionym A where the basionym A is already being used as basionym for a name C. In this case the
PermissionDeniedException is thrown when the second basionym has been added to A.

Actions #9

Updated by Andreas Müller about 6 years ago

  • Related to bug #7392: Remove Cascade from relations added
Actions #10

Updated by Andreas Kohlbecker about 6 years ago

  • Status changed from In Progress to Duplicate

This issue has been clearly solved by fixing #7392, so we can consider this issue being a duplicate of #7392.

Actions

Also available in: Atom PDF