Resources have semantically a certain lifetime. That means, after a resources is created it will experience state-transition until it reaches the end of its lifetime (e.g. archival). The lifetimes and state-transitions need to be defined in an abstract way, in order to allow the platform to excel for different use-cases.
graph TDA[Create resource] -->|Auto-assign to creator| BB[State: Open] --> |Do work|BB --> |Assign to somebody who can close| CC[State: Open & Ready to close] --> |Close| DD[Resource closed]
Re-Opening is not supported; it could be discussed as long as the parent is still open (hierarchy must hold). Different usage-scenarios are acommodated via manual steps.
Scenario: A subproject must only be closed when 2 people A & B (e.g. different departments) checked it.
Prereqs: Closing right is given to an administrative person and not to the people signing off
- Subproject is executed as usual, then for sign-off is assigned to Person A
- Sign-Off Person A enters a Workflow-Item validating the state and assigns Person B
- Sign-Off Person B enters a Workflow-Item validating the state and assigns to administrative personell that has the close-rights
- Administrative person checks whether all required sign-offs are there and then finally closes; otherwise assigns back
A resource hierarchically describes a node in a tree-like structure. Therefore we need to look at impact of a closed resource to other nodes in the tree.
If a resource has no children, there is no impact on other resources.
If a resource has children (e.g. subprojects / workflowitems), the resource cannot be closed. All children need to be in state closed before a parent can be closed.
graph TD; Project-->Subproject_A; Project-->Subproject_B; Subproject_A-->Workflowitem_A; Subproject_A-->Workflowitem_B; Subproject_B-->Workflowitem_C; Subproject_B-->Workflowitem_D;
This ADR is desigend to enable a MVP implementation. Implementation consists of a check before closing a project whether all subprojects have already been closed.
- Re-opening is not supported
- No automatic closing in hierarchy for now
- System blocks closing if there are open children
- No system-support for specific usage patterns
This approach is on-purpose very lightweight and agnostic to usage pattern. Once needs are understood better system support for scenarios like 4-eyes-principle can be established through a new / updated ADR and formally manifested in the ledger in machine-readable format.