[MGNLUI-3427] Parent item may be null when executing OpenCreateDialogAction Created: 19/Dec/14  Updated: 06/Aug/15  Resolved: 02/Jun/15

Status: Closed
Project: Magnolia UI
Component/s: framework
Affects Version/s: None
Fix Version/s: 5.3.9

Type: Bug Priority: Major
Reporter: Lars Fischer Assignee: Federico Grilli
Resolution: Fixed Votes: 1
Labels: choosedialog, support, uzh
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File textImage1.png     PNG File textImage2.png    
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

To reproduce use STK Text and Image component. An exception is thrown when no folder is selected before clicking "upload & edit".
This happens e.g. when no selection has been made yet and a info.magnolia.ui.vaadin.integration.NullItem instance is passed by default to the action ctor

See attached screenshots.



 Comments   
Comment by Federico Grilli [ 11/Feb/15 ]

Apparently this has been fixed at least since dam 2.0.7 (Magnolia 5.3.7) as I cannot reproduce it.

Comment by Lars Fischer [ 03/Mar/15 ]

Client checked and found that it still doesn't work.

What I found: Now the buttons on the left "Upload..." only are selectable when no asset is selected or a folder (which is wrong too).

Comment by Frank Sommer [ 23/Apr/15 ]

If you clear the dam link field in dialog before opening the choose dialog, the error will be occure. Reproduced with M5.3.7.

Caused by: java.lang.NullPointerException
        at info.magnolia.ui.vaadin.integration.contentconnector.JcrContentConnector.getNewItemId(JcrContentConnector.java:200)
        at info.magnolia.ui.framework.action.OpenCreateDialogAction.execute(OpenCreateDialogAction.java:88)
        at info.magnolia.ui.api.action.AbstractActionExecutor.execute(AbstractActionExecutor.java:62)
        ... 129 more
Comment by Mikaël Geljić [ 21/May/15 ]
  1. At first the fix sounds ok, but I'm wondering why the defaultItemId fallback is not implemented on the choose-dialog itself (much like the workbench is supposed to do by default)
  2. In UploadAndEditActionRenderer, not disabling the Button on click will have the side-effect of allowing people to double-click it, firing the action twice. We need a proper mechanism to give the hand back to the dialog (refresh, re-evaluate availability) when an error occurs through DialogActionExecutor. Workaround exists (reselect item) so we may as well ignore that glitch?
  3. Check formatting in action and test, e.g. missing space around if statement, indentation problem (maybe a tab character in test), unnecessary new line?
Comment by Federico Grilli [ 21/May/15 ]

1) I agree, you mean something like this https://gist.github.com/anonymous/bb7b5849a985d800dea7 ?
2) Unless I miss something, the fix seems safe to me. In this case the chooser dialog is covered by another modal dialog - the asset editor one - so there's no chance (of course apart from playing with js and remove the asset editor node from dom) for a double-click

Comment by Federico Grilli [ 26/May/15 ]

See MGNLUI-3427-review branch

Comment by Mikaël Geljić [ 28/May/15 ]

@fgrilli
#1 Much like that yes, minus the the extra parenthesis on line 10
#2 Could happen—especially if you have a slow connection—that you might be able to double-click before the asset edit dialog opens.

Comment by Aleksandr Pchelintcev [ 28/May/15 ]

I think the test could be improved:

  • make content connector return some specific object (obj) as a default item id with a mock
  • return a tested Item for that particular obj
  • ensure that the Item is within arguments -> no need for the verify()

Also test doesn't need JavaDoc which anyway doesn't explain much.

Generated at Mon Feb 12 09:06:30 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.