OMS Web

Overview¶

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

Requirement¶

"We have two major changes to implement in the OMS application. Please inspect the existing application, database schema, authentication/authorization flow, and menu structure before making any changes.
Dont create any screen we dont want any screen for this rereuiment so just so the functionalities

1. Role & Permission Management¶

We need to implement a proper role-based permission system for OMS.

User Types¶

We have two types of users:

1. Supplier
2. Manufacturer

Each user type has two roles:

• Admin
• Staff

So the structure is:

Supplier
├── Admin
└── Staff

Manufacturer
├── Admin
└── Staff

Each role will have different permissions.

Permission-Based Access¶

All menus and functionalities in the OMS application must be displayed and accessible based on the user's permissions.

This should not be implemented only at the UI/menu level.

We need proper authorization at both:

• Frontend/UI level
• Backend/API level

If a user does not have permission for a particular functionality:

• The corresponding menu should not be shown.
• The user should not be able to access the functionality directly through a URL.
• The corresponding API should reject unauthorized requests.
• Do not rely only on hiding the menu for security.

Permission Design¶

Please inspect all existing OMS menus/features and design the permission structure accordingly.

Permissions should preferably be granular enough to support future requirements.

Do not blindly use a fixed example permission list. Inspect the actual OMS functionality and determine the appropriate permission model.

The permission system should also be designed so that adding new menus/features in the future does not require redesigning the entire authorization system.

Initial Super Admin¶

Initially, we need one default user with Role: Super Admin, Permissions: All.

The Super Admin should have access to all current and future functionalities unless explicitly restricted later.

Please determine the best way to implement this based on the existing authentication/database architecture.

Also ensure that the initial Super Admin creation is safe and does not create duplicate users when the application is initialized multiple times.

2. Database ID Format¶

Currently, database unique IDs are being generated in a cuid-style format. We do not want this. We need to standardize on proper UUID format instead.

This change must be applied consistently across all existing tables, primary keys, foreign keys, join/relationship tables, and any other fields using the old format — and future tables/models must automatically follow the UUID standard.

Do not simply change the column type without considering existing relationships and data. We need to preserve existing records and relationships wherever possible.

Important: Do not implement these as isolated changes. First understand the existing OMS architecture and make the role/permission system and UUID strategy consistent, reusable, and maintainable for future development.

Explicit Constraints¶

• Dont create any screen we dont want any screen for this rereuiment so just so the functionalities screens/UI
• This should not be implemented only at the UI/menu level. authorization/security
• Do not rely only on hiding the menu for security. authorization/security
• Do not blindly use a fixed example permission list. Inspect the actual OMS functionality and determine the appropriate permission model. permission design
• We do not want this [cuid-style format]. We need to standardize on proper UUID format instead. database schema
• Do not simply change the column type without considering existing relationships and data. database schema/migration
• Do not implement these as isolated changes. scope/implementation approach
• ensure that the initial Super Admin creation is safe and does not create duplicate users when the application is initialized multiple times. super admin seeding

Task Breakdown¶

Parent: OMS — Role/Permission system + UUID ID standardization

1. Architecture inspection + combined design spec (permission model & UUID strategy)
   • Inspect existing OMS app, DB schema, auth/authz flow and menu structure. Produce: (a) full inventory of existing menus/features → derived granular permission catalogue and naming convention that is extensible for future features without redesign; (b) UUID strategy (generation point, column type, ORM/model default so future tables inherit it automatically, migration approach preserving existing rows and relationships). Deliverable is a written design, no code shipped.
2. RBAC data model, migrations, and idempotent Super Admin seed
   • Tables/models for user_type (Supplier | Manufacturer), role (Admin | Staff, plus Super Admin), permission, and their join tables; assignment of the designed permission catalogue to each user_type×role combination; a default Super Admin with all permissions, seeded idempotently so repeated app initialization creates no duplicate user. Super Admin implicitly grants current and future permissions rather than a frozen snapshot.
3. Backend/API authorization enforcement across all existing endpoints
   • Middleware/policy/guard layer resolving the acting user's permissions; every existing OMS API endpoint mapped to its permission and rejecting unauthorized requests with the correct status; a permissions endpoint the frontend consumes; default-deny for unmapped routes so future endpoints fail closed.
4. Frontend permission gating — menu rendering and route guards
   • Consume the permission set at login/session; render only permitted menu entries; guard direct URL access to unpermitted routes (redirect/403 view using existing components). No new screens, no redesign — gating of what already exists.
5. cuid → UUID standardization across schema, with data-preserving migration
   • Convert all existing PKs, FKs, join/relationship tables and any other cuid-format fields to UUID; forward migration that preserves existing records and relationships (mapping table / staged FK rewrite rather than a bare column-type change); base model/ORM default so future tables and models inherit UUID automatically; referential-integrity verification and a documented rollback.

Acceptance Criteria¶

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

Test Cases¶

☐ The system's user-type definition contains exactly two values, Supplier and Manufacturer, with none added or missing.
☐ Each of Supplier and Manufacturer supports exactly two roles, Admin and Staff.
☐ Menus and functionalities shown to a logged-in user match exactly that user's assigned permission set.
☐ Authorization is enforced independently on the frontend/UI and on the backend/API — removing or bypassing one layer does not expose the functionality via the other.
☐ A user lacking permission for a functionality does not see the corresponding menu entry.
☐ A user lacking permission for a functionality cannot reach it by navigating directly to its URL.
☐ A user lacking permission for a functionality has the corresponding backend API reject the request as unauthorized.
☐ The permission registry is derived from the actual current inventory of OMS menus/features rather than a fixed example list — every real menu and API route has a corresponding permission mapping.
☐ The permission model is granular (resource+action level, not just module-level) so it can support permission requirements beyond the initial rollout.
☐ A new menu/feature can be added later using only the standard registration mechanism, without modifying the core authorization engine.
☐ After application initialization, exactly one Super Admin user exists, holding every permission.
☐ The Super Admin automatically retains access to functionality added after initial setup, unless an explicit restriction record has been placed on that Super Admin.
☐ Re-running application initialization never creates a duplicate Super Admin user.
☐ All existing cuid-style unique IDs are converted to standard UUID format.
☐ The UUID conversion is applied consistently to every table's primary keys, foreign keys, and join/relationship tables, with none skipped.
☐ Newly added tables/models automatically get UUID-formatted IDs without any extra per-model configuration.
☐ Existing records and their relationships remain intact and functional after the ID-format migration, with no data loss.
☐ No new UI screens are introduced while implementing this requirement.
☐ The role/permission system and the UUID id-format strategy are built as one consistent design, not as two isolated efforts — the new authorization tables follow the same UUID convention as everything else.

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-rbac-v2 (side: web)