fix(workflow-form): let ui-udf-parameters show the form's renames and hides in its columns, and add a parameter to the card's operator - #8846

What changes were proposed in this PR?

Closes #8763. Part of the Form View feature (#8011); from the #8439 refinements (item 6).

ui-udf-parameters (the Python UDF parameter table) is exposable, but its renderer hides formly's labels and draws fixed column headers (Value / Name / Type), so the author's per-sub-field overrides from the form (#8438) changed nothing a reader saw: formly expresses a rename as the sub-field's label and a hide as hide, and renders both through the field's wrapper, which this widget's cells never go through -- a renamed column kept its old heading, a hidden one kept its heading over an empty cell. Reviewing it turned up more the widget got wrong on a Form View card. The operator property panel is untouched throughout.

• The form publishes what the author decided; the widget asks. New common/formly/sub-field-view.ts: a host that holds per-sub-field decisions publishes them once on the field it hands a widget (props.subFieldView, keyed by sub-field path: { label, shown } -- the author's name, or "" where they kept the one it came with, and whether a reader sees the part at all), and a widget that draws its own chrome asks subFieldsInView / subFieldLabel. Reading the state back out of the rendered rows was not the answer: it is only there once formly has built a row, so a table whose UDF declares nothing yet had nothing to read, and a group's hide is marked on the group while its children are merely not rendered. The Form View fills the map during its override walk (the first node met for a path answers for it, as it does for the controls: the rows of a repeated section share one override), shown for an author always (who keeps a hidden sub-field on screen, faded, to bring it back) and for a reader unless the override hides it; a hide of the attribute group takes both its columns out. A name being typed is written into the very object the field carries, so a header follows the typing without a rebuild; an emptied box deletes the override and the header falls back to the widget's own name. Nothing published -- the panel, where there is no author -- means every part in view under the widget's own name, which is what its fixed headers already say.
• The widget's columns and headers follow it on a card. columns is read live (the form hands the widget its field after the widget's first check) through subFieldsInView, which hands back the same array instance while the answer has not changed so the header's ngFor does not redraw; a header reads subFieldLabel with the fixed label as fallback -- the author's name, else "Type", never the schema's "Attribute Type", which the panel does not show either. All three columns come back while the draft row is open: that row names and types the parameter being added, so it needs them whatever the author hid (Copilot on this PR: a filtered header over its three cells put the name box under the wrong heading).
• A column's label controls live in the header, once (second commit; found on the running instance while authoring). The form's label wrapper decorates every row's sub-fields -- the first row with the name box and the eye, every later row with a static name -- and this widget drew them in its cells under the header that now reads the author's name, so a column's name was drawn three times over (header, first-row box, each later row's static label; and the static one said "Attribute Type" where the header said "Type"). The wrapper gains one prop, labelHosted: a host that draws the label itself sets it, and the wrapper then renders no box, eye or static label, only the control's accessible name (sr-only, tied to the control by for, or the group twin for a repeated field) and the dimmed state. The widget hosts the one name box and eye per column in its header, bound to the first row's props and callbacks (authorName / authorHidden / renameField / setFieldHidden -- the row the form gave the controls to), and for each column it hosts marks every cell of that column, named as the heading reads. The write-through those controls make (the props first, then the form) and the box's and eye's styles have one definition each, on the wrapper (EditableLabelWrapperComponent.rename / setHidden; _editable-label.scss), which the header uses rather than copies. How a later row's own name keeps up with a rename is the form's followersByPath, as before. A renderer with no header of its own (the generic array widget) sets nothing and is untouched; the panel carries no operator mark, so nothing is hosted or marked there.
• The form names the operator on every field it renders (props.operatorID: FIELD_OPERATOR_ID_PROP / fieldOperatorID / renderedInFormView in custom-formly-type.ts), since nothing is highlighted on the form; the same mark tells a shared widget which host it is on, where the two must differ.
• "Add parameter" works on a card as on the panel. It inserts a declaration into an operator's code, and it took that operator from the canvas highlight -- on the form nothing is highlighted, or another step is, so it edited the wrong operator or failed with "code is not available". It now adds to the field's operator on a card and to the highlighted one on the panel. Whether a card offers it (editable) asks the two halves of the canvas's rule separately, because the canvas's flag answers neither one on that page. Write access: the card is not a reader's, which the form marks on the field itself (props.disabled; renderedReadOnly). So a writer's card offers it in and out of edit mode, as every value on the card can be edited, and adding a parameter is adding a row; it followed the canvas's modification flag, which the Form View holds off outside edit mode against structural edits through its page, so a writer could edit every value on the page but not add a parameter to this table without entering edit mode. No run in flight: asked of the execute service, which owns that rule (isExecutionInFlight(), lifted out of the switch that already locks the graph, so the states are listed once). Adding a parameter writes into the UDF's code, and code is what a run must not have rewritten under it. The mark decides rather than the table's own control, which does not answer the question: formly disables the leaf controls under a disabled field, not the array itself, so a reader's table with no parameters yet reads as enabled and would have offered the button. The check also sits in the method, not only on the button. The panel keeps the canvas's rule, the flag, unchanged.
• The declared parameters then reach the operator. The parser announces the UI parameters a UDF's code declares, and the operator property panel's frame writes them onto the operator for the operator it shows, only while it acts as the editor. With the panel closed or on another step nobody wrote them, so a parameter added from a card changed the code but no row appeared. The form writes them when the frame does not: a writer only, not while the step panel shows that very step live, and only for an operator still on the graph; the same value the frame writes. The card showing them is then rebuilt right after the current tick (once every writer has written; held while the reader is typing, and flushing a card's pending write first, as every rebuild is since fix(workflow-form): rebuild the cards on compilation only when it changed something they show #8845): it would otherwise have kept its old rows until the compilation result rebuilt it, half a second and a round trip later, and a value typed into it in that window would have gone back with the old rows, dropping the one just declared.
• A read-only reader's value cells are locked: the Form View marks a reader's field props.disabled, and the widget's own "the value is editable" used to re-enable the control after formly had disabled it.

Any related issues, documentation, discussions?

Closes #8763. Raised by Copilot on #8438; filed from #8439. Rebased on main, which now has #8848 (the widget's lock on the Name and Type cells holding under the panel's wholesale enable(), split out of an earlier revision of this PR) and #8845 (a card's pending write is flushed before every rebuild, which the catch-up rebuild here inherits; an earlier revision listed that as #8844, open then). #8760 (the form's own code editor host) needs the same operator mark and the same write of the declared parameters; whichever lands second drops its copy. Checked under real formly while reviewing: hiding the attribute group itself keeps the rows' names and types in the model (formly resets a hidden field's children only on a hide that happens after the build; the form sets hide at build only, and a reader's card is rebuilt rather than toggled). Table semantics for assistive tech (the header and cells are plain divs, as on the canvas) stay a follow-up. The remaining stale-row window is a collaborator declaring a parameter while this user types in that same card, where the rebuild is held and the card's write-back puts the old list back; closing it means a card writing only its own key into the operator's current value instead of replacing the whole property, which is a change to every property's write-back and belongs in its own PR.

Seen in review, the Form View's own and not changed here: the form's array widget (ArrayTypeComponent) shows its add and remove buttons to a reader too, without a write-back behind them; that goes to a follow-up issue. And on main, renaming or hiding a repeated section's sub-field reaches only its first row at once: followersByPath registers the configs the section's builder returns, which formly clones before rendering, so the rows on screen never hear of the edit until a rebuild shows the saved override on every row. Pre-existing, found while checking the second commit, which hosts the first row's controls and leaves that mechanism as it is; it goes to its own issue.

An earlier revision of this PR let a run through. It described a writer's cards as editable mid-run and read the button as following from that, which holds for the values -- they were always editable here -- but not for this button: the canvas's flag had been hiding it during a run, and dropping the flag dropped that with it. A declaration goes into the UDF's own code, straight into the shared document and not through the graph's lock, and the property panel and the canvas code editor both refuse a code edit while a run is in flight (mengw15). The card now asks for that half on its own; see the rule above.

How was this PR tested?

Unit tests (vitest), added or extended in this PR; every statement, function and branch the PR adds is covered, with the rule for Add parameter pinned once, under real formly, rather than again by hand.

• sub-field-view.spec.ts: a host that publishes nothing leaves every part in view under the widget's own name; a publishing host drops what the author hid and keeps the rest in the widget's order, gives the author's name and the widget's own where the author kept it, and keeps, and names, a part it did not mention; the same array comes back while the answer has not changed and a new one once it has, each host's answer kept apart; a published value that is not a map is ignored.
• The widget's spec: it is on the panel until formly hands it a field and on the form once the field names its operator (and hosts no controls before then); a renamed column shows under its new name and a hidden one is left out, in the header and the cells; the three fixed columns come back while the draft row is open; rows formly builds on demand; a hidden group takes its columns out; the author's name shows while renaming and follows the typing; a table whose UDF declares nothing yet; the panel keeps its fixed headers whatever the sub-fields carry, and the fixed name for a column the author did not rename whatever the schema calls it; the columns are read live, and the same list comes back while nothing changed; a reader's value cells are locked; Add parameter adds to the card's operator on a writer's card, the canvas's flag off, and on the panel to the highlighted one; on a card that is not editable (a reader's, or a writer's while a run is in flight) the method adds nothing, whoever calls, and the draft stays open; on the panel nothing is added while modification is off. Second commit: the header hosts one name box and one eye per column, seeded from the first row, and every cell of every row is marked and named as the heading reads; typing in the header renames through that column's first-row callback and the box follows, the other columns' callbacks untouched; the eye hides through that column's callback, the column fades and stays in view and the eye says so, a second click un-hides; no eye for a column the form marked not hideable, and the mark survives a re-populate; a reader's card and the panel keep a plain text header with no cell marked.
• The widget's formly spec (the table stood up under FormlyModule.forRoot, a builder row template as formly-jsonschema produces, nz-input cells as in the app, so the rows are formly's own and a reader's lock is the one formly applied): a writer's Form View card offers Add parameter without the canvas's flag and a reader's card, its field disabled, does not; the same with no parameters yet, where formly leaves the empty array control enabled; a run in flight takes the button off a writer's card and leaves the values editable.
• The wrapper's spec: with labelHosted, the row that carries the controls draws no box or eye but is still named and still fades when hidden; a later row draws no static name, only the sr-only one tied to the control by for, or the group twin with its -label id for a repeated field; rename / setHidden write the props and then call the form, and tolerate a reader mount that has neither callback.
• The form's spec: every field carries its operator; the declared UI parameters are written for a writer when the step panel is not editing that step, left to the frame while it shows the step live (the card still rebuilt), written when it shows the step read-only, and not written for a reader or a vanished operator; the cards are rebuilt after the current tick when one shows that step's parameters, through buildForm (the old cards cut off, the card holding the declared rows), held while the reader is typing and run once the focus leaves, and left alone when none shows that step's parameters or the one that does is another step's; a sub-field formly built without props is renamed; a name being typed lands in the published view on the field itself, a rename for a path the view does not carry is ignored, an author is told a hidden sub-field is still in view and a reader that it is not, and no name is published for a sub-field the author did not rename.
• The execute service's spec pins isExecutionInFlight against the graph lock, state by state; custom-formly-type's spec pins fieldOperatorID, renderedInFormView and renderedReadOnly.

eslint, prettier and the production (AOT) build pass; the full frontend suite passes.

Checked on a flag-on instance (main-demo; a Python source feeding a Python UDF whose code declares two UI parameters, uiParameters exposed with the Name column renamed "Parameter" and the Type column hidden), the canvas and the form open side by side, main against this branch. On main the card shows Value / Name / Type, the overrides ignored. With this PR the card shows Value / Parameter, the Type column gone, while the canvas panel still shows Value / Name / Type. A writer's card offers Add parameter in and out of edit mode (on main it appeared only in edit mode, while any list's rows could be added either way); adding cutoff (double) inserts self.UiParameter(name="cutoff", type=AttributeType.DOUBLE) into that UDF's code, and the new row appears on the card and in the canvas tab's panel within a few seconds, and is there after a reload. In edit mode, the first commit alone drew 3 header titles, 3 name boxes and 3 eyes in the first row and 3 static labels in the second; with the second, the header holds the 3 name boxes and 3 eyes and the cells hold none, and a hidden column's header fades with its cells.

The canvas panel shows the same three columns, the same values and the same behaviour as on main, side by side on both instances.

Video

Before

After

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