FOUR-32683: Preserve PM Block task context in Web Entry redirects

[eiresendez]

Issue & Reproduction Steps

An authenticated Web Entry that transitions into a PM Block creates the child request and task correctly, but the redirect flow retains the parent request ID while applying the child task node ID. This produces an invalid Web Entry URL, a 404 configuration request, and an interstitial that remains loading indefinitely.

1. Import the test_pm_block_6789.json fixture attached to FOUR-32683.
2. Start the parent process through its authenticated Web Entry.
3. Submit the first form and continue until the PM Block creates its child task.
4. Observe that the failing flow combines the parent request ID with the child task node ID.

Solution

• Resolve the complete next assigned task before processing Web Entry socket redirects.
• Pass the target task ID, element ID, and process request ID through Web Entry hard redirects.
• Preserve the existing numeric task-ID redirect contract outside Web Entry.
• Redirect tasks without Web Entry availability to the standard task form.
• Add focused regression tests for child-request, fallback, websocket, and compatibility paths.

How to Test

• Run TaskWebEntryRedirect.spec.js and TaskSelfServiceLock.spec.js.
• Start the attached process through its authenticated Web Entry and submit until it reaches the PM Block.
• Confirm that the child task opens without a stale request ID, 404 response, or infinite interstitial.
• Complete the child task and confirm that the parent request resumes and can finish.

Related Tickets & Packages

• https://processmaker.atlassian.net/browse/FOUR-32683
• https://processmaker.atlassian.net/browse/FOUR-29254
• Companion Package Web Entry PR: https://github.com/ProcessMaker/package-webentry/pull/302

ci:deploy
ci:package-webentry:task/FOUR-32683
.

[cypress]

screen-builder    Run #2357

Run Properties:   Failed #2357  •  3dbb40093a: FOUR-32683: Preserve PM Block task context in Web Entry redirects

Project	screen-builder
Branch Review	task/FOUR-32683
Run status	Failed #2357
Run duration	46m 16s
Commit	3dbb40093a: FOUR-32683: Preserve PM Block task context in Web Entry redirects
Committer	Eleazar Resendez
View all properties for this run ↗︎

---

Test results
Failures	2
Flaky	0
Pending	17
Skipped	4
Passing	389
View all changes introduced in this branch ↗︎

---

Tests for review

  DatePicker.spec.js • 1 failed test • CI - Chrome

View Output

Test		Artifacts
Date Picker > Date time picker validate when the user enter a string instead of a valid date		Test Replay Screenshots

  ComputedFields.spec.js • 1 failed test • CI - Chrome

View Output

Test		Artifacts
Computed fields > Focuses the first field that has an error		Test Replay Screenshots

[processmaker-sonarqube]

Quality Gate passed

Issues
0 New issues
6 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
46.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[nolanpro]

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

[nolanpro]

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

[eiresendez]

@nolanpro @sanjacornelius @CarliPinell

The Decisions SonarQube migration is also blocking this PR, but the failure has two separate causes:

• The old SonarQube server passed commit 962d07d with 46.7% coverage on new code. The current commit 22734e1 reports 49.2%, but the new Decisions Quality Gate now requires at least 80%. The LCOV report was generated and imported successfully; however, Screen Builder’s Sonar workflow only merges Cypress coverage. The focused Jest regression tests added for this PR are not executed or included in the CI coverage report.
• The single new issue is javascript:S8961 at src/components/task.vue:564. Screen Builder uses Vue 2.6, and SonarSource lists JS-2088, “S8961 should not raise on Vue 2 projects,” as fixed in SonarJS 13.4.

How can we solve this?

Evidence:

• Previous CI/Sonar run: https://github.com/ProcessMaker/screen-builder/actions/runs/32070384575
• Current CI/Sonar run: https://github.com/ProcessMaker/screen-builder/actions/runs/32158391731
• SonarJS 13.4 fix: https://github.com/SonarSource/SonarJS/releases/tag/13.4.0.43982

[CarliPinell]

The code looks good. No observations.

[CarliPinell]

Tested on Built environment the process completes succesfully

[CarliPinell]

Unit Tests passed

[CarliPinell]

Tested and approved.

[ryancooley]

I have updated the new SonarQube quality gate. Re-running tests.

[nolanpro]

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

[decisions-sonarqube]

Quality Gate failed

Failed conditions
1 New issue
1 New Maintainability Issues (required ≤ 0)

See analysis details on SonarQube

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[eiresendez]

Hi @sanjacornelius and @ryancooley — SonarQube is reporting S8961 because the new redirect event is not declared in an emits option. However, Screen Builder targets Vue 2 (^2.6.12, currently resolved to 2.7.16), while explicit emits is primarily a Vue 3 convention and is supported in Vue 2.7 only for type-checking, without runtime behavior. This also appears inconsistent with the existing codebase: task.vue has 21 $emit calls covering 10 event names, and the repository has 175 similar findings across 61 files.

Could you advise how I should proceed? It seems S8961 may be incorrectly enabled for this Vue 2 project, so marking this finding as a false positive or disabling the rule for Screen Builder’s quality profile may be more appropriate than adding a partial Vue 3-style emits declaration solely to satisfy the quality gate.

[eiresendez]

In sync with @ryancooley and @sanjacornelius, we will not address this SonarQube finding because Screen Builder currently uses Vue 2, and adding the emits option only here would be inconsistent with the rest of the codebase. The finding will be marked as a false positive.

[nolanpro]

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

[eiresendez]

I reran the failed checks, but these failures are unrelated to the changes in this PR. The same intermittent Cypress/Vite issue has occurred in other Screen Builder PRs, where the app sometimes does not render and tests time out waiting for common UI elements. This CI stability issue should be addressed in a separate ticket outside the scope of this PR, so please disregard these failed checks when reviewing the changes here.

@nolanpro @sanjacornelius