feat(workflow-form): render nested and array sub-field inputs - #8438

…or's instruction (apache#8440)

### What changes were proposed in this PR?

Closes apache#8023. Part of the Form View stack (parent issue apache#8011), stacked
on apache#8438 (PR11) and apache#8437 (PR10).

The Form View can now render inputs and write them back. This PR makes
it usable end to end: it runs the workflow, and shows the author's
instruction above the inputs.

- **Run.** A Run button that shares the operator canvas's disable
conditions (an invalid or empty workflow, a unit still connecting, or no
unit chosen each disable it and say why), but deliberately simplifies
the execution states a reader needs down to Run and Stop, with no
pause/resume. The unit is chosen in the embedded computing-unit
selector. Running is the same execution call the canvas makes, so empty
or invalid inputs surface as a real engine error rather than a
client-side gate; a run clock counts off the engine's own event, and a
failed run collapses an opaque trace to one plain sentence (a required
input left empty reads as "please fill in the required fields").
- **Instruction.** The author's optional instruction renders above the
inputs as a collapsible, read-only markdown card, shown only when there
is text. It is bound through `[innerHTML]` with Angular's default
sanitizer, so author markdown cannot inject script. Editing it is part
of the authoring PR.

Showing the chosen results is the next PR (apache#8024).

### Any related issues, documentation, discussions?

Closes apache#8023. Part of the Form View feature (parent issue apache#8011).

### How was this PR tested?

Unit tests (vitest). Direct-construction tests cover every run-button
precedence branch, `onRun` (kill while running, no-op when disabled,
else execute and clear the error), the five failed-run message paths,
the run clock and its tick, and the status/validation/connection
subscriptions; the instruction is covered for the markdown render,
`hasInstruction`, and the toggle. TestBed template tests stand up the
instruction card, the run bar, and the run-button click binding. 100%
statement and function coverage on the changed source (the remaining
uncovered branches are the pre-existing defensive `??`/`||` fallbacks).
`ng test` (99 tests), `ng build gui`, eslint and prettier all pass, in
both the single-user and collaboration paths.

#### Screenshot

The run bar (Run button + computing-unit selector + clock) and the
author's instruction card above the inputs.
<img width="1323" height="488" alt="Screenshot 2026-09-06 at 12 07
57 PM"
src="https://github.com/user-attachments/assets/024d3bf5-be01-4449-8a0f-7538961cb83a"
/>



### Was this PR authored or co-authored using generative AI tooling?

Yes. Co-authored with Claude (Anthropic), reviewed line by line by the
author before submission.

Co-authored-by: Claude Opus 4.8 <[email protected]>
Co-authored-by: Meng Wang <[email protected]>

…m, with the drag (apache#8843)

### What changes were proposed in this PR?

Closes apache#8761. Part of the Form View feature (apache#8011); from the apache#8439
refinements (item 2).

An exposed drag-reorder property -- Projection's columns, formly type
`repeat-section-dnd` -- fell back to a plain repeated list in the Form
View (`CANVAS_ONLY_FORMLY_TYPES`): a reader could edit the rows but not
reorder them, which is what the widget is for. The fallback assumed the
drag had nowhere to attach on a form; the widget carries its own CDK
drop list, and the row template it needs comes from the operator's own
schema (the per-instance one, with the upstream columns), which the form
already builds.

- `repeat-section-dnd` leaves `CANVAS_ONLY_FORMLY_TYPES`; the set now
holds the code editor only. On the form the widget renders exactly as on
the operator property panel, drag handle and all, and a drop reaches the
operator through the card's `valueChanges` write-back; the panel's
`reorder` callback stays optional (the widget calls it only when the
host provides one), so the same widget serves both hosts without a
form-specific branch. Nothing is added to the widget's UI.
- Two defects in the widget itself, found while reviewing this and in
reach of the form for the first time: every button now has
`type="button"` -- `nz-button` sets no type, so inside a form (the
card's, the panel's) a typeless button is the submit button and Enter in
a row's input clicked it, removing the first row (the fallback the form
used before had typed buttons; the panel has had this since the widget
exists); and the rows are re-keyed to their positions after a drop, as
formly's own `remove()` does -- formly keys rows by position and writes
a cell's value into the model by that key path, so a value typed into a
moved row landed on the row that used to be there (the same after a drag
on the panel, until the operator was re-selected).

### Any related issues, documentation, discussions?

Closes apache#8761. Raised by @mengw15 on apache#8436; filed from apache#8439. Builds on
the sub-field walk from apache#8438. apache#8760 (proper) also shrinks
`CANVAS_ONLY_FORMLY_TYPES`; whichever lands second deletes the
then-empty set. Known limitation, not this PR's code: the Form View
rebuilds every card on every compilation, including the one a card's own
write triggers, so on the form a drop's write redraws the rows about a
second later, and a second drop made in the last 150 ms before that
redraw is undone. The canvas panel has no such rebuild. Filed as apache#8844
and fixed in apache#8845 (the form rebuilds only when the schema, the set of
inputs or a value it does not hold changed); this PR is independent of
it. Other follow-ups: a card's model is seeded once and never re-seeded
from a co-editor's edit of the same property, so a reorder writes the
whole array back over such an edit (pre-existing for every array/object
property; a reorder is one more trigger); the HuggingFace and codearea
widgets also carry typeless buttons.

