[18.0][stock_operating_unit] Access Errors on Inter-Warehouse Replenishment and Transfer Validation

[habibz6deh]

Module

stock_operating_unit

Describe the bug

When attempting an inter-warehouse transfer (replenishment) between two warehouses belonging to different Operating Units (OU), users encounter Access Errors in two specific stages.

1. Replenishment Creation: A user assigned to the destination OU cannot create a replenishment rule that pulls from a source warehouse in a different OU (Access Error on stock.warehouse / stock.location).
2. Transfer Validation: A user assigned to the source OU cannot validate the outgoing delivery order because it is linked to a move in the destination OU (Access Error on stock.move).

The strict record rules seem to prevent the cross-OU access required for the standard "Resupply from Warehouse" route to function.

To Reproduce

Affected versions: 18.0

Steps to reproduce the behavior:

1. Setup Configuration:

• Operating Units: Create Main OU and Second OU.
• Warehouses:
  • WH (My Company) -> Assigned to Main OU.
  • WH2 (Second Warehouse) -> Assigned to Second OU.
• Users:
  • User 1: Assigned to Main OU. Role: Inventory Administrator.
  • User 2: Assigned to Second OU. Role: Inventory Administrator.
• Routes: Configure a product with the "Supply Product from My Company" route (pulling from WH to supply WH2).

2. Scenario A (Creation Failure):

1. Log in as User 2 (Second OU).
2. Go to Replenishment and attempt to create a manual orderpoint for the product in WH2 (triggering a pull from WH).
3. Result: The system raises an Access Error for stock.warehouse.

3. Scenario B (Validation Failure):

1. (Workaround) Log in as Admin and create the replenishment rule for User 2. This generates a Delivery Order in WH and a Receipt in WH2.
2. Log in as User 1 (Main OU).
3. Open the Delivery Order in WH and click Validate.
4. Result: The system raises an Access Error for stock.move.

Expected behavior

1. User 2 should be able to trigger a replenishment for their own warehouse (WH2), even if the supply route originates from a different OU (WH).
2. User 1 should be able to validate the outgoing Delivery Order from their warehouse (WH), without being blocked by the linked move in the destination OU.

Additional context

Error Log (Scenario A - User 2):

Uh-oh! Looks like you have stumbled upon some top-secret records. Sorry, User 2 (id=7) doesn't have 'read' access to: - Warehouse (stock.warehouse)

Error Log (Scenario B - User 1):

Uh-oh! Looks like you have stumbled upon some top-secret records. Sorry, User 1 (id=6) doesn't have 'read' access to: - Stock Move (stock.move)

[rkingkong]

In stock_operating_unit, warehouses, locations, and moves are very tightly scoped to the user’s operating unit. That works fine as long as flows stay inside one OU, but the standard Resupply from Warehouse route implicitly assumes cross-warehouse visibility. Once those warehouses belong to different OUs, you hit exactly the two failure points you described.

On the replenishment side, the orderpoint creation ends up needing read access to the source stock.warehouse and its locations to resolve the route and supply path. Since the user in OU2 has no read access to OU1’s warehouse, the record rule prevents anything meaningful from happening.

On validation, the outgoing picking in WH is linked to a chained move whose destination is in WH2/OU2. When validating, Odoo tries to read/update the complete move chain. The user in OU1 doesn’t have read access to the destination move, so an access error on stock.move is expected under the current rules.

In other words, the standard resupply flow is cross-OU by design, but the module enforces OU isolation at a level that prevents that flow from completing.

From an implementation standpoint, there are usually two ways this gets addressed:

• Relax record rules selectively for internal logistics flows (routes, orderpoints, chained moves), so users can read related records that belong to another OU only when the operation originates from their own warehouse.
• Or introduce an explicit “logistics OU” / shared visibility concept for inter-warehouse routes, so the source and destination warehouses can see each other without opening up full cross-OU access everywhere.

We’ve had to solve similar cases in multi-OU, multi-warehouse setups, and the key is to be very deliberate about read vs write access to stock.warehouse, stock.location, and stock.move so you don’t break the isolation model while still allowing chained moves to work.

If this is something the OCA module wants to support natively, I’d say this is less a bug in replenishment and more a missing design decision around cross-OU internal transfers. Happy to help reason through what the “least dangerous” rule relaxation would look like if that’s useful.