yangzhang75 commented on code in PR #8846:
URL: https://github.com/apache/texera/pull/8846#discussion_r4309281488
##########
frontend/src/app/workspace/component/ui-udf-parameters/ui-udf-parameters.component.ts:
##########
@@ -79,13 +96,45 @@ export class UiUdfParametersComponent extends
FieldArrayType<FormlyFieldConfig>
super();
}
- get workflowModificationEnabled(): boolean {
- return this.workflowActionService.checkWorkflowModificationEnabled();
+ /** Whether this is a Form View card rather than the operator property
panel; see columnsInView. */
+ get onFormView(): boolean {
+ return renderedInFormView(this.field ?? {});
+ }
+
+ /**
+ * Whether the table takes a new parameter here. On the operator property
panel that is the
+ * canvas's rule, as it always was: the workflow may be modified (write
access, no run in flight).
+ * On a Form View card it is the card's own rule: the card is not a
reader's, which the form marks
+ * on the field itself (props.disabled, its one lock on a card; see
renderedReadOnly). A writer's
+ * card is editable in and out of edit mode, as every value on it is (adding
a parameter is adding
+ * a row). The canvas's flag is not the card's rule: the Form View holds it
off outside edit mode,
+ * against structural edits through its page, and that hid the button on a
card whose values could
+ * still be edited. 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 (a reader's table
with rows reads as
+ * disabled only because every row's controls are).
+ */
+ get editable(): boolean {
+ if (!this.onFormView) {
+ return this.workflowActionService.checkWorkflowModificationEnabled();
+ }
+ return !renderedReadOnly(this.field);
Review Comment:
Both right, and the second one I had read as the page's existing behaviour
rather than something this PR changed. `addParameter` writes straight into the
shared Y text, so it never passed through the modification lock at all -- the
flag was the only thing keeping the button off a running workflow.
The card now asks the two halves separately: the form's reader mark for
write access, and the execute service for a run in flight
(`isExecutionInFlight()`, lifted out of the switch that already locks the
graph, so the states stay listed once). The values on a card stay editable
through a run as before; only the button goes.
Tests: the button drops while a run is in flight and comes back on that same
card once the run ends, on both the plain spec and the real-formly one, and the
predicate is pinned state by state against the lock it came from. Pushed as
11d021416; the PR text no longer reads the mid-run button as existing behaviour.
--
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]