### How was this PR tested?

Unit tests (vitest). The widget's spec: a drop reorders the model, the
field configs and the form controls and then tells the parent; a section
without a reorder callback still reorders; a keyless row's children are
re-keyed to the row's new position, as formly's own remove() does; every
button carries `type="button"`; the existing rendering tests (one row
per entry, draggable rows, remove, add, disabled section) still hold. A
second spec stands the widget up under real formly
(`FormlyModule.forRoot`, a form, a model): a drop changes the model and
the cells and keeps the rows' keys in step with their positions, and a
value typed into a moved row lands on that row's entry. The form's spec:
Projection's `attributes` renders through `repeat-section-dnd`.
`custom-formly-type`'s spec pins the set. Each guard was
deletion-checked (the re-keying dropped; the callback called unguarded;
the remove button typeless; the type back in the canvas-only set) and
turned a named test red. eslint, prettier and the production (AOT) build
pass; the full frontend suite passes; every statement, function and
branch this PR adds is covered.

Checked on a flag-on instance (main-demo; a Python source with four
columns feeding a Projection whose `attributes` is exposed), with the
canvas and the form open side by side: on main the card is a plain list
(no handle); with this PR the card shows the drag handles, as the panel
does. Dragging the last row to the top: the operator's order follows in
the canvas tab's panel within a second and in the saved workflow. An
alias typed into the moved row lands on that column, not its neighbour;
Enter in an alias input removes no row; a reload shows the same order. A
drop made on the canvas panel reaches the form within a second.

#### Video

**Before**


https://github.com/user-attachments/assets/5a78f6f5-3b27-4b93-955e-bb15b40fd854



**After**


https://github.com/user-attachments/assets/b84c79fa-a0a4-4bbc-b734-e75147bdf0d6




### Was this PR authored or co-authored using generative AI tooling?

Yes. Generated-by: Claude Code (Claude Fable 5.1, Anthropic).
Co-authored with Claude, reviewed line by line by the author before
submission.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Fable 5.1 <[email protected]>
Co-authored-by: Meng Wang <[email protected]>

