FOUR-19110: [40531] changes on screen are not reflected in ongoing cases

[eiresendez]

Issue & Reproduction Steps

• Have cases running in a process.
• edit one of the screens that is used in those cases' process.
• save and publish the changes on the screen.
• Changes are reflected only in new cases.

Current behavior

• Changes applied on a screen and published are only reflected in new cases. in 4.10 the changes were reflected in new and also ongoing cases

Expected behavior

• Change should be reflected in ongoing cases.

Solution

• Added a version parameter (screen_version) to screen URLs, generated based on the latest published id of the screen.
• This approach forces the browser to treat each updated published screen as a new resource, preventing the use of outdated cached versions.

How to Test

• Verify that screen updates generate new URLs with different version parameters, ensuring that changes are correctly fetched.
• Test across different browsers to confirm that old cached versions are not used.

Related Tickets & Packages

• FOUR-19110
• Screen Builder PR

Code Review Checklist

• I have pulled this code locally and tested it on my instance, along with any associated packages.
• This code adheres to ProcessMaker Coding Guidelines.
• This code includes a unit test or an E2E test that tests its functionality, or is covered by an existing test.
• This solution fixes the bug reported in the original ticket.
• This solution does not alter the expected output of a component in a way that would break existing Processes.
• This solution does not implement any breaking changes that would invalidate documentation or cause existing Processes to fail.
• This solution has been tested with enterprise packages that rely on its functionality and does not introduce bugs in those packages.
• This code does not duplicate functionality that already exists in the framework or in ProcessMaker.
• This ticket conforms to the PRD associated with this part of ProcessMaker.

ci:next
ci:deploy
ci:screen-builder:bugfix/FOUR-19110

[tokensPM]

QA server K8S was successfully deployed https://ci-366b9da8b8.engk8s.processmaker.net

[caleeli]

Seems there is no cache in the screen:

ScreenCache.mov

[tokensPM]

QA server K8S was successfully deployed https://ci-366b9da8b8.engk8s.processmaker.net

[ryancooley]

@caleeli Is this not the intended behavior? It seems as if it handled the situation correctly. First it returns a 200, then it returns a 304 not modified. cc: @eiresendez

[danloa]

I had some issue, probably web browser related. It used the disk cache to retrieve the screen. After I disabled and enabled the browser cache, everything is working correctly now.

[tokensPM]

QA server K8S was successfully deployed https://ci-366b9da8b8.engk8s.processmaker.net

[devmiguelangel]

[eiresendez]

Issue & Reproduction Steps

• Have cases running in a process.
• edit one of the screens that is used in those cases' process.
• save and publish the changes on the screen.
• Changes are reflected only in new cases.

Current behavior

• Changes applied on a screen and published are only reflected in new cases. in 4.10 the changes were reflected in new and also ongoing cases

Expected behavior

• Change should be reflected in ongoing cases.

Solution

• Added a version parameter (screen_version) to screen URLs, generated based on the latest published id of the screen.
• This approach forces the browser to treat each updated published screen as a new resource, preventing the use of outdated cached versions.

How to Test

• Verify that screen updates generate new URLs with different version parameters, ensuring that changes are correctly fetched.
• Test across different browsers to confirm that old cached versions are not used.

Related Tickets & Packages

• FOUR-19110
• Screen Builder PR

Code Review Checklist

• I have pulled this code locally and tested it on my instance, along with any associated packages.
• This code adheres to ProcessMaker Coding Guidelines.
• This code includes a unit test or an E2E test that tests its functionality, or is covered by an existing test.
• This solution fixes the bug reported in the original ticket.
• This solution does not alter the expected output of a component in a way that would break existing Processes.
• This solution does not implement any breaking changes that would invalidate documentation or cause existing Processes to fail.
• This solution has been tested with enterprise packages that rely on its functionality and does not introduce bugs in those packages.
• This code does not duplicate functionality that already exists in the framework or in ProcessMaker.
• This ticket conforms to the PRD associated with this part of ProcessMaker.

ci:next
ci:deploy
ci:screen-builder:bugfix/FOUR-19110

[tokensPM]

QA server K8S was successfully deployed https://ci-366b9da8b8.engk8s.processmaker.net

[caleeli]

Seems there is no cache in the screen:

ScreenCache.mov

[tokensPM]

QA server K8S was successfully deployed https://ci-366b9da8b8.engk8s.processmaker.net

[ryancooley]

@caleeli Is this not the intended behavior? It seems as if it handled the situation correctly. First it returns a 200, then it returns a 304 not modified. cc: @eiresendez

[danloa]

I had some issue, probably web browser related. It used the disk cache to retrieve the screen. After I disabled and enabled the browser cache, everything is working correctly now.

[tokensPM]

QA server K8S was successfully deployed https://ci-366b9da8b8.engk8s.processmaker.net

