[MGNLDATA-127] Subtype dialog reload incorrectly after validation error. Created: 08/Jul/11  Updated: 07/Jan/13  Resolved: 11/Dec/12

Status: Closed
Project: Magnolia Data Module (closed)
Component/s: None
Affects Version/s: 1.6.3
Fix Version/s: 1.7.4

Type: Bug Priority: Critical
Reporter: Danilo Ghirardelli Assignee: Jaroslav Simak
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File rename.patch    
Issue Links:
Cloners
is cloned by MGNLDATA-162 CLONE -Subtype dialog reload incorrec... Closed
relation
is related to MAGNOLIA-3245 Paragraph does not render after faili... Closed
is related to MGNLDATA-130 Error while renaming sub-items. Closed
is related to MGNLDATA-144 Validation does not work for subtype ... Closed
is related to MGNLDATA-157 Mark as deleted don't work for data Closed
Template:
Patch included:
Yes
Acceptance criteria:
Empty
Date of First Response:

 Description   

Steps to reproduce the problem:

  • Create a new type in Data module (I will reference it as "myType")
  • Create a subtype for the new type (I will reference it as "mySubType")
  • Define a simple dialog for myType
  • Define another dialog for mySubType, adding a new edit control
  • Mark the edit control of the subtype as required
  • Go to the tree and create a new instance of myType, and save it
  • Select the instance and click on "new", the dialog of mySubType will show
  • Try to save the empty dialog

The validation stop the saving process, and the error message for the required field is shown correctly. But the dialog behind now is the myType one, and not the mySubType I would expect.
Saving that dialog may cause a real mess in some cases... You will have then a node of myType under another node of myType even if your configuration would not allow it, the user is expecting some data to edit at that level but opening the faulty node will show another dialog (myType instead of mySubType), and obviously xpath queries may have unexpected results.



 Comments   
Comment by Danilo Ghirardelli [ 08/Jul/11 ]

The problem seems to be that even for subtypes, the dialog is generated with the form parameter "mgnlDialog" with the value of the main type. But at this point I don't if it's related to the generation of the bottom bar itself.

Comment by Danilo Ghirardelli [ 12/Aug/11 ]

The very same patch for MGNLDATA-130 seems to solve also this problem.
The workaroud of setting "dialogName" in each tree works fine too.

Comment by Jean-Francois Nadeau [ 12/Jul/12 ]

I'm on 4.5.3 and I hit a similar problem and the workaround of setting dialogName does not work. Here are the steps to reproduce it:

Create a new type in Data module (I will reference it as "myType")
Create a subtype for the new type (I will reference it as "mySubType")
Define a simple dialog for myType
Define another dialog for mySubType
Add a new edit control to myType and mark the edit control as required
Go to the tree and create a new instance of myType, and save it
Select the instance and click on "new", the dialog of mySubType will show
Try to save dialog and it will show you a validation error showing you an empty dialog from myType telling you one field is required but empty.

This is like the validation of myType is used instead of mySubType.

Comment by Jean-Francois Nadeau [ 13/Jul/12 ]

FYI I can reproduce it on the official magnolia demo site http://demo.magnolia-cms.com

Comment by Jean-Francois Nadeau [ 13/Jul/12 ]

Like Danilo Ghirardelli said the dialog is generated with the form parameter mgnlDialog with the value of the main type. The only workaround I know is to create another dummy subtype. Because if you have at least 2 subtypes under the main type a form with a radio button will ask you to select the subtype you want to create. After that, the dialog will contain the good mgnlDialog parameter. But this is not nice at all.

This bug was open more than one year ago. Why nobody wants to fix it.

Generated at Mon Feb 12 05:11:37 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.