# Feature RESMA-27 - Implement the request/approval process for Resource Allocations

Project: Stream Resource Management
Status: new
URL: https://community.openproject.org/work_packages/RESMA-27

## Planning

| Attribute | Value |
| --- | --- |
| Date |  |
| Priority | Medium |
| Target versions | Product Backlog |
| Votes |  |
| List |  |
| Roadmap |  |
| Relevance |  |

## OPEN POINTS / FEEDBACK

_No work packages_

## Features and Chunks

_No work packages_

## Bugs and other work packages

_No work packages_

## Technical Details

| Attribute | Value |
| --- | --- |
| Module |  |
| Feature Flag |  |
| Requires doc change | No |
| Enterprise plan |  |

## Details

| Attribute | Value |
| --- | --- |
| Pull preview |  |
| Mockups |  |
| Accessibility | No |

## People

| Attribute | Value |
| --- | --- |
| Assignee |  |
| Accountable |  |
| Product manager |  |
| Developers |  |
| Designer |  |
| Ordered by |  |
| Signed off by |  |
| Interest by |  |

## Estimates and progress

| Attribute | Value |
| --- | --- |
| PD (min) |  |
| PD (max) |  |
| Work |  |
| Labor costs |  |

## Description

**As** a project or team lead who needs capacity owned by someone else  
**I want to** request a resource allocation and have it approved before it becomes active  
**so that** the person who owns that capacity stays in control of what is booked on their team, and requesters get a clear, auditable answer instead of silently over-booking people

**Acceptance criteria**

*   A user with the new _request resource allocations_ permission can create an allocation that lands in the **requested** state instead of going straight to **allocated**; `requested_by` is set to the creating user.
    
*   Requested allocations are visually distinguished (state badge/label) in the timelines, lists and staffing views, and do **not** count toward a user's booked capacity or overbooking calculations until approved.
    
*   A user with the _review resource allocations_ permission sees a queue of pending (**requested**) allocations for their project and can **approve** (→ `allocated`) or **reject** (→ `rejected`); `reviewed_by` is set to the reviewer in both cases.
    
*   The requester can **withdraw** their own pending request (→ `canceled`).
    
*   Once approved, a request behaves identically to a directly-created allocation — it counts toward capacity and triggers the existing overbooking checks.
    
*   Only valid transitions are allowed: `requested → allocated | rejected | canceled`; already-decided allocations cannot be re-decided.
    
*   Every transition is captured in the allocation journal (who requested, who reviewed, when), surfaced in the activity/history.
    
*   All four state values render translated, human-readable labels.
    

**Technical notes**

*   The model is already prepared: `ResourceAllocation` has the `state` enum (`requested`/`allocated`/`rejected`/`canceled`) and the `requested_by`, `reviewed_by`, `principal_assigned_by` user columns, all journalized and principal-reference-tracked. **No schema change is needed for the core flow.**
    
*   The flow is currently short-circuited — see the comment at `resource_allocation.rb:67` ("State machine is ignored… all allocations go directly to the `allocated` state"). This must be replaced with real transition logic.
    
*   There is **no AASM gem** — it's a plain Rails enum. Add transition guards in a service/contract (e.g. `ApproveAllocation` / `RejectAllocation`), not a full state-machine dependency, unless complexity grows.
    
*   Capacity/overbooking already scope to `.allocated` (`allocated_for_principals`, `allocated_for_work_packages`, overbooking helpers), so requested allocations are naturally excluded from capacity math — confirm this holds and add coverage.
    
*   Add project-scoped permissions in `engine.rb`: `request_resource_allocations` and `review_resource_allocations`, both depending on `view_resource_planners`, mapped to new controller actions (`approve`, `reject`, `cancel`). Keep consistency with the existing `allocate_user_resources` naming/pattern.
    
*   New/updated contracts: a request-create path that sets `state: :requested` + `requested_by`; a review contract that checks the reviewer permission and the current state before transitioning and sets `reviewed_by`.
    
*   Decide how this interacts with the existing `allocate_user_resources` permission — whether it still allows direct-to-`allocated` creation (bypassing approval) for capacity owners, or whether it becomes approve-only.
    

**Permissions and visibility considerations**

*   _To whom is this feature visible?_
    
    *   Requesters (holders of `request_resource_allocations`) see their own requests and their status.
        
    *   Reviewers (holders of `review_resource_allocations`) see the pending-request queue and the approve/reject controls for their project.
        
    *   All resource-management access remains gated by `view_resource_planners` and is **project-scoped** (no global permission), consistent with the rest of the module.
        
*   _When is it not visible?_
    
    *   Users without `view_resource_planners` see nothing.
        
    *   Approve/reject controls are hidden from users lacking `review_resource_allocations`; the request action is hidden from users lacking `request_resource_allocations`.
        
    *   Requested (not-yet-approved) allocations must not appear as confirmed bookings to team members viewing capacity — open question: whether the targeted assignee (`principal`) can see a pending request aimed at them.
        

**Translation considerations**

*   _Key terms and phrases in the key languages (EN / DE):_
    
    *   Requested — Angefragt
        
    *   Allocated / Approved — Zugeteilt / Genehmigt
        
    *   Rejected — Abgelehnt
        
    *   Canceled (withdrawn) — Zurückgezogen
        
    *   Pending — Ausstehend
        
    *   Request / Approve / Reject / Withdraw — Anfragen / Genehmigen / Ablehnen / Zurückziehen
        
    *   Requested by — Angefragt von · Reviewed by — Geprüft von
        
*   Note: the four `state` enum values currently have **no value translations** in `config/locales/en.yml` (only the `state` attribute label exists) — these must be added for every supported language.
    

**Out of scope**

*   Multi-level or chained approvals, and approval routing rules.
    
*   Delegation, substitute reviewers, or auto-approval policies.
    
*   Email / in-app notifications to reviewer and requester (may be a fast-follow, decide explicitly).
    
*   Bulk approve/reject.
    
*   Approval SLAs, reminders, or escalation.
    
*   Any public API / BCF exposure of the new states and actions.
    

_Set the_ **To be informed/consulted teams** _field to include all teams necessary to be informed of the changes._

A couple of decisions I'd flag as the main open questions before this is buildable: (1) whether allocate\_user\_resources still permits direct-to-allocated creation for capacity owners, or approval becomes mandatory for everyone; and (2) whether notifications are in v1 — without them, reviewers have to actively poll the queue, which weakens the feature considerably.