…not only the pointer (apache#9016)

### What changes were proposed in this PR?

Closes apache#8943. Part of the Form View feature (apache#8011); from the apache#8439
refinements (item 5).

A read-only input card -- what a viewer without write access sees -- is
locked with `pointer-events: none`. That is hit testing only. The bound
formly controls are disabled through `props.disabled`, but the controls
a custom widget draws of its own are not: the HuggingFace audio and
image uploaders each render a plain file input that nothing disables. A
reader could Tab into one inside a locked card, open it with Enter and
choose a file.

For the audio input that is a real write. The widget POSTs the chosen
file to `/api/huggingface/upload-audio`, which authorises any signed-in
user and never asks who may write this workflow, so the file lands in
the server's temp store. Checked on a workflow shared read-only: two
presses of Tab reach the uploader inside the locked card, Enter opens
the file dialog, and the POST comes back 200 with the stored path. The
image uploader is client-side, so there the reader only makes the card
display a picture of their choosing -- a read-only card wires no
write-back and a reader's save is refused, so the operator keeps the
author's value and a run still runs it.

The card now also keeps the keyboard out, through a small directive on
it (`texeraReadOnlyCard`, applied as `[texeraReadOnlyCard]="!canEdit"`
beside the existing `read-only` class):

- Every focusable descendant is taken out of the tab order
(`tabindex="-1"`, its own value remembered) and marked
`aria-disabled="true"`, so there is nothing for Tab to reach and
assistive tech says why rather than going quiet.
- Every control the browser will refuse outright -- button, input,
select, textarea -- is also disabled natively, its previous state
remembered. Out of the tab order is not out of reach: `tabindex="-1"`
ends only sequential navigation and `aria-disabled` only announces, so a
reader's assistive tech could still focus a widget's file input and
activate it, which for the audio one posts the file (Copilot).
- A card that becomes editable gets its controls back, each with the
tabindex and the disabled state it had, and only those this directive
took.
- A control that leaves the card is let go of on the next pass: a widget
redraws its own controls while the card lives on, so a set that only
grew held every detached node for as long as the reader stayed on the
page (Copilot).
- Widgets render their own controls after the card is built and redraw
them as they go, so the locking is re-applied on every change inside the
card: a control added, one whose own tabindex is written back (ng-zorro
writes one when it enables a control), and one a widget enables again
(the audio uploader's `[disabled]="isUploading"`). The observer runs
outside Angular and sets only what is not already set, so one pass
settles it.

`inert` is what the step panel uses for its read-only mount, and the
issue suggested following it; this does not, deliberately. `inert` also
removes the subtree from the accessibility tree, and a reader's card
exists to be read -- the values are what a reader runs the workflow with
-- so that would trade this bug for a worse one. Disabled controls stay
in the accessibility tree and keep being announced. The directive's doc
comment says so, next to the code.

Nothing else changes: the pointer lock, the styles, the card's content
and the author's editing path are untouched, and the directive does
nothing at all while a card is editable.

### Any related issues, documentation, discussions?

Closes apache#8943, which re-files apache#8758 (closed). Part of apache#8439 (item 5) and
the Form View feature apache#8011. Raised by Copilot on apache#8437, apache#8438 and
apache#8440.

Three neighbouring things are deliberately left alone. The widgets' own
controls still do not consult the field's disabled state in their own
handlers -- fixing that is per-widget work (the HuggingFace uploaders,
the dataset picker, the resource value selector), and the card-level
lock covers every widget at once, including ones added later. The upload
endpoint itself authorises on being signed in and nothing else
(`@RolesAllowed("REGULAR","ADMIN")`, no workflow-access check), so it
would still accept a file posted by hand; closing the UI route does not
close that one, and it is worth its own issue. And the step panel's
`inert` mount has the same accessibility-tree problem described above;
changing it is not this issue's scope, and it is worth its own look.

### How was this PR tested?

Unit tests (vitest). The directive's own spec, on a host shaped like a
card (a bound input, a widget's Browse button, a link, a span, a control
with its own `tabindex`): every focusable control in a read-only card is
out of the tab order; each is marked `aria-disabled` while the card is
not inert and its text is still there; an editable card is left alone,
keeping a control's own `tabindex="3"`; a card that becomes editable
gets that `3` back, the untouched control gets no `tabindex`, and the
`aria-disabled` marks go; a control a widget adds after the card was
built is locked; a control whose widget writes its `tabindex` back, or
enables again, is locked again; a click on a locked control dispatches
no activation and the controls report disabled (jsdom does not model a
disabled control refusing focus, so that half is asserted through the
property the browser acts on); the disabled state is given back on
unlock; five rounds of a control being added and removed leave the
tracked set where it started, rather than holding the detached nodes;
the observer is disconnected when the card goes away. The page's
rendered spec wires it through the real template: a read-only viewer's
card, with a button appended the way a widget renders one, has it out of
the tab order and marked, and the card is not inert.

By hand, on two dev builds of the same base commit, one with this change
and one without, signed in as a second account the workflow is shared
read-only with. Before: from the view toggle, two presses of Tab land on
the uploader inside the locked card, Enter opens the file dialog, and
choosing a file POSTs it (200). After: the same two presses land on Run,
the card is skipped, and no request goes out. The mouse reaches nothing
in either build, and the stored workflow is unchanged in both.

Each guard was deletion-checked and turned a named test red (the
directive not applied; the tabindex write; the aria-disabled write; the
native disable; the editable check; the unlock; the original-tabindex
restore; the original-disabled restore; the release of what has left the
card; the childList and both attribute halves of the observer; the
disconnect). eslint, prettier and the production (AOT) build pass; every
statement, function and branch this PR adds is covered, and the full
frontend suite passes.

#### Video

**Before**



https://github.com/user-attachments/assets/cd1b58ff-6cc4-4958-ad78-dd00bb86f14e



**After**


https://github.com/user-attachments/assets/8f524126-d370-48f3-bc70-68497791cf5f




### Was this PR authored or co-authored using generative AI tooling?

Yes. Generated-by: Claude Code (Anthropic). Co-authored with Claude,
reviewed line by line by the author before submission.

🤖 Generated with [Claude Code](https://claude.com/claude-code)