Surface a record's BPM user tasks as in-context actions on generated entity views#6074
Merged
Conversation
The Outlook-style inbox redesign (#6064/#6066/#6068) replaced the task table with a bk-list and embeds a claimed task's form in the detail pane, but the BPM test projects still clicked a <tr> "Process request" row and a non-existent "Open Form" tab - failing ApproveLeaveRequestBpmIT, DeclineLeaveRequestBpmIT and BpmnMultitenancyIT on master. Select the task via its bk-list link (ANCHOR) and drop the "Open Form" + switchToLatestTab steps; the claimed task's form now embeds in the detail pane, so the Approve/Decline click + native-alert assertion run against the embedded iframe (the fixture form still uses a native alert, unaffected by the non-modal-notification change to intent-generated forms). Verified locally: ApproveLeaveRequestBpmIT + BpmnMultitenancyIT green. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Process-aware entities (those the intent trigger stamps with a ProcessId) now surface the current user's actionable user tasks directly on their generated entity views, removing the trip to the Process Inbox to correlate a task to its record by business key. - New shared ProcessTasks Angular module (resources-dashboard) holding the inbox fetch -> bucket-by-processInstanceId -> claim/open-form logic plus an <entity-process-tasks> directive; one self-contained piece reused everywhere. - parameterUtils.js sets hasProcess when an entity has a ProcessId property. - Wired (gated on hasProcess) into list, manage, master-list/detail, master-manage/detail and both main-details views, so it works regardless of master/detail layout. - FormIntentGenerator: the generated task form now closes its host on completion via DialogHub.closeWindow() + window.close() (dialog, inbox and standalone window); the prior window.close()-only call was a no-op inside iframes. Co-Authored-By: Claude Opus 4.8 <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
1 participant
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.
Why
For a document-centric process (e.g. an
Invoice/Loanwith a manual validation/approval step), a user today has to create the record in the Entities area and then switch to the Process Inbox, find the user task, and mentally correlate it to the record by business key. This removes that round-trip: a process-aware record's actionable user tasks appear directly on its generated entity view.Approach
Correlation keys off the
ProcessIdthe intent process-trigger already stamps onto the entity (entity.ProcessId === task.processInstanceId) — an exact id match, no business-key convention, and process start is already handled by the trigger. A record is treated as process-aware purely by the presence of aProcessIdproperty, so no new modelling is required.The logic lives in one shared piece, not copied per template:
resources-dashboard/.../dashboard/services/process-tasks.js— aProcessTasksAngular module (loaded next to the existingentity.js) with a service (refresh/ensureLoaded/getTasks/openTask: inbox fetch → bucket-by-processInstanceId→ claim-if-needed → open form) and a self-contained<entity-process-tasks entity="...">directive (count-badged inbox button → popover of the record's tasks; hidden when none).parameterUtils.js— setshasProcesswhen an entity has aProcessIdproperty (same mechanism ashasDropdowns/hasDates).#if($hasProcess), ~3 lines each) into list, manage, master-list/detail, master-manage/detail and both main-details views — so it works whether the process-aware entity is a master (e.g.Order) or a composition detail (e.g.Loan).Form close on completion
FormIntentGeneratornow closes the task form's host on completion via bothDialogHub.closeWindow()andwindow.close()— covering the shell dialog, the inbox's inline iframe (no-op; it clears its own pane), and a standalone script-opened window respectively. The previouswindow.close()-only call was a no-op inside iframes, which is why the dialog stayed open after Approve.Notes / limitations
ProcessId(intent-trigger apps, or any model that adds one + starts the process); classic hand-authored projects with neither are unaffected — all additions are gated and inert otherwise./services/bpm/bpm-processes/tasks/{id}while the directive claims via the permission-checked/services/inbox/tasks/{id}— non-admin candidate users may need these aligned later.Testing
No integration test drives the generated row menus or asserts the form's code block, so the IT suite is unaffected. Verified manually by generating an intent app whose process triggers on a record and confirming the task surfaces on the record's view and the dialog closes after Approve.
🤖 Generated with Claude Code