[8547] Workflow states options should only display valid options

[jvega190]

craftercms/craftercms#8547

Summary by CodeRabbit

• New Features

  • Staging-related controls in workflow state dialogs are now conditionally visible based on configuration, simplifying the UI when staging isn't available.
  • Dialogs accept a flag to control staging visibility, enabling downstream components to toggle staging behavior.

• Bug Fixes / Improvements

  • Improved error handling when fetching publishing targets to surface clearer error dialogs.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

---

Walkthrough

Adds a new public prop hasStaging: boolean to the SetItemStateDialog API, threads it through SetItemStateDialog -> SetItemStateDialogContainer -> WorkflowStateManagement, and conditions rendering of staging-related controls on that prop. Also updates error handling import usage in WorkflowStateManagement.

Changes

Cohort / File(s)	Summary
Dialog Interface Update ui/app/src/components/SetWorkflowStateDialog/SetItemStateDialog.tsx	Added hasStaging: boolean to SetItemStateDialogProps (public API change).
Conditional Rendering Implementation ui/app/src/components/SetWorkflowStateDialog/SetItemStateDialogContainer.tsx	Destructures hasStaging and wraps staging UI controls with {hasStaging && ...} to conditionally render them; preserves existing state update logic.
Prop Threading & Error Handling ui/app/src/components/WorkflowStateManagement/WorkflowStateManagement.tsx	Passes hasStaging into SetItemStateDialog; imports and uses extractErrorPayload when dispatching pushErrorDialog on publishing targets fetch error.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Possibly related PRs

• [8438] Publish On Demand dialog does not display API 4xx error responses #4773 — Also updates error handling to use extractErrorPayload and dispatches pushErrorDialog with the extracted payload.

Suggested reviewers

• rart
• russdanner

🚥 Pre-merge checks | ✅ 1 | ❌ 2

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.
Description check	❓ Inconclusive	The PR description only contains a link to the issue without explaining what changes were made or why, making it vague and insufficient for code review purposes.	Expand the description to explain the specific changes made (e.g., adding hasStaging prop, conditional rendering) and the rationale behind them.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly references issue [8547] and accurately describes the main change: restricting workflow state options to display only valid ones.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

ui/app/src/components/WorkflowStateManagement/WorkflowStateManagement.tsx (1)

154-163: ⚠️ Potential issue | 🟡 Minor

Missing error handler in fetchPublishingTargets subscription causes silent failure.

If fetchPublishingTargets fails (network error, 5xx, etc.), hasStaging silently stays false. On sites with staging actually configured, the staging workflow controls in the dialog and the "staged" filter checkbox will permanently be absent for that page load — a silent UX regression with no indication to the user.

🛡️ Suggested fix: add an error handler

 useMount(() => {
   const sub = fetchPublishingTargets(siteId).subscribe({
     next({ publishingTargets: targets }) {
       setHasStaging(targets.some((target) => target.name === 'staging'));
-    }
+    },
+    error() {
+      // Fail open: leave hasStaging as false; staging controls remain hidden.
+      // Optionally dispatch an error notification here if desired.
+    }
   });
   return () => {
     sub.unsubscribe();
   };
 });

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@ui/app/src/components/WorkflowStateManagement/WorkflowStateManagement.tsx`
around lines 154 - 163, The subscription to fetchPublishingTargets inside
useMount lacks an error handler so failures are silent; update the subscribe
call in WorkflowStateManagement (the useMount block that calls
fetchPublishingTargets(siteId).subscribe) to provide an error callback that logs
the error (e.g., console.error or the app logger) and explicitly sets
setHasStaging(false) or otherwise maintains a safe default state, ensuring the
returned teardown still unsubscribes the subscription.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@ui/app/src/components/WorkflowStateManagement/WorkflowStateManagement.tsx`:
- Around line 154-163: The subscription to fetchPublishingTargets inside
useMount lacks an error handler so failures are silent; update the subscribe
call in WorkflowStateManagement (the useMount block that calls
fetchPublishingTargets(siteId).subscribe) to provide an error callback that logs
the error (e.g., console.error or the app logger) and explicitly sets
setHasStaging(false) or otherwise maintains a safe default state, ensuring the
returned teardown still unsubscribes the subscription.

[jvega190]

Outside diff range comments addressed