fix(frontend): hold the Python UDF parameter table's Name and Type cells locked when the panel enables its form group - #8848

What changes were proposed in this PR?

Closes #8847. The Python UDF operator's "UI parameters" table (#5043) infers each parameter's name and type from the self.UiParameter(...) declarations in the operator's code, so the widget disables those two columns' controls as it builds each row: a name typed into the table does not reach the code, and the parameter's value then never reaches it either (checked on main: the table's name changes, the code's does not).

The lock does not survive on the operator property panel. setInteractivity(true) enables the whole form group -- one task after every render, and again whenever the workflow becomes modifiable, for instance when a run ends -- and formly mirrors a control's state back into props.disabled, so the one-time disable is simply undone. Which state a given panel opening shows depends on which of the two ran last: measured on main, the cells were editable on 4 of 5 openings, and always after a run. The Form View, which never enables a group wholesale, has always shown them locked, so the two views disagreed as well.

The widget now holds its own lock. On each cell it locks it registers Angular's disabled-change hook of the control (registerOnDisabledChange, the same hook formly's mirror and the input's value accessor use): when a host enables the control, the hook disables it again in the microtask after that enable, and announces the status change as the enable did. Both details matter and were found on a running instance:

• deferred to the microtask, because the input's value accessor is one more hook on the same control, registered after this one when the cell renders; disabling from inside the enable's own round of hooks left the accessor having been told "enabled" last, so the box was editable over a locked control;
• announced rather than silent (disable(), not disable({emitEvent: false})), because ng-zorro's nz-input paints its disabled attribute from the control's status changes; a silent disable left it painting the box editable again at the next change detection.

A cell the widget configures editable -- the Value column, or any cell once reconfigured -- is released from the hold, so whether it is editable stays the host's call: a read-only panel still locks everything, and a host that disables the whole field still reaches the Value cell. The frame is untouched: two other approaches were tried first and dropped, re-disabling from the frame after enable() (formly's mirror has already set props.disabled to false by then) and a formly expression on props.disabled (formly re-evaluates expressions on model changes only, and registers them at populate, so enable() never triggers one).

Any related issues, documentation, discussions?

Closes #8847. Split out of #8846 (the same table under the Form View's renames and hides), which is based on main and does not touch this; the two are independent and can land in either order. The table's fixed 250px columns clip Name and Type at the panel's default 260px width, which is why the cells have to be brought into view to see any of this; that is a separate layout bug, filed separately.

How was this PR tested?

Unit tests (vitest). The widget's spec: a locked cell's control is held locked when a host enables it, in the microtask after the enable and announcing the status change, while the Value cell is left to the host; a cell configured editable again is released from the hold; a cell the host disables again before the microtask is left alone; a control that is not a FormControl gets no hook, and a control is hooked once however often it is configured. A second spec stands the table up under real formly (FormlyModule.forRoot, a form, the builder row template formly-jsonschema produces, nz-input cells as in the app): the rows build with Name and Type locked and Value editable; a wholesale form.enable(), as the panel does, leaves Name and Type locked, read from the inputs' disabled state and not only from the controls'; a read-only form.disable() locks everything and a later enable() gives only the Value cell back. Each guard was deletion-checked 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 local instance (a Python source feeding a Python UDF whose code declares two UI parameters), the panel widened so the columns are in view. On main the cells are editable on most openings (4 of 5) and after every run; with this PR they stayed locked on every opening and through a forced setInteractivity(true) followed by real change-detection passes, read from the DOM as well as from the controls. The Value cell follows the host in both.

Video

Before

After

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