pub struct PendingUserTask {Show 24 fields
pub instance_id: Uuid,
pub workspace_id: String,
pub element_id: String,
pub token_id: Uuid,
pub name: Option<Option<String>>,
pub bpmn_flow_path: Option<Option<String>>,
pub bpmn_version: Option<Option<i64>>,
pub instance_created_at: String,
pub instance_created_by: String,
pub parked_at: Option<Option<String>>,
pub assignee: Option<Option<String>>,
pub owner: Option<Option<String>>,
pub candidate_users: Option<Vec<String>>,
pub candidate_groups: Option<Vec<String>>,
pub assignment_unresolved: Option<bool>,
pub unresolved_assignments: Option<Vec<BpmnUnresolvedAssignment>>,
pub identity_resolved_at: Option<Option<String>>,
pub claimed_by: Option<Option<String>>,
pub claimed_at: Option<Option<String>>,
pub due_date: Option<Option<String>>,
pub priority: Option<Option<String>>,
pub form_key: Option<Option<String>>,
pub form_fields: Option<Vec<BpmnUserTaskFormField>>,
pub form_validation_disabled: Option<bool>,
}Expand description
PendingUserTask : One <userTask> parked awaiting a human, with the process context needed to act on it (#1104). Every field is read off the persisted process status, the compiled user-task model, or the human_task_claim ledger added by #1123.
Fields§
§instance_id: Uuidthe process instance – the id path segment of the completion operation
workspace_id: String§element_id: Stringthe <userTask> element id – the user_task_id path segment of the completion operation
token_id: UuidThe parked token – the park itself, and what a claim is taken on (#1123). A multi-instance or parallel-branch task parks several tokens at one element, each with its own resolved identity and its own claim, so (instance_id, element_id) does not identify one of them. Pass this as token_id to the claim and release operations when an element holds more than one park.
name: Option<Option<String>><userTask name=\"...\">, the label an author wrote for a human
bpmn_flow_path: Option<Option<String>>§bpmn_version: Option<Option<i64>>§instance_created_at: String§instance_created_by: String§parked_at: Option<Option<String>>When the token arrived at this element, from the engine’s own bounded history. Null for a park older than the retained history.
assignee: Option<Option<String>>flowable:assignee / <humanPerformer> – the name the engine resolved at park time when the assignment was written as an expression, the declared literal otherwise (#1123).
owner: Option<Option<String>>flowable:owner, same rule as assignee
candidate_users: Option<Vec<String>>§candidate_groups: Option<Vec<String>>§assignment_unresolved: Option<bool>The task declares an assignment that could not be turned into a name – an expression the engine’s park-time resolution refused, or a task whose token parked before #1123 shipped. The task is still listed (hiding it would make it unreachable, which is the defect #1104 is about) but a client must not present it as unassigned. An expression the engine did resolve is not flagged: the identity fields above carry the answer.
unresolved_assignments: Option<Vec<BpmnUnresolvedAssignment>>Each refused expression with the reason it could not be read, so a client can say why rather than only that. Empty when there is nothing to refuse, and for a token parked before #1123 shipped (which carries no resolution record at all).
identity_resolved_at: Option<Option<String>>When the engine decided this task’s identity. Present exactly when a park-time resolution record exists; absent means the identity was read from the static model, which for a literal assignment is the same answer arrived at a different way.
claimed_by: Option<Option<String>>Who has taken responsibility for this park (#1123). Absent means unclaimed, which is the ordinary state – claiming is optional and an unclaimed task is completable by anyone in its audience. A claimed task is still listed for everyone in its audience, so they can see it is taken; only its holder and admins may complete it.
claimed_at: Option<Option<String>>§due_date: Option<Option<String>>presentational only – nothing schedules on it
priority: Option<Option<String>>§form_key: Option<Option<String>>flowable:formKey – the key exactly as the model wrote it, always reported so a client can name the external form whether or not it resolved. Before 6.0.0 a resolved key (via a bpmn_form_binding row) or orvanta:formRef could each name an Orvanta app to render in place of form_fields, surfaced as resolved_form_ref / form_ref. Apps were removed (#1720) and both fields with them (#1759): a key now only ever falls back to form_fields.
form_fields: Option<Vec<BpmnUserTaskFormField>>§form_validation_disabled: Option<bool>the model set flowable:formFieldValidation=\"false\", so the server will not validate the payload
Implementations§
Source§impl PendingUserTask
impl PendingUserTask
Sourcepub fn new(
instance_id: Uuid,
workspace_id: String,
element_id: String,
token_id: Uuid,
instance_created_at: String,
instance_created_by: String,
) -> PendingUserTask
pub fn new( instance_id: Uuid, workspace_id: String, element_id: String, token_id: Uuid, instance_created_at: String, instance_created_by: String, ) -> PendingUserTask
One <userTask> parked awaiting a human, with the process context needed to act on it (#1104). Every field is read off the persisted process status, the compiled user-task model, or the human_task_claim ledger added by #1123.