Feature/form sticky buttons

[jeanpxc]

Summary

Changed the submit, reset and delete button to be in a sticky footer instead of being at the bottom

Checklist

• I have read and agree to the CLA.md (CLA Assistant will check/sign on the PR)
• I confirm my contribution is licensed under Apache-2.0 (LICENSE)

[msander]

Three things to address (the first one breaks the build, so flagging even though this is still a draft):

1. Build error — reloadTask/backToList were added as required props to SingleTaskProps, but the router doesn't pass them and the component never reads them; revert the interface change (inline comment).
2. Delete dialog — doesn't close on confirm and allows double-dispatch of the delete request (inline comment).
3. Line breaks — the \n\n in the new dialog text collapses when rendered; use whitespace-pre-line (inline comment).

The sticky footer itself and consolidating the delete action next to submit/reset look good.

---

Generated by Claude Code

[msander]

These two new required props break the build — and they're never used

reloadTask and backToList were added as required props to SingleTaskProps, but the two places that render this component don't pass them (initRouter.tsx:208 and :220 still render <SingleTask state={...} />), so TypeScript fails with "missing required properties".

They're also not needed: this component still defines both callbacks inline further down and passes them to SingleTaskHeader (which is where the props of the same name actually live). Nothing in SingleTask reads props.reloadTask or props.backToList.

Fix: revert the interface change —

 interface SingleTaskProps {
   state: WorkflowState;
-  reloadTask: () => void;
-  backToList: () => void;
 }

---

Generated by Claude Code

[msander]

Delete dialog never closes, and the button isn't guarded against double-clicks

Confirming the delete only dispatches the request — the dialog stays open until the response handling in SingleTaskHeader eventually navigates away. If the request fails, the dialog stays open forever with no feedback. And since the button is disabled={false} and isLoading={false} is hard-coded on the WeAlertDialog, a second click dispatches the delete twice.

The old implementation in SingleTaskHeader closed the dialog immediately after dispatching. Suggest wiring in the existing loading state:

const deleteWorkflowLoadState = useSelectUiLoading(WeDataKey.DELETE_WORKFLOW, 'POST');
// ...
<WeAlertDialog
  isDialogOpen={deleteDialogeOpen}
  setDialogOpen={setDeleteDialogeOpen}
  isLoading={deleteWorkflowLoadState}
  ...
  <Button
    disabled={deleteWorkflowLoadState}
    design={ButtonDesign.Negative}
    onClick={() => {
      handleDeleteWorkflow(task?.id);
      setDeleteDialogeOpen(false);
    }}>

(Closing immediately matches the previous behavior; alternatively keep it open while deleteWorkflowLoadState is true and close on completion — but then a failure path must close it too.)

---

Generated by Claude Code

[msander]

The \n\n in the dialog text won't render as a paragraph break

The new taskContent.deleteDialogText uses \n\n to separate the two sentences, but this <Text> renders with normal HTML whitespace handling, so the newlines collapse into a single space and the text shows as one run-on line. (The old version used <br/><br/> via dangerouslySetInnerHTML, which is why it worked before.)

Simplest fix — preserve the line breaks with CSS:

<Text className="whitespace-pre-line">{t('taskContent.deleteDialogText')}</Text>

---

Generated by Claude Code

[jeanpxc]

The Message gets rendered with paragrapgh breaks.