[PAGES-598] Dialog saved into parent page instead of component when going into another app and back Created: 09/May/22  Updated: 16/Aug/22  Resolved: 14/Jul/22

Status: Closed
Project: Magnolia pages module
Component/s: None
Affects Version/s: 6.2.18
Fix Version/s: 6.2.20

Type: Bug Priority: Critical
Reporter: Carlos Cantalapiedra Assignee: Lam Nguyen Bao
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: 5d 7.5h
Original Estimate: Not Specified

Attachments: File magnolia-demo-error.mp4     Text File pages.patch     Text File ui.patch    
Issue Links:
Problem/Incident
Template:
Acceptance criteria:
Empty
Task DoD:
[X]* Doc/release notes changes? Comment present?
[X]* Downstream builds green?
[X]* Solution information and context easily available?
[X]* Tests
[X]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[X]* Steps to reproduce, expected, and actual results filled
[X]* Affected version filled
Date of First Response:
Epic Link: AuthorX Support
Sprint: AuthX 13
Story Points: 2
Team: AuthorX

 Description   

Steps to reproduce:

  1. Go to demo, open a travel/about/Company
  2. Edit the Text&Image component and include some data at the Image tab (e.g, Image title, Caption...)
  3. Without closing the dialog, copy the URL to open the dam app (https://demo.magnolia-cms.com/.magnolia/admincentral#app:dam)
  4. Close the Assets app (using the X icon) and notice you will be redirected to the opened dialog we were on step 3
  5. Save the dialog (Save changes)
  6. Go to JCR app, open the /travel/about/Company and check that the fields you fulfilled on the step 2 have been stored in: root page level instead of in the Text&Image, if you open the dialog again it is empty

Dev notes:

Please, check the attached video.



 Comments   
Comment by Roman Kovařík [ 18/May/22 ]

4. Doesn't work for me (both copying the URL or manually changing the URL as shown in the video)

It's not clear to me how this could happen as by manually changing the URL, the existing UI should be destroyed (so in my case I was just redirected to findbar as no other app except dam was opened after changing the URL).

Can anybody else reproduce this? 

Comment by Mercedes Iruela [ 18/May/22 ]

Hi Roman, I changed the steps to reproduce, the data is stored in the wrong place, in root instead of in the text&image component, so that if you open again the text&image, it is empty, but if you check in the JCR it there at page root level.

Comment by Roman Kovařík [ 18/May/22 ]

Hey Mercedes

the problem on my side is that the point 4. is not happening to me (UI is destroyed including all opened apps). So I have no dialog left to save .

Comment by Mercedes Iruela [ 18/May/22 ]

Are you testing in demo? I have just reproduced it a few minutes ago

Comment by Roman Kovařík [ 18/May/22 ]

Discovery:

  • In case you have troubles to reproduce this: I can't reproduce it in Safari, but I can in Chrome (a timing involved I suppose).
  • He's what happens:
    1. Opening a page sets the valueContext to /page node
    2. Editing = opening a component sets the valueContext to a /page/main/0 node
    3. Changing the url to dam app and closing the dam app rerenders the inner frame (page editor) which triggers the logic described in 1. again
    4. At the point we click save now, the changes are written into /page which is the current node in the valueContext
  • This should be an issue for page editor only (the other apps have always the selected node part of the URL whereas the pages editor always point to the parent page, not the component) therefore I'll move this to the pages project
  • At the point 4. the editor is already in an inconsistent state as the page editor points to the parent page but the dialog is opened for a component
  • Attaching a possible patches for UI and pages. A proper solution in UI might rather be an introduction of ContextProperty#lock/unclock (which is more explicit than an usage of an interceptor to prevent changing the value)
Generated at Mon Feb 12 06:20:30 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.