yangzhang75 opened a new issue, #8847:
URL: https://github.com/apache/texera/issues/8847
### What happened?
The Python UDF operator's "UI parameters" table infers each parameter's name
and type from the `self.UiParameter(...)` declarations in the operator's code,
so the Name and Type columns are meant to be read-only: the widget disables
their controls as it builds each row (added in #5043). A name typed into the
table does not change the code, and the parameter's value then no longer
reaches the UDF.
That lock does not hold on the operator property panel. The panel enables
its whole form group whenever it turns interactive (`setInteractivity(true)` ->
`formlyFormGroup.enable()`), which happens one task after every render and
again whenever the workflow becomes modifiable, for instance when a run
finishes. The enable reaches the cells the widget had disabled, and formly
mirrors the new state back into `props.disabled`, so nothing puts the lock
back. Whether a given panel opening shows the cells locked or editable depends
on which of the two ran last, so the panel disagrees with itself between
openings, and with the Form View, which never enables a group wholesale and
therefore always shows them locked.
Measured on main (2082021a8), opening the panel for the same Python UDF five
times with the panel widened so the two columns are in view: locked on 1
opening, editable on 4. After a run finishes they are editable every time.
Expected: the Name and Type cells stay read-only under the panel, as the
widget intends and as the same table already behaves on the Form View.
Note for anyone trying to see this: at the panel's default width (260px) the
Name and Type columns are not visible at all, because the table's grid is
`250px 250px 1fr`; the panel has to be widened to about 600px first. That
clipping is a separate layout bug and is reported on its own.
### How to reproduce?
1. Add a Python UDF whose code declares a UI parameter, for example
`self.UiParameter(name="threshold", type=AttributeType.DOUBLE).value`.
2. Click the operator to open the property panel, and drag it wider (about
600px) so the Name and Type columns of the "Parameters" table come into view.
3. Reload the page and reopen the panel a few times: on most openings the
Name and Type cells are white and editable instead of greyed out.
4. Alternatively, run the workflow and look at the table once the run
finishes: the two cells are editable every time.
5. Type a different name into the Name cell. The operator's code is
unchanged, and the parameter's value no longer reaches the UDF.
### Version/Branch
1.4.0-incubating-SNAPSHOT (main)
### Commit Hash (Optional)
2082021a8073c26bc38aeac7d654bdc661d4ff87
### What browsers are you seeing the problem on?
_No response_
### Relevant log output
```shell
Five consecutive panel openings on main (2082021a8), same workflow, same
Python UDF,
panel widened to 820px, read from the DOM (input.disabled / nz-select's
disabled class):
load 1: headers=[Value|Name|Type] Value=white Name=white Type=white
load 2: headers=[Value|Name|Type] Value=white Name=grey Type=grey
load 3: headers=[Value|Name|Type] Value=white Name=white Type=white
load 4: headers=[Value|Name|Type] Value=white Name=white Type=white
load 5: headers=[Value|Name|Type] Value=white Name=white Type=white
The widget marks both columns disabled while it builds each row
(ui-udf-parameters.component.ts, fieldColumns + applyDisabledState), and the
panel's
operator-property-edit-frame.component.ts enables the whole group afterwards:
setTimeout(() => { this.setInteractivity(this.interactive); ... }, 0) //
after every render
getWorkflowModificationEnabledStream().subscribe(canModify =>
this.setInteractivity(canModify))
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
