OMS Web

Overview¶

Feature for the web side. 13 test case(s) generated.

Requirement¶

Hi Claude,

We need to implement permission-based menu and functionality access across the OMS application.

Currently, all menus and functionalities are visible to all users regardless of their assigned permissions. We need to change this so that the UI dynamically shows or hides menus and actions based on the user's permissions.

1. Menu-Level Permissions¶

All OMS menus should be displayed based on the logged-in user's permissions.

For example:

User Permissions
      ↓
Permission Check
      ↓
Show only permitted menus

If the user does not have permission to access a particular module/menu:

• The menu should not be displayed.
• The user should not be able to access the corresponding screen directly through the URL.
• The backend/API should also enforce the permission.

Do not rely only on hiding the menu in the frontend.

2. Functionality-Level Permissions¶

Within each module, individual actions must also be controlled by permissions.

For example:

Supplier
├── View
├── Create
├── Edit
└── Delete

Based on the user's permissions:

• View permission → Show/access the supplier list/details.
• Create permission → Show the Add/Create action.
• Edit permission → Show the Edit action.
• Delete permission → Show the Delete action.

The same permission-based behaviour should be applied consistently to all OMS modules and their available actions.

For example:

Item
├── View
├── Create
├── Edit
└── Delete

Project
├── View
├── Create
├── Edit
└── Delete

UOM
├── View
├── Create
├── Edit
└── Delete

Please do not hardcode permission checks separately in every component. Use a reusable and maintainable permission-checking mechanism.

3. Frontend + Backend Authorization¶

Permission enforcement should happen at both levels:

Frontend:

• Hide menus when the user doesn't have access.
• Hide buttons/actions when the user doesn't have the corresponding permission.
• Prevent direct navigation to unauthorized screens.

Backend/API:

• Validate the user's permissions for every protected operation.
• Reject unauthorized API requests even if someone manually calls the API.

The frontend should never be considered the security layer by itself.

4. Dynamic & Future-Proof¶

The implementation should be driven by the existing role/permission structure.

Do not implement logic like:

if user is admin → show everything

Instead, use the actual permission assigned to the user.

The solution should also support adding new modules, menus, roles, and permissions in the future without requiring major changes to the authorization architecture.

5. Before Implementation¶

First inspect the existing OMS implementation and provide:

1. Current menu structure.
2. Current permission/role implementation.
3. Existing permission definitions.
4. Which menus currently ignore permissions.
5. Which actions currently ignore permissions.
6. Existing frontend authorization/guard logic.
7. Existing backend/API authorization logic.
8. Recommended reusable permission-checking architecture.
9. List of files/components/API endpoints that need to be updated.

Provide a table like:

Module	Menu Permission	View	Create	Edit	Delete	Current Status
Supplier	...	...	...	...	...	...
Item	...	...	...	...	...	...
Project	...	...	...	...	...	...
UOM	...	...	...	...	...	...

After the analysis, implement the changes and verify all permission combinations.

Acceptance Criteria¶

• Menus are shown/hidden based on permissions.
• Unauthorized screens cannot be accessed directly.
• View permission controls screen/data access.
• Create permission controls Add/Create actions.
• Edit permission controls Edit actions.
• Delete permission controls Delete actions.
• All OMS modules follow the same permission mechanism.
• Backend APIs enforce the same permissions.
• No permission checks are unnecessarily hardcoded.
• Existing authorized functionality continues to work.
• The implementation is reusable for future modules and permissions.

Please first analyze the current implementation and do the implementation. can you give it to me properly

Explicit Constraints¶

• Do not rely only on hiding the menu in the frontend. frontend/backend authorization
• Please do not hardcode permission checks separately in every component. implementation architecture
• Do not implement logic like: if user is admin → show everything permission logic/role checks
• The frontend should never be considered the security layer by itself. frontend/backend authorization

Acceptance Criteria¶

(none extracted — spec-extract has not run for this session)

Test Cases¶

☐ A logged-in user only sees navigation menu entries for OMS modules they hold at least one permission for; modules they have no permission on are absent from the rendered menu, not merely disabled.
☐ Typing or following a direct URL to a module screen the user lacks permission for is blocked by the route guard, independent of whether a menu link to it exists.
☐ Backend API endpoints re-validate the authenticated caller's permission on every protected operation, so a request sent directly (bypassing the UI) without the required permission is rejected.
☐ View permission is required to access a module's list/detail screen and its underlying data, enforced both in the UI and by the API.
☐ Create permission gates both the visibility of the Add/Create action in the UI and whether the backend accepts create requests for that module.
☐ Edit permission gates both the visibility of the Edit action in the UI and whether the backend accepts update requests for that module.
☐ Delete permission gates both the visibility of the Delete action in the UI and whether the backend accepts delete requests for that module.
☐ The view/create/edit/delete permission-gating behavior verified for Supplier is applied identically to Item, Project, and UOM, with no module exempted.
☐ Every permission check in the codebase — frontend and backend, across all modules — resolves through one shared, reusable permission-checking mechanism rather than separate hardcoded checks per component or controller.
☐ No access decision anywhere in the codebase is made by branching on role identity (e.g. checking for an 'admin' role name); all decisions resolve against the user's actual assigned permission set.
☐ Registering a new module/menu/permission through the mechanism's configuration is sufficient to get it enforced — no changes to the core permission-checking logic are required.
☐ For a user who is authorized on all four existing modules, previously-working view/create/edit/list/navigation flows continue to succeed unchanged after permission enforcement is added.
☐ A pre-implementation analysis deliverable exists and covers every required topic: current menu structure, current permission/role implementation, existing permission definitions, which menus/actions currently ignore permissions, existing frontend/backend authorization logic, the recommended reusable architecture, and the per-module View/Create/Edit/Delete status table of files/components/endpoints needing updates.

Implementation Details¶

(populated once implementation completes — see the run's completion note on this ticket for the real commit list and MR link)

Verification¶

(populated once verification completes — see the run's completion note on this ticket for UI/live-verification evidence)

---

Orchestration slug: oms-menu-permissions (side: web)