bug #7390
closedpossible permission clash when adding basionym
0%
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
Updated by Andreas Kohlbecker over 6 years ago
- Related to bug #7391: grant UPDATE for taxonnames temporarily when using a name as basionym added
Updated by Andreas Kohlbecker over 6 years ago
- Tags changed from phycobank to permission
Updated by Andreas Müller over 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.
Updated by Andreas Müller over 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"
Updated by Andreas Kohlbecker over 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.
Updated by Andreas Müller over 6 years ago
- Related to bug #7392: Remove Cascade from relations added
Updated by Andreas Kohlbecker over 6 years ago
- Status changed from In Progress to Duplicate