Previously the fields / classes are named with `placeholder`. However,
the actual purpose is to use as default values. This commit addresses
this problem by correcting names for relevant fields / classes.
- FormInputPlaceholder
- FormInput.placeholder
- HumanInputRequiredResponse.resolved_placeholder_values
- HumanInputFormDefinition.resolved_placeholder_values
- FormCreateParams.resolved_placeholder_values
- HumanInputRequired.resolved_placeholder_values
- The `resolved_placeholder_values` argument of _create_human_input_delivery_test_form
- The `resolved_placeholder_values` inside _jsonify_form_definition
The HumanInput node will pause the execution of workflow if execution, while WorkflowTool works in a blocking manner. (Receiving arguments and returning results once finished). The two mode are inherently incompatible.
The goal of this change is to forbid workflows containing HumanInput node being published as WorkflowTool.
Please check the current implementation and propose a solution.
Avoid drain_queue and race condition caused by drain queue.
The current approach starts a background thread and buffer in-fly events
to an intermediate queue.Queue. The queue is bound and will drop events
once it's full.
For users with sandbox plan, the email delivery is not available.
The backend logic should check the plan of the current tenant while sending email. The core check logic should be abstracted in FeatureService. The `HumanInput` node configuration should not validate the presence of `EmailDelivery`.
For enterprise deployment, the email delivery is not limited.
The EmailDeliveryConfig in api/core/workflow/nodes/human\_input/entities.py has a field `debug_mode`. When this field is set to `True` in `node_data`, the test run (InvokeFrom.DEBUGGER) and the delivery test should only sent test emails to the current user, instead of sending to the specified recipients.
Please implement this logic, write correspond test cases to ensure that the logic works as expected.
This ensures that `HumanInputForm` could be associated to a specific
application without relying on `WorkflowRun`, providing us a smoother
migration path if we want to implement test form.
