john-thomas-dotcms
commented
1 month ago This has been going back and forth for a while (years), and we've taken several shots at this, but we always end up with use cases where things don't work as expected. So, we're going to have an internal meeting to clearly define the different use cases and expected behavior.
Parent Issue
No response
Problem Statement
If you modify a template and PP it, the multi_tree table on the receiver won't be updated so the page will defer from the sender (or if the template originally had timestamp UUIDs, the page will be blank).
Steps to Reproduce
1- Create a design template like this one:
3- Create a page with that template
4- Add a few contents
5- PP the created page = Pages look the same on sender and receiver.
6- Modify the template: Add a new box before the second row and should use the same container that will be on the second row.
7- PP the template using the filter Everything and Dependencies.
8- Compare the pages; the one of the senders looks different from the one of the receiver.
Sender
Receiver
NOTE: The customer was coming from pretty old versions when template-containers UUIDs weren't sequential; when updating the template, it updated the UUIDs to sequential, so the page in the receiver shows blank due to the relation_type in the multi_tree table still using the old ones.
Acceptance Criteria
The page should look the same on the sender and on the receiver.
When PP a template, if there were updates in the design, all pages that uses that template should be PP.
dotCMS Version
Tested on 24.04.24 LTS and demo, but probably all LTS are affected.
Proposed Objective
Customer Success
Proposed Priority
Priority 2 - Important
External Links... Slack Conversations, Support Tickets, Figma Designs, etc.
https://dotcms.zendesk.com/agent/tickets/116560
Assumptions & Initiation Needs
No response
Quality Assurance Notes & Workarounds
The current workaround is that when PP a template, Force push all impacted pages.
Sub-Tasks & Estimates
No response