h3. Overview
Feature for the web side. 23 test case(s) generated.

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

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

h3. Acceptance Criteria
(none extracted — spec-extract has not run for this session)

h3. Test Cases
☐ The system recognizes exactly two user types, Supplier and Manufacturer, as first-class values in the user/account model.
☐ Both Supplier and Manufacturer user types support exactly two roles, Admin and Staff.
☐ Permissions are defined and stored in a data/configuration model (e.g. role/permission/menu tables or config) rather than as hardcoded per-role conditionals scattered through application logic.
☐ A menu item is shown only to users whose role/permissions grant access to it, and is hidden from users who lack that permission.
☐ A feature or action within a screen is enabled/accessible only to users whose role/permissions grant it, and is blocked otherwise.
☐ Navigating directly to a frontend route/URL for a feature the user lacks permission for does not grant access to that feature.
☐ Every backend API endpoint tied to a permissioned feature independently enforces authorization, regardless of frontend/UI state.
☐ A direct API request made without the required permission is rejected by the backend with an authorization error status, not merely hidden by the UI.
☐ Exactly one Super Admin user exists after the application's initial initialization process runs.
☐ The Super Admin role is granted all currently defined permissions by default.
☐ The Super Admin role is granted all future permissions by default, unless explicitly restricted later.
☐ Running the application initialization process multiple times does not create duplicate Super Admin users.
☐ A new role, menu, or feature can be added to the permission system purely through configuration/data, without modifying the core authorization logic elsewhere in the application.
☐ Every primary key that previously used the old non-UUID ID format has been migrated to UUID format.
☐ Every foreign key column referencing a migrated primary key now holds the corresponding new UUID value.
☐ Every existing relationship, including join/relationship tables, resolves correctly after the ID migration.
☐ No existing data rows are lost or corrupted as a result of the ID migration.
☐ A newly created record after migration receives a UUID-format ID automatically, without manual ID generation in the model.
☐ A newly created table/model added after this change defaults to UUID-format primary keys via centralized database/ORM configuration, without per-model manual setup.
☐ No backend or frontend code path assumes, generates, or validates the old non-UUID ID format after migration is complete.
☐ Every existing API endpoint continues to return correct request/response behavior when operating on UUID-format IDs.
☐ Every existing frontend feature that relies on IDs (ID-based URLs/routes, filtering, sorting, relationship lookups) continues to function correctly with UUID-format IDs.
☐ Existing automated tests and seed data are updated to use and expect UUID-format IDs, and the full test suite passes after migration.

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

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

---

Orchestration slug: oms-rbac (side: web)