[devmiguelangel]

[eiresendez]

Issue & Reproduction Steps

• Have cases running in a process.
• edit one of the screens that is used in those cases' process.
• save and publish the changes on the screen.
• Changes are reflected only in new cases.

Current behavior

• Changes applied on a screen and published are only reflected in new cases. in 4.10 the changes were reflected in new and also ongoing cases

Expected behavior

• Change should be reflected in ongoing cases.

Solution

• Added a version parameter (screen_version) to screen URLs, generated based on the latest published id of the screen.
• This approach forces the browser to treat each updated published screen as a new resource, preventing the use of outdated cached versions.

How to Test

• Verify that screen updates generate new URLs with different version parameters, ensuring that changes are correctly fetched.
• Test across different browsers to confirm that old cached versions are not used.

Related Tickets & Packages

• FOUR-19110
• Screen Builder PR

Code Review Checklist

• I have pulled this code locally and tested it on my instance, along with any associated packages.
• This code adheres to ProcessMaker Coding Guidelines.
• This code includes a unit test or an E2E test that tests its functionality, or is covered by an existing test.
• This solution fixes the bug reported in the original ticket.
• This solution does not alter the expected output of a component in a way that would break existing Processes.
• This solution does not implement any breaking changes that would invalidate documentation or cause existing Processes to fail.
• This solution has been tested with enterprise packages that rely on its functionality and does not introduce bugs in those packages.
• This code does not duplicate functionality that already exists in the framework or in ProcessMaker.
• This ticket conforms to the PRD associated with this part of ProcessMaker.

ci:next
ci:deploy
ci:screen-builder:bugfix/FOUR-19110

[tokensPM]

QA server K8S was successfully deployed https://ci-366b9da8b8.engk8s.processmaker.net

[caleeli]

Seems there is no cache in the screen:

ScreenCache.mov

[tokensPM]

QA server K8S was successfully deployed https://ci-366b9da8b8.engk8s.processmaker.net

[ryancooley]

@caleeli Is this not the intended behavior? It seems as if it handled the situation correctly. First it returns a 200, then it returns a 304 not modified. cc: @eiresendez

[danloa]

I had some issue, probably web browser related. It used the disk cache to retrieve the screen. After I disabled and enabled the browser cache, everything is working correctly now.

[tokensPM]

QA server K8S was successfully deployed https://ci-366b9da8b8.engk8s.processmaker.net

[devmiguelangel]

[eiresendez]

Issue & Reproduction Steps

• Have cases running in a process.
• edit one of the screens that is used in those cases' process.
• save and publish the changes on the screen.
• Changes are reflected only in new cases.

Current behavior

• Changes applied on a screen and published are only reflected in new cases. in 4.10 the changes were reflected in new and also ongoing cases

Expected behavior

• Change should be reflected in ongoing cases.

Solution

• Added a version parameter (screen_version) to screen URLs, generated based on the latest published id of the screen.
• This approach forces the browser to treat each updated published screen as a new resource, preventing the use of outdated cached versions.

How to Test

• Verify that screen updates generate new URLs with different version parameters, ensuring that changes are correctly fetched.
• Test across different browsers to confirm that old cached versions are not used.

Related Tickets & Packages

• FOUR-19110
• Screen Builder PR

Code Review Checklist

• I have pulled this code locally and tested it on my instance, along with any associated packages.
• This code adheres to ProcessMaker Coding Guidelines.
• This code includes a unit test or an E2E test that tests its functionality, or is covered by an existing test.
• This solution fixes the bug reported in the original ticket.
• This solution does not alter the expected output of a component in a way that would break existing Processes.
• This solution does not implement any breaking changes that would invalidate documentation or cause existing Processes to fail.
• This solution has been tested with enterprise packages that rely on its functionality and does not introduce bugs in those packages.
• This code does not duplicate functionality that already exists in the framework or in ProcessMaker.
• This ticket conforms to the PRD associated with this part of ProcessMaker.

ci:next
ci:deploy
ci:screen-builder:bugfix/FOUR-19110

[tokensPM]

QA server K8S was successfully deployed https://ci-366b9da8b8.engk8s.processmaker.net

[caleeli]

Seems there is no cache in the screen:

ScreenCache.mov

[tokensPM]

QA server K8S was successfully deployed https://ci-366b9da8b8.engk8s.processmaker.net

[ryancooley]

@caleeli Is this not the intended behavior? It seems as if it handled the situation correctly. First it returns a 200, then it returns a 304 not modified. cc: @eiresendez

[danloa]

I had some issue, probably web browser related. It used the disk cache to retrieve the screen. After I disabled and enabled the browser cache, everything is working correctly now.

[tokensPM]

QA server K8S was successfully deployed https://ci-366b9da8b8.engk8s.processmaker.net

[devmiguelangel]

[eiresendez]

Issue & Reproduction Steps

• Have cases running in a process.
• edit one of the screens that is used in those cases' process.
• save and publish the changes on the screen.
• Changes are reflected only in new cases.

Current behavior

• Changes applied on a screen and published are only reflected in new cases. in 4.10 the changes were reflected in new and also ongoing cases

Expected behavior

• Change should be reflected in ongoing cases.

Solution

• Added a version parameter (screen_version) to screen URLs, generated based on the latest published id of the screen.
• This approach forces the browser to treat each updated published screen as a new resource, preventing the use of outdated cached versions.

How to Test

• Verify that screen updates generate new URLs with different version parameters, ensuring that changes are correctly fetched.
• Test across different browsers to confirm that old cached versions are not used.

Related Tickets & Packages

• FOUR-19110
• Screen Builder PR

Code Review Checklist

• I have pulled this code locally and tested it on my instance, along with any associated packages.
• This code adheres to ProcessMaker Coding Guidelines.
• This code includes a unit test or an E2E test that tests its functionality, or is covered by an existing test.
• This solution fixes the bug reported in the original ticket.
• This solution does not alter the expected output of a component in a way that would break existing Processes.
• This solution does not implement any breaking changes that would invalidate documentation or cause existing Processes to fail.
• This solution has been tested with enterprise packages that rely on its functionality and does not introduce bugs in those packages.
• This code does not duplicate functionality that already exists in the framework or in ProcessMaker.
• This ticket conforms to the PRD associated with this part of ProcessMaker.

ci:next
ci:deploy
ci:screen-builder:bugfix/FOUR-19110

[tokensPM]

QA server K8S was successfully deployed https://ci-366b9da8b8.engk8s.processmaker.net

[caleeli]

Seems there is no cache in the screen:

ScreenCache.mov

[tokensPM]

QA server K8S was successfully deployed https://ci-366b9da8b8.engk8s.processmaker.net

[ryancooley]

@caleeli Is this not the intended behavior? It seems as if it handled the situation correctly. First it returns a 200, then it returns a 304 not modified. cc: @eiresendez

[danloa]

I had some issue, probably web browser related. It used the disk cache to retrieve the screen. After I disabled and enabled the browser cache, everything is working correctly now.

[tokensPM]

QA server K8S was successfully deployed https://ci-366b9da8b8.engk8s.processmaker.net

[devmiguelangel]

[eiresendez]

Issue & Reproduction Steps

• Have cases running in a process.
• edit one of the screens that is used in those cases' process.
• save and publish the changes on the screen.
• Changes are reflected only in new cases.

Current behavior

• Changes applied on a screen and published are only reflected in new cases. in 4.10 the changes were reflected in new and also ongoing cases

Expected behavior

• Change should be reflected in ongoing cases.

Solution

• Added a version parameter (screen_version) to screen URLs, generated based on the latest published id of the screen.
• This approach forces the browser to treat each updated published screen as a new resource, preventing the use of outdated cached versions.

How to Test

• Verify that screen updates generate new URLs with different version parameters, ensuring that changes are correctly fetched.
• Test across different browsers to confirm that old cached versions are not used.

Related Tickets & Packages

• FOUR-19110
• Screen Builder PR

Code Review Checklist

• I have pulled this code locally and tested it on my instance, along with any associated packages.
• This code adheres to ProcessMaker Coding Guidelines.
• This code includes a unit test or an E2E test that tests its functionality, or is covered by an existing test.
• This solution fixes the bug reported in the original ticket.
• This solution does not alter the expected output of a component in a way that would break existing Processes.
• This solution does not implement any breaking changes that would invalidate documentation or cause existing Processes to fail.
• This solution has been tested with enterprise packages that rely on its functionality and does not introduce bugs in those packages.
• This code does not duplicate functionality that already exists in the framework or in ProcessMaker.
• This ticket conforms to the PRD associated with this part of ProcessMaker.

ci:next
ci:deploy
ci:screen-builder:bugfix/FOUR-19110

[tokensPM]

QA server K8S was successfully deployed https://ci-366b9da8b8.engk8s.processmaker.net

[caleeli]

Seems there is no cache in the screen:

ScreenCache.mov

[tokensPM]

QA server K8S was successfully deployed https://ci-366b9da8b8.engk8s.processmaker.net

[ryancooley]

@caleeli Is this not the intended behavior? It seems as if it handled the situation correctly. First it returns a 200, then it returns a 304 not modified. cc: @eiresendez

[danloa]

I had some issue, probably web browser related. It used the disk cache to retrieve the screen. After I disabled and enabled the browser cache, everything is working correctly now.

[tokensPM]

QA server K8S was successfully deployed https://ci-366b9da8b8.engk8s.processmaker.net

[devmiguelangel]

[eiresendez]

Issue & Reproduction Steps

• Have cases running in a process.
• edit one of the screens that is used in those cases' process.
• save and publish the changes on the screen.
• Changes are reflected only in new cases.

Current behavior

• Changes applied on a screen and published are only reflected in new cases. in 4.10 the changes were reflected in new and also ongoing cases

Expected behavior

• Change should be reflected in ongoing cases.

Solution

• Added a version parameter (screen_version) to screen URLs, generated based on the latest published id of the screen.
• This approach forces the browser to treat each updated published screen as a new resource, preventing the use of outdated cached versions.

How to Test

• Verify that screen updates generate new URLs with different version parameters, ensuring that changes are correctly fetched.
• Test across different browsers to confirm that old cached versions are not used.

Related Tickets & Packages

• FOUR-19110
• Screen Builder PR

Code Review Checklist

• I have pulled this code locally and tested it on my instance, along with any associated packages.
• This code adheres to ProcessMaker Coding Guidelines.
• This code includes a unit test or an E2E test that tests its functionality, or is covered by an existing test.
• This solution fixes the bug reported in the original ticket.
• This solution does not alter the expected output of a component in a way that would break existing Processes.
• This solution does not implement any breaking changes that would invalidate documentation or cause existing Processes to fail.
• This solution has been tested with enterprise packages that rely on its functionality and does not introduce bugs in those packages.
• This code does not duplicate functionality that already exists in the framework or in ProcessMaker.
• This ticket conforms to the PRD associated with this part of ProcessMaker.

ci:next
ci:deploy
ci:screen-builder:bugfix/FOUR-19110

[tokensPM]

QA server K8S was successfully deployed https://ci-366b9da8b8.engk8s.processmaker.net

[caleeli]

Seems there is no cache in the screen:

ScreenCache.mov

[tokensPM]

QA server K8S was successfully deployed https://ci-366b9da8b8.engk8s.processmaker.net

[ryancooley]

@caleeli Is this not the intended behavior? It seems as if it handled the situation correctly. First it returns a 200, then it returns a 304 not modified. cc: @eiresendez

[danloa]

I had some issue, probably web browser related. It used the disk cache to retrieve the screen. After I disabled and enabled the browser cache, everything is working correctly now.

[tokensPM]

QA server K8S was successfully deployed https://ci-366b9da8b8.engk8s.processmaker.net

[devmiguelangel]

[eiresendez]

Issue & Reproduction Steps

• Have cases running in a process.
• edit one of the screens that is used in those cases' process.
• save and publish the changes on the screen.
• Changes are reflected only in new cases.

Current behavior

• Changes applied on a screen and published are only reflected in new cases. in 4.10 the changes were reflected in new and also ongoing cases

Expected behavior

• Change should be reflected in ongoing cases.

Solution

• Added a version parameter (screen_version) to screen URLs, generated based on the latest published id of the screen.
• This approach forces the browser to treat each updated published screen as a new resource, preventing the use of outdated cached versions.

How to Test

• Verify that screen updates generate new URLs with different version parameters, ensuring that changes are correctly fetched.
• Test across different browsers to confirm that old cached versions are not used.

Related Tickets & Packages

• FOUR-19110
• Screen Builder PR

Code Review Checklist

• I have pulled this code locally and tested it on my instance, along with any associated packages.
• This code adheres to ProcessMaker Coding Guidelines.
• This code includes a unit test or an E2E test that tests its functionality, or is covered by an existing test.
• This solution fixes the bug reported in the original ticket.
• This solution does not alter the expected output of a component in a way that would break existing Processes.
• This solution does not implement any breaking changes that would invalidate documentation or cause existing Processes to fail.
• This solution has been tested with enterprise packages that rely on its functionality and does not introduce bugs in those packages.
• This code does not duplicate functionality that already exists in the framework or in ProcessMaker.
• This ticket conforms to the PRD associated with this part of ProcessMaker.

ci:next
ci:deploy
ci:screen-builder:bugfix/FOUR-19110

[tokensPM]

QA server K8S was successfully deployed https://ci-366b9da8b8.engk8s.processmaker.net

[caleeli]

Seems there is no cache in the screen:

ScreenCache.mov

[tokensPM]

QA server K8S was successfully deployed https://ci-366b9da8b8.engk8s.processmaker.net

[ryancooley]

@caleeli Is this not the intended behavior? It seems as if it handled the situation correctly. First it returns a 200, then it returns a 304 not modified. cc: @eiresendez

[danloa]

I had some issue, probably web browser related. It used the disk cache to retrieve the screen. After I disabled and enabled the browser cache, everything is working correctly now.

[tokensPM]

QA server K8S was successfully deployed https://ci-366b9da8b8.engk8s.processmaker.net

[devmiguelangel]