Inventory Permissions QA

This guide covers Inventory U2. Use the developer guide for accepted rules. This unit implements source policies and permission presentation, not stock commands or HTTP endpoints. Later units now provide source commands and HTTP APIs. Repeat these denial checks at those routes using the HTTP QA guide. Do not accept it by changing mock Hospital stock statuses.

Automated ChecksCopy Anchor Link

Use the disposable database setup. Apply migration 20261011000002_add_inventory_permissions.rb, prepare the test database, and provision RLS grants. Run from backend/:

PARALLEL_WORKERS=1 bin/rails test domains/inventory/test domains/identity/test/rbac domains/identity/test/services/permission_management/access_levels_test.rb domains/identity/test/services/permission_management/member_access_levels_test.rb

Run from frontend/:

pnpm --filter @kulcare/auth-identity test:run
pnpm --filter @kulcare/auth-identity typecheck

Manual ChecklistCopy Anchor Link

Record the branch/commit, tester, environment, tenant, facility, and results on issue #2517 or the integration PR. Use test members and facilities. Do not use real patient or stock data.

• Verify all four keys exist with owner/admin defaults only: view_inventory, manage_inventory, manage_inventory_consumption, and manage_inventory_adjustments.
• Verify each key has one area/level, a defaults row, a real policy-action test, and a snapshot entry naming the permission migration.
• Open Shell permission management with Hospital enabled. Verify Inventory, Inventory consumption, and Inventory adjustments appear as separate areas under Hospital / Surgery Center. No separate Inventory app or RBAC editor is added.
• For a staff role, save Inventory View, Inventory consumption Manage, and Inventory adjustments None. Verify source policy consumption is allowed but receipt, adjustment, and write-off are denied.
• Save another area. Verify all three Inventory grants remain unchanged.
• Repeat the two save checks in the member-access dialog. Verify per-member access remains separate from role defaults.
• Give a member a custom mutation-only grant with Inventory View denied. Verify reads and writes are denied.
• Verify initial expiry validation needs View and stock management. Verify correction also needs adjustments.
• Verify a receipt reversal needs stock management and adjustments. Verify a consumption reversal needs consumption and adjustments. Both also need View.
• Replay an initial expiry-validation operation after a later correction. Verify the original action evidence determines required grants. Missing action evidence must deny, not guess.
• Revoke an effective grant. Verify the corresponding policy denies operation replay.
• Suspend or end the staff/practitioner assignment. Verify policy access is denied, including replay.
• Suspend membership through a separate record while an old membership remains in request context. Verify access is denied.
• Use a different facility in the same tenant. Verify unassigned staff/practitioners cannot access it. Active owners/admins retain tenant-wide facility access but still need action permissions.
• Use another tenant's facility or clear tenant context. Verify denial without stock disclosure.
• Verify a platform administrator without tenant membership has no stock bypass.
• Confirm no stock command, source endpoint, Hospital consumption integration, or production deployment is claimed from U2 policy tests.

Regression NotesCopy Anchor Link

The focused U1/U2, full RBAC, and Shell access-level suite passed locally: 381 tests, 1,777 assertions, no failures, errors, or skips. The new frontend constant test and auth-identity typecheck passed. The RBAC scan exposed stale Connect/staff catalog entries. Their recorded reasons were updated to match existing code; production Connect/staff code was not changed. The known Custom-cell count is 12. The existing Hospital practitioner defaults add the extra cell because they include case/OT management but exclude facility configuration. The three Inventory areas add no Custom cells under catalog defaults. A separate test verifies that property. These checks do not establish full backend CI, deployment, or operator QA acceptance.