Project

General

Profile

bug #6894

NPE when trying drag&drop a Classification to the GrantedAuthority editor

Added by Andreas Müller over 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
New
Assignee:
Category:
taxeditor
Target version:
Start date:
08/07/2017
Due date:
% Done:

50%

Severity:
critical
Found in Version:
Tags:

Description

This is critical because adding to full classification as a GrantedAuthority is a standard usecase. Maybe this got corrupted when changing classification handling in taxon navigator from classification to taxonnode. this is not the and was the cause for fixing this issue the wrong way!


Related issues

Related to Edit - bug #6783: Menu item for editing right is missing Closed 07/07/2017
Related to Edit - bug #6961: Drag&Drop for taxon nodes throws NPE when hovering Classification Closed 09/20/2017
Duplicated by Edit - bug #6798: NPE when trying to drag&drop a classification to the user rights editor Duplicate 07/11/2017

Associated revisions

Revision 1d45fffd (diff)
Added by Katja Luther over 1 year ago

ref #6894: fix drag&drop in grantedAuthority view for classification

Revision af65d6ac (diff)
Added by Katja Luther over 1 year ago

ref #6894: adapt Drag&drop to use classification as dragsource not the rootnode

Revision 9aa59538 (diff)
Added by Andreas Müller about 1 year ago

fix #6961 fix NPE for TaxonNode d&d when hovering classification in AdapterAssistant class

Revision fa8083dd (diff)
Added by Andreas Müller about 1 year ago

fix #6961 fix further potential NPEs in TreeNodeDropAdapter and TreeNodeDropAdapterAssistant and cleanup

Revision 1cefec6b (diff)
Added by Andreas Müller about 1 year ago

fix #6961 fix further NPEs in TreeNodeDropAdapter and TreeNodeDropAdapterAssistant

Revision 2f567cbc (diff)
Added by Katja Luther about 1 year ago

ref ##6894: revert use of classification instead of rootnode for CdmPermittionVoter

History

#1 Updated by Katja Luther over 1 year ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 50

The exception is not thrwon anymore, but the type is now TaxonNode, not Classification.

#2 Updated by Katja Luther over 1 year ago

the dragAssistant now check if the dragged node is the root node and then uses the classification instead of the taxonnode as drag source.

#3 Updated by Katja Luther over 1 year ago

  • Status changed from In Progress to Resolved
  • Assignee changed from Katja Luther to Andreas Müller

#4 Updated by Andreas Müller over 1 year ago

  • Assignee changed from Andreas Müller to Andreas Kohlbecker

Katja Luther wrote:

The exception is not thrwon anymore, but the type is now TaxonNode, not Classification.

Do we need classification as type? I imagine that handling everything via TaxonNode is easier than having to handle both Classification and TaxonNode. The semantics is the same.

@AK: what do you thing from the security implementation perspective?

#5 Updated by Andreas Müller over 1 year ago

  • Duplicated by bug #6798: NPE when trying to drag&drop a classification to the user rights editor added

#6 Updated by Andreas Müller about 1 year ago

Andreas Müller wrote:

@AK: what do you thing from the security implementation perspective?

??

#7 Updated by Andreas Müller about 1 year ago

  • Related to bug #6783: Menu item for editing right is missing added

#8 Updated by Andreas Müller about 1 year ago

  • Related to bug #6961: Drag&Drop for taxon nodes throws NPE when hovering Classification added

#9 Updated by Andreas Kohlbecker about 1 year ago

  • Assignee changed from Andreas Kohlbecker to Katja Luther

The drag and drop action is no longer causing a NPE but the resulting authority is not correct. The Autority which is created in turn of dropping a clasification is CLASSIFICATION[....] but the TaxonNodeVoter is not able to interpret this. A CdmPermittionVoter is always only responsible for one CDM BaseClass only!! Therefore the resulting authority must the one for the root taxon node of the classification. The drag and drop was originally implemented that way. taxeditor|af65d6ac changed this

#10 Updated by Andreas Kohlbecker about 1 year ago

  • Status changed from Resolved to Feedback

#11 Updated by Andreas Kohlbecker about 1 year ago

  • Description updated (diff)

#12 Updated by Andreas Müller about 1 year ago

So do I understand correctly that a ClassificationVoter does not (yet) exist. If yes than we need of course to store the TaxonNode instead.

However, for the user I find it more comfortable if we show Classification instead of TaxonNode as this is more what the user expects. Maybe the UI could hide this by transforming root nodes to classifications and back when showing / saving data.
But this we can also do in a more advanced UI later if it is difficult to implement now.

#13 Updated by Andreas Kohlbecker about 1 year ago

Andreas Müller wrote:

So do I understand correctly that a ClassificationVoter does not (yet) exist. If yes than we need of course to store the TaxonNode instead.

Exactly! And there will never be a ClassificationVoter since the TaxonNodeVoter is completely sufficient to to the job

#14 Updated by Katja Luther about 1 year ago

  • Status changed from Feedback to Resolved

sorry, I reverted the changes and now the root node is used for the TaxonNodeVoter

#15 Updated by Andreas Müller about 1 year ago

  • Assignee changed from Katja Luther to Andreas Müller

#16 Updated by Andreas Müller about 1 year ago

  • Status changed from Resolved to Closed
  • Assignee changed from Andreas Müller to Katja Luther

Looks good now.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 40 MB)