spec: resolver-path user-task assignment - #18
Open
delchev wants to merge 1 commit into
Open
Conversation
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The problem
A user task's
assigneeis a role / candidate-group name or the literalpersonal(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
The behaviour
pathis 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 declaresidentity, which is what maps a record to a login.fallbackis 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.