Package com.axelor.workflow.task
Class WorkflowTaskQueries
java.lang.Object
com.axelor.workflow.task.WorkflowTaskQueries
What the approval inbox reads: which tasks a user may act on, the rows of a record's approvals
dropdown, which buttons a task offers, and why one is out of reach.
-
Nested Class Summary
Nested ClassesModifier and TypeClassDescriptionstatic final recordstatic final recordThe actionable-by-me domain and the role and group ids it binds. -
Constructor Summary
Constructors -
Method Summary
Modifier and TypeMethodDescriptionblockedReason(MetaWorkflowTask task, boolean canAct, boolean owns) Why the current user cannot act on this task, or null when they can, from most to least specific: the assignee, the claimer, a hint to claim, then the pool.buttonVisibility(MetaWorkflowTask task, boolean canAct, boolean owns, boolean isAdmin) The buttons a task offers, from its state and three precomputed facts: not pending: none claim: a pooled, unclaimed task the user may act on complete, reassign: the owner reject: the owner, where the node allows it cancel, force complete: an admin, where the node allows itbooleanWhether the current user may read the task's record, checked per operation since a task points at its record polymorphically.longPending tasksusermay act on; 0 for no user.myTasksDomain(User user) Tasks a user may act on: pending and assigned to them, claimed by them, or unclaimed and offered to one of their roles or their group.longpendingCount(String model, Long recordId) Pending approvals on one business record.rowsForRecord(String model, Long recordId, User user) The pending tasks on one record as rows for its approvals dropdown, with the action flags worked out here so the client never decides who may act.visibility(MetaWorkflowTask task, User user) The buttonstaskoffersuser, from what the task service says they may do.Models with at least one active workflow, so the client skips the approvals query elsewhere.
-
Constructor Details
-
WorkflowTaskQueries
public WorkflowTaskQueries()
-
-
Method Details
-
myTasksDomain
Tasks a user may act on: pending and assigned to them, claimed by them, or unclaimed and offered to one of their roles or their group. Role membership cannot be written in a static domain, so the ids are returned for binding. -
countMine
Pending tasksusermay act on; 0 for no user. -
pendingCount
Pending approvals on one business record. -
rowsForRecord
The pending tasks on one record as rows for its approvals dropdown, with the action flags worked out here so the client never decides who may act. -
blockedReason
Why the current user cannot act on this task, or null when they can, from most to least specific: the assignee, the claimer, a hint to claim, then the pool. -
visibility
The buttonstaskoffersuser, from what the task service says they may do. -
buttonVisibility
public WorkflowTaskQueries.ButtonVisibility buttonVisibility(MetaWorkflowTask task, boolean canAct, boolean owns, boolean isAdmin) The buttons a task offers, from its state and three precomputed facts:- not pending: none
- claim: a pooled, unclaimed task the user may act on
- complete, reassign: the owner
- reject: the owner, where the node allows it
- cancel, force complete: an admin, where the node allows it
The node's restrictions are snapshotted on the task, since a view has no plan.
-
canReadRecord
Whether the current user may read the task's record, checked per operation since a task points at its record polymorphically. Uses the persisted task's model and id, not the client's. -
workflowModels
Models with at least one active workflow, so the client skips the approvals query elsewhere.
-