Description:
"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.

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

For example:

User Login
    ↓
User Type
    ↓
Role
    ↓
Permissions
    ↓
Allowed Menus / Features
    ↓
UI Access
    ↓
API Authorization

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.

For example, depending on the existing application:

Supplier
    - View
    - Create
    - Edit
    - Delete

Item
    - View
    - Create
    - Edit
    - Delete

Project
    - View
    - Create
    - Edit
    - Delete

UOM
    - View
    - Create
    - Edit
    - Delete

Orders
    - View
    - Create
    - Edit
    - Delete
    - Approve

Expenses
    - View
    - Create
    - Edit
    - Delete

Do not blindly use the above permissions. 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 format like:

cmt8shn9y0009zhj5h8vvj5m8

We do not want to use this format.

We need to standardize the database unique IDs to use a proper UUID format, for example:

550e8400-e29b-41d4-a716-446655440000

Scope¶

This change must be applied consistently across:

• All existing tables.
• All primary keys.
• Foreign keys referencing those IDs.
• Join/relationship tables.
• Any other database fields currently using the existing ID format.
• Future tables/models.

Do not fix only the currently existing tables.

The database/model configuration should be changed so that new tables and future models automatically follow the UUID standard.

Migration Requirements¶

Please inspect the existing database and identify:

• Which tables currently use the existing ID format.
• Which columns are primary keys.
• Which columns are foreign keys.
• Which relationships depend on those IDs.
• Any indexes/constraints involving those IDs.
• Any application code that assumes the current ID format.
• Any API/frontend code that validates or expects the current ID format.

Then create a safe migration strategy.

Important:

Do not simply change the column type without considering existing relationships and data.

We need to preserve existing records and relationships wherever possible.

---

3. Check Application Impact¶

For both changes, please inspect the entire application for dependencies.

For Role & Permissions, check:

• Authentication
• User model
• Role model
• Permission model
• Middleware
• API authorization
• Menu configuration
• Frontend routing
• Backend routes
• Existing guards
• Database relationships
• Seed data

For UUID changes, check:

• Database schema
• ORM configuration
• Models
• Primary keys
• Foreign keys
• Migrations
• API request/response handling
• Validation
• Frontend state
• URLs/routes containing IDs
• Query/filter logic
• Sorting/filtering
• Relationships
• Seed scripts
• Test data
• Existing tests

---

4. Avoid Hardcoding¶

The permission system should be data/configuration driven.

Do not implement logic such as:

if user == admin:
    show everything

Instead, use:

User
  ↓
Role
  ↓
Permissions
  ↓
Menu/Feature Access

This should allow us to add or modify roles and permissions later without changing the application logic everywhere.

Similarly, UUID generation should be centralized through the database/ORM configuration rather than manually generating IDs in individual models.

---

5. Before Implementation¶

Please first inspect the existing OMS project and provide:

A. Current Architecture¶

Explain the current:

• User/authentication structure
• Database schema
• Menu structure
• Authorization mechanism
• ID generation mechanism

B. Role & Permission Design¶

Provide:

User Type
    ↓
Role
    ↓
Permissions
    ↓
Menus
    ↓
Actions

and list the proposed roles and permissions.

C. UUID Impact Analysis¶

Provide a table:

Table	Current ID	Foreign Keys	Related Tables	Required Change
...	...	...	...	...

D. Migration Plan¶

Explain how you will migrate existing IDs to UUIDs without breaking:

• Existing data
• Relationships
• APIs
• Frontend
• Foreign keys
• Existing functionality

E. Implementation Plan¶

Provide the files/modules that need to be changed and explain why.

After the analysis, implement both changes and perform full verification.

---

Final Acceptance Criteria¶

Role & Permissions¶

• Supplier and Manufacturer user types are supported.
• Admin and Staff roles are supported for each user type.
• Permissions are properly defined.
• Menus are displayed based on permissions.
• Features/actions are protected based on permissions.
• Frontend routes are protected.
• Backend APIs enforce authorization.
• Unauthorized users cannot bypass permissions through direct API/URL access.
• One initial Super Admin user exists.
• Super Admin has all permissions.
• Super Admin creation is idempotent.
• Permission architecture supports future roles and features.

UUID¶

• All existing table IDs are migrated to proper UUID format.
• All related foreign keys are migrated correctly.
• Existing relationships continue to work.
• Existing data is preserved.
• New records use UUIDs automatically.
• Future tables/models use UUIDs by default.
• No application code still depends on the old ID format.
• APIs continue to work correctly with UUIDs.
• Frontend continues to work correctly with UUIDs.
• Tests and seed data are updated accordingly.

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."

Test Cases:
☐ Both Supplier and Manufacturer user types can be created and are persisted as distinct, valid user types in the system.
☐ Admin and Staff roles can each be assigned to both Supplier and Manufacturer user types.
☐ Every existing OMS menu/feature entry in the menu registry has at least one corresponding permission defined in the permission catalog.
☐ The navigation menu only shows entries the logged-in user has permission to access; hidden entries do not render for a Staff user lacking that permission, and appear for a user who has it.
☐ A specific feature/action control (e.g. Approve Order) is disabled or hidden for a user lacking the corresponding permission, and enabled for a user who has it.
☐ Navigating directly to a permission-protected frontend route URL without the required permission redirects away instead of rendering the protected page.
☐ A backend API endpoint rejects a request from an authenticated user who lacks the required permission for that endpoint.
☐ A user whose menu entry is hidden client-side because they lack the permission still cannot obtain that resource by calling the underlying API endpoint directly.
☐ After application bootstrap/initialization, exactly one Super Admin user exists in the database.
☐ The Super Admin role is granted every permission present in the permission catalog, with none missing.
☐ Running application initialization/seed multiple times does not create duplicate Super Admin users.
☐ A brand-new role, menu, and permission added purely as data (no code changes) is enforced correctly by the existing authorization logic, proving the architecture is extensible without redesign.
☐ After the ID migration runs, every existing table's primary key values are in proper UUID format instead of the old non-UUID format.
☐ After migration, foreign key columns that referenced migrated old-format ids now correctly point to the same rows' new UUID values.
☐ Existing relationships between tables (e.g. Order to OrderItems, Supplier to Orders) still resolve correctly through ORM relation queries after the UUID migration.
☐ Row counts and non-id business field values for every migrated table are unchanged before and after the UUID migration.
☐ Creating a new record after the migration automatically produces a UUID id without the caller specifying one.
☐ A brand-new model added to the Prisma schema, relying only on the shared/global id default rather than a per-model override, still generates UUID ids for its records.
☐ No application source file still generates or depends on the old non-UUID id format after the migration is complete.
☐ Existing API endpoints continue to function correctly when addressed by their new UUID-based ids, and reject old-format ids as not found rather than erroring.
☐ Frontend pages that reference a record by id render correctly when navigated to using the new UUID-based id.
☐ Test fixtures and seed data no longer hardcode ids in the old non-UUID format.

---

Orchestration slug: oms-rbac-uuid (side: web)