OpenBoxes: Location-Scoped Inventory Permissions Need Concrete Tests

Inventory systems reveal stock levels, supplier relationships, shipment status, and the locations that hold sensitive supplies. OpenBoxes uses permission levels that can apply across the system or at a specific location. A small internet count does not make that model less important. It creates an opportunity to review each candidate precisely.

OpenBoxes' permission guide says every user has a level that controls what they can see and do, with system-wide and location-specific settings. The user guide describes location roles and a default location. The onboarding documentation recommends changing the default administrator password and role and creating users with the appropriate authority. The product documentation also describes locations that manage inventory and non-depot locations that may only submit or view requests.

These distinctions make location the central authorization context. A user with stock access at one depot should not be able to view or transact at another depot unless the policy grants it. A user who can submit a request from a ward should not be able to approve stock movement at a depot.

Measurement scope

A count-only ZoomEye AI probe on 2026-11-16 used sub_type=all, page 1, and page size 1. title="OpenBoxes" returned 4 matches. app="OpenBoxes" returned 0, and http.body="OpenBoxes" returned 197. The body count can include documentation and project pages. Four title matches are a narrow observation and may include demos or references rather than production systems.

The count is not proof of a public inventory system. It is a small candidate set that should be verified by owner and hostname.

Test the location boundary

Create a user with a role at location A and no role at location B. Test inventory view, stock movement, shipment receipt, and request submission at both locations. Then test a user whose default role is no access but whose location role grants one workflow. The result should match the location-specific grant, not fall back to a broad default.

Test the location hierarchy. A regional manager may need access to a group of locations, while a single depot user should not inherit the regional scope. Review how the application resolves the hierarchy in the UI and in any API or import path.

Review imports and shipments

Bulk imports, shipment rollback, and data imports are administrative operations. A user who can create a stock count should not automatically be able to roll back a shipment or import new products. Separate these actions into narrow roles and record the file, actor, target location, and result.

Shipments can traverse several locations. Verify that each transition checks the actor's authority at both the source and destination. A receiving user should not be able to alter a shipment after it has been finalized unless the policy grants a correction workflow with an audit record.

Protect administrator access

Use a named administrator account and a unique strong credential. Change the default administrator password and role as part of onboarding. Restrict internet access to the administrative path where possible and put the application behind a trusted identity proxy if that integration is supported.

Log role assignment, location-role changes, stock adjustments, imports, and shipment rollback. Review the logs for users who have broad default roles they no longer need.

OpenBoxes illustrates a general inventory problem: the most important authorization decision is often not "can this user log in?" It is "at which location and for which transaction?" The four title matches should be treated as candidates for that exact test. ZoomEye can narrow the public edge; the location-role matrix determines whether the edge is safe.

References

1. OpenBoxes, "Intro to User Permissions." https://help.openboxes.com/article/64-intro-to-user-permissions
2. OpenBoxes, "Create and Manage users." https://help.openboxes.com/article/89-manage-users
3. OpenBoxes, "Onboarding." https://docs.openboxes.com/en/develop/user-guide/onboarding/