Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FTM: working version of a piece of content can be seen in Live Mode #31367

Closed
nollymar opened this issue Feb 12, 2025 · 3 comments · Fixed by #31431
Closed

FTM: working version of a piece of content can be seen in Live Mode #31367

nollymar opened this issue Feb 12, 2025 · 3 comments · Fixed by #31431

Comments

@nollymar
Copy link
Contributor

Parent Issue

No response

Problem Statement

A content author edits a piece of content with changes to be published in the future. When he goes to see the Live page with the content, it shows the working version in the present instead of the published one.

Steps to Reproduce

Follow the steps described in the attached video

Screen.Recording.2025-02-12.at.12.08.51.PM.mov

Acceptance Criteria

A user should never see working versions in Live mode

dotCMS Version

main

Proposed Objective

Please Select

Proposed Priority

Please Select

External Links... Slack Conversations, Support Tickets, Figma Designs, etc.

No response

Assumptions & Initiation Needs

No response

Quality Assurance Notes & Workarounds

No response

Sub-Tasks & Estimates

No response

@fabrizzio-dotCMS
Copy link
Contributor

fabrizzio-dotCMS commented Feb 12, 2025

The cause of this issue is located in the class com.dotcms.rendering.velocity.services.ContentletLoader
in line 651 We need to remove the && TimeMachineUtil.isNotRunning() part of it
Image

The resulting code should look like this

final String inode = key.mode.showLive
                ? contentletVersionInfo.getLiveInode()
                : contentletVersionInfo.getWorkingInode();

The problem I believe is that we are using a session variable that once has been set with the time machine reminds there and breaks stuff

@fabrizzio-dotCMS
Copy link
Contributor

fabrizzio-dotCMS commented Feb 12, 2025

Writing a test for this will be quite difficult as I'm not sure why it only happens with this CT.
I have other Karate tests that go through this scenario but I'm not sure what's different here.

@valentinogiardino valentinogiardino moved this from In Progress to In Review in dotCMS - Product Planning Feb 20, 2025
github-merge-queue bot pushed a commit that referenced this issue Feb 20, 2025
…ode #31367 (#31431)

### Proposed Changes
* Modified `ContentletLoader.java` to ensure the Live page always
displays the published version of content, regardless of the Time
Machine state.
* Added new Karate tests to validate the behavior of future-published
content, including cases with VTL code like banners.
* Updated existing test scenarios to include banner content and
additional edge cases.

### Checklist
- [x] Tests
- [x] Translations
- [x] Security Implications Contemplated (add notes if applicable)

### Additional Info
This PR addresses an issue where content authors editing content with
future publish dates would see the working version on the Live page
instead of the currently published version. The fix ensures that the
Live page always displays the correct published content, even when
future content is scheduled.
@github-project-automation github-project-automation bot moved this from In Review to Done in dotCMS - Product Planning Feb 20, 2025
@valentinogiardino valentinogiardino removed their assignment Feb 20, 2025
@nollymar nollymar reopened this Feb 20, 2025
@github-project-automation github-project-automation bot moved this from QA to Current Sprint Backlog in dotCMS - Product Planning Feb 20, 2025
@nollymar nollymar moved this from Current Sprint Backlog to QA in dotCMS - Product Planning Feb 20, 2025
@jgambarios jgambarios self-assigned this Feb 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

5 participants