TJK: fix(custom-roles): stock request workflow for Facility Storekeeper and Regional Warehouse

[MatiasArriola]

✨ Description of Change

Link to GitHub issue or Jira ticket: https://app.clickup.com/t/869da29v7

Problem

This PR fixes regressions in the stock request workflow for the new restricted custom roles:

• ROLE_FACILITY_STOREKEEPER
• ROLE_REGIONAL_WAREHOUSE

The original issue was that stock request creation was failing for these users. Endpoints needed by the stock request process were being denied.
After opening up the create flow, there were also follow-up inconsistencies around related stock-request actions and the stock movement show page: most actions were incorrectly denied (comment, add doc, etc.).

What changed

1. Update permissions related to stock-request

File:

• CustomRolePolicyServiceSpec.groovy

Added coverage for:

• stock request creation through API
• stocklist loading needed during request creation
• stock request comment/document/delete routes for facility storekeeper
• approval-route expectations for regional warehouse with and without approver role

Reasoning:

• These workflows regressed specifically because of the custom-role changes.
• The tests now document the expected stock request behavior for the affected roles.

2. Hide misleading actions on the stock movement show page

Files:

• AuthTagLib.groovy
• show.gsp

Changes:

• Added canCreateStockMovementFromShow taglib helper.
• Create is hidden on electronic stock requests for:
  • ROLE_FACILITY_STOREKEEPER
  • ROLE_REGIONAL_WAREHOUSE
• Receive is shown only when stockMovement.isReceivingAuthorized(currentLocation) is true.

Reasoning:

• After fixing the stock request flow, the show page still exposed actions that were not valid for these restricted roles in this context.
• This produced avoidable access-denied flows.
• The Create visibility rule was moved out of the GSP and into AuthTagLib to keep the view easier to reason about.

3. Allow requestors to delete their own stock requests

File:

• StockMovement.groovy

Change:

• In isDeleteOrRollbackAuthorized(...), electronic stock requests can now be deleted by the requestor themselves, even if they do not have assistant-or-higher role.

Reasoning:

• Once facility storekeeper / regional warehouse users can create stock requests, it is inconsistent if they cannot remove their own pending request.
• This change is narrowly scoped to electronic stock requests only.
• If needed, we could allow Facility Storekeeper or Regional Warehouse Users to delete any request. We would need to review this more in-depth.

Functional impact

For facility storekeeper / regional warehouse users:

• stock request workflow is more coherent end to end
• invalid or misleading actions are hidden on the stock request show page

For stock request requestors:

• users can delete their own pending stock requests without needing assistant-or-higher role

Testing

Added/updated unit coverage in:

• CustomRolePolicyServiceSpec.groovy

Important:

To test the approval flow, the users that should approve the Stock Requests must have the separate "Request approver" role for the given Location. This role is what allows the users to appear in the "Approvers" control, and also used to check for permissions to exercise that action.

---

📷 Screenshots & Recordings (optional)

openboxes-stock-request.webm

[anagperal]

thanks @MatiasArriola ! only two comments

[anagperal]

I have this access denied when click on "Receive" button as a user with role REGIONAL_WAREHOUSE that receives the shipment from an inbound movement:

A REGIONAL_WAREHOUSE user clicking Receive (partialReceiving/create):

1. getActivePolicy → ROLE_REGIONAL_WAREHOUSE (so hasPolicy = true).
2. isDeniedForRegionalWarehouse('partialReceiving','create') → no matching rule → denied = false.
3. isAllowedByPolicy → isRouteAllowed(REGIONAL_WAREHOUSE_ALLOWED_ACTIONS, 'partialReceiving', 'create') → partialReceiving wasn't a key in the map → false. And isAllowedStockRequestRoute doesn't handle partialReceiving either → allowed = false.
4. Result: denied:false, allowed:false → falls through to the legacy rules.

AI-suggested solution, add to REGIONAL_WAREHOUSE_ALLOWED_ACTIONS:

    'internalLocationApi'     : ['listReceiving'],
    'partialReceiving'        : ['create'],
    'partialReceivingApi'     : ['read', 'update'],

Test

1. Create a request from regional location to main location
2. Go to main location and approve request then click on edit to create shipment and click on send shipment
3. Go to regional location to the corresponding inbound shipment and click on "Receive"

[anagperal]

I have this access denied when trying to create the shipment from the request as a user with role REGIONAL_WAREHOUSE:

The updateShipment action is missing from isAllowedStockRequestRoute. The Send step makes two calls: updateShipment (save shipment details) then updateStatus with DISPATCHED. The updateStatus is already allowed via isAllowedStockRequestRoute line 405, but updateShipment is missing

Test

1. Create request with facility user to regional location
2. Go to regional location and approve request then click on edit to create shipment and click on send shipment

[MatiasArriola]

Thanks @anagperal! Good catches and suggestions!

Tested both flows end to end before the changes and reproduced the issues, then added the permissions and verified it is fixed. Had to add the permissions for both facility storekeeper and regional warehouse.
Also I got an extra forbidden error for RPC superuser when editing the request, so also I had to allow it to get the stockMovementItems.

Tested from inbound request until receive and verifying inventory using both scenarios:

• facility storekeeper <-> regional warehouse
• regional warehouse <-> RPC superuser

[anagperal]

thanks @MatiasArriola !