Skip to content

spec: resolver-path user-task assignment - #18

Open
delchev wants to merge 1 commit into
mainfrom
spec/assignee-path
Open

spec: resolver-path user-task assignment#18
delchev wants to merge 1 commit into
mainfrom
spec/assignee-path

Conversation

@delchev

@delchev delchev commented Aug 15, 2026

Copy link
Copy Markdown
Contributor

The problem

A user task's assignee is a role / candidate-group name or the literal personal (the record owner). The reviewer is very often a person the record itself names — the requester's manager, the customer's account manager, the department's approver — and that has no expression today, even though the notify block already resolves one-hop paths off a record with the same kind of validation. The Planned list has carried it since 1.1.

The shape

- name: approve
  kind: userTask
  args:
    assignee: { path: employee.manager, fallback: manager }
    form: ApproveRequest

The behaviour

  • Every segment of path is a to-one relation — the first of the trigger entity, each further one of the previous target — and the walk ends at an entity that declares identity, which is what maps a record to a login.
  • A cross-model relation may only be the last segment: a projection carries the target's own properties (so its identity is known) but not its relations, so there is nothing to walk on from there.
  • A conforming generator validates every hop when the file is read, so a dangling segment is reported then rather than when the process runs.
  • fallback is required and names the candidate group. The walk is resolved when the task is reached, not when the process starts — so a relation an earlier step of the same process set is visible — and when it resolves to nobody (a null hop, a missing record, a blank identity) the task is created unassigned and the fallback group can still claim it. That is what makes the unresolvable case total: a resolver path can never mint a task nobody can see.

Prior art

Hand-written code: a delegate that loads the record, chases the foreign keys and calls the task service to set an assignee — the shape every workflow project rebuilds, with the null-hop case usually left to leave an unclaimable task.

Implementation

Eclipse Dirigible: eclipse-dirigible/dirigible#6738 (closes eclipse-dirigible/dirigible#6716) — parse-time hop validation, a delegate inserted before the task, and the assignee expression plus fallback candidate group on the user task.

Changes here

  • versions/1.2.md — the Task assignment section, the scoped-surfaces cross-reference, a DSL index row, and the Planned entry removed.

A user task's `assignee` accepts a relation walk off the trigger record
beside a role name and the `personal` literal:

    assignee: { path: employee.manager, fallback: manager }

Every segment is a to-one relation and the walk ends at an entity declaring
`identity`; a cross-model relation may only be the last segment, since a
projection carries the target's own properties but not its relations. A
conforming generator validates every hop when the file is read.

`fallback` is required, and is what makes the unresolvable case total: the
walk is resolved when the task is reached, and when it resolves to nobody the
task is created unassigned so the candidate group can still claim it. A
resolver path can therefore never mint a task nobody can see.

Removes the matching entry from the Planned list and adds the DSL index row.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

intent: resolver-path task assignment - route a user task by a relation walk, beyond 'assignee: personal'

1 participant