OMS Web

Overview¶

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

Requirement¶

Hi Claude, We need to implement the complete User Management module in the OMS application. The module should support the following functionality: 1. User List 2. Add User 3. View User 4. Edit User 5. Delete User I have attached the User List and Add User designs for reference. Please carefully review the attached designs and implement the UI and complete user flow accordingly. 1. User List Implement the User List screen based on the attached design. The list should include: Date, User Name, Role, User Type, Mobile, Status, Actions (Edit, View, Delete). Also implement pagination, sorting, search, filtering, loading state, empty state, and error state. Use the existing application patterns/components wherever possible. 2. Add User Implement the Add User flow based on the attached design. Fields: User Name, Mobile, Role, Type, Password, Confirm Password, Status. Implement required-field validation, input validation, mobile number validation, password validation, confirm-password validation, duplicate user validation where applicable, proper error messages, loading/submission state, success handling, and API error handling. Save creates the user through the appropriate API. Cancel returns to the list without creating/updating anything. 3. View User Implement a View User flow so users can view complete user information in a read-only format, following existing OMS UI patterns, with no unauthorized modification allowed. 4. Edit User Same form/design patterns as Add User: load existing user data, pre-populate the form, allow only permitted fields to be modified, apply the same validations as Add User, save through the appropriate API, and refresh the user list after a successful update. Reuse common form components and validation logic instead of duplicating Add User. 5. Delete User Delete -> Confirmation Modal -> Cancel/Delete -> Delete API -> Success -> Refresh User List. Do not delete without confirmation. Handle confirmation, cancellation, loading state, API failure, success message, and list refresh. 6. Role & Permission Integration Follow the existing OMS role and permission system. Actions should be shown/enabled based on the logged-in user's permissions (View Users, Create User, Edit User, Delete User). Do not rely only on hiding UI buttons -- backend APIs must also validate permissions. 7. UI Requirements Treat the attached designs as the source of truth. Match layout, spacing, typography, colors, borders, buttons, icons, form fields, table, pagination, modal, and responsive behaviour as closely as possible. Do not create a completely different UI. Inspect the existing OMS application first and reuse existing components/styles where they match the design. 8. API & Database Inspect the existing backend/API implementation first to determine whether the required User APIs already exist, and reuse them where available. If missing, implement the required backend functionality following existing OMS architecture and conventions. Ensure the complete flow works: UI -> API -> Database -> API Response -> UI Update. 9. Before Implementation First inspect the existing project and provide: current User module implementation (if any), existing User APIs, existing database User model/schema, existing role/permission implementation, existing reusable UI components, what needs to be created, what can be reused, any gaps/issues in the current implementation, and a proposed implementation plan. Provide the plan before making major changes. 10. Verification After implementation, verify: User List -> Search/Filter/Sort/Pagination -> View User -> Add User -> Edit User -> Delete User -> Permission Validation -> API Validation -> Final UI Verification. Also verify different permission combinations so users only see/perform actions they're authorized for. Acceptance Criteria: User List matches the design; Add User matches the design; View/Edit/Delete User implemented (Delete with confirmation); Search/Filtering/Sorting/Pagination work correctly; form and API validations implemented; role/permission-based access implemented with unauthorized actions inaccessible; loading/empty/error/success states handled; existing OMS UI patterns/components reused where appropriate; complete frontend -> API -> database flow verified; UI verified against the attached designs. Important: first understand the existing OMS architecture and the attached designs, reuse existing functionality where possible, avoid unnecessary duplication, then implement the complete User Management flow end-to-end.

Attached spec file (read it directly for the real requirements): /tmp/dev-hub-spec-wSXuzYqcndsbNvoZR-Users_Screens__standalone_.html

Explicit Constraints¶

• Do not delete without confirmation Delete User flow
• Do not rely only on hiding UI buttons -- backend APIs must also validate permissions Role & Permission Integration
• Do not create a completely different UI screens/UI
• Cancel returns to the list without creating/updating anything Add User / Edit User flow
• no unauthorized modification allowed View User screen
• allow only permitted fields to be modified Edit User form
• Reuse common form components and validation logic instead of duplicating Add User Edit User implementation / code reuse
• Inspect the existing backend/API implementation first to determine whether the required User APIs already exist, and reuse them where available API & Database / scope
• Inspect the existing project and provide a proposed implementation plan before making major changes scope / implementation order

Acceptance Criteria¶

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

Test Cases¶

☐ Verify the User List screen renders the required columns and per-row action controls.
☐ Verify the User List supports pagination through multi-page result sets.
☐ Verify the User List supports sorting by clicking a column header.
☐ Verify the User List search narrows results to matching users.
☐ Verify the User List supports filtering results by attributes such as Role and Status.
☐ Verify the User List displays a loading state while user data is being fetched.
☐ Verify the User List displays an empty state when there are no users to show.
☐ Verify the User List displays an error state when the data fetch fails.
☐ Verify the User List is implemented using OMS's existing shared UI components rather than new bespoke ones.
☐ Verify the Add User form renders all required input fields.
☐ Verify the Add User form blocks submission when mandatory fields are left blank.
☐ Verify the Add User form validates the input format of relevant fields (e.g., User Name character constraints).
☐ Verify the Add User form validates the Mobile field.
☐ Verify the Add User form validates the Password field against the OMS password policy.
☐ Verify the Add User form validates that Confirm Password matches Password.
☐ Verify the Add User form rejects creating a user that duplicates an existing one.
☐ Verify the Add User form displays clear error messages for both client-side validation failures and API failures.
☐ Verify the Add User form shows a loading/submission state while the create request is in flight.
☐ Verify the Add User flow shows success handling after a user is created successfully.
☐ Verify the Add User form's Save action creates the user via the create-user API.
☐ Verify the Add User form's Cancel action returns to the list without creating or updating any user.
☐ Verify View User displays complete user information in a read-only format with no editable fields.
☐ Verify View User is implemented using OMS's existing read-only detail-view UI patterns.
☐ Verify Edit User loads the existing user's data and pre-populates the form.
☐ Verify Edit User only allows fields the acting user is permitted to modify to be edited.
☐ Verify Edit User applies the same field validation rules as Add User.
☐ Verify Edit User's Save action updates the user via the update-user API.
☐ Verify the User List refreshes after a successful Edit User update.
☐ Verify Edit User reuses Add User's common form components and validation logic rather than duplicating them.
☐ Verify Delete User requires a confirmation modal before any deletion occurs.
☐ Verify the delete confirmation modal supports both Cancel and Delete actions.
☐ Verify cancelling the delete confirmation performs no deletion.
☐ Verify Delete User shows a loading state while the delete request is in flight.
☐ Verify Delete User handles an API failure during deletion with an appropriate message.
☐ Verify Delete User shows a success message after a successful deletion.
☐ Verify the User List refreshes after a successful deletion.
☐ Verify User List actions (View/Create/Edit/Delete) are shown or hidden/disabled based on the logged-in user's permissions.
☐ Verify the backend User APIs enforce View/Create/Edit/Delete permissions independent of what the UI shows.
☐ Verify the implemented UI matches the attached design mockups' layout, spacing, typography, colors, borders, buttons, icons, form fields, table, pagination, and modal styling.
☐ Verify the User Management screens are responsive across standard viewport sizes.
☐ Verify the User Management screens reuse OMS's existing shared components/styles rather than introducing divergent bespoke UI.
☐ Verify existing User-related backend APIs are reused rather than reimplemented.
☐ Verify any newly implemented backend User functionality follows existing OMS architecture and conventions.
☐ Verify the complete UI -> API -> Database -> API Response -> UI Update flow functions correctly for create, read, update, and delete operations.
☐ Verify a pre-implementation discovery report is produced covering all required areas before implementation begins.
☐ Verify a proposed implementation plan is presented before major implementation changes are made.
☐ Verify post-implementation verification confirms User List search, filter, sort, and pagination all work correctly.
☐ Verify post-implementation verification confirms the View, Add, Edit, and Delete User flows all work correctly end-to-end.
☐ Verify post-implementation verification confirms permission validation is enforced correctly across different permission combinations, with unauthorized actions inaccessible.
☐ Verify post-implementation verification confirms API-level validation is enforced independent of the UI.
☐ Verify post-implementation verification confirms the final UI matches the attached designs.

Implementation Details¶

Merge Request¶

• Repository: oms/oms-web
• Branch: feat/3246-user-management-module-c
• MR: https://gitlab.techbumbles.co.in/oms/oms-web/-/merge_requests/7

Commits¶

• b54c371 Contract (oms-user-management)
• 8b3b5af 4. Dead Code (oms-user-management)
• 548568e 1. Unit Tests (oms-user-management)
• c02fb69 UI Implementation (oms-user-management)
• 36413ae Data Layer (oms-user-management)

Verification¶

Quality Gates¶

• W10_gate_unit_tests: PASS — 353 passed / 0 failed, 94.97% coverage
• (W10_gate_unit_tests at docs/gate-evidence/unit-tests-3246-user-management.txt could not be attached — see log above)
• W11_gate_typescript: PASS — 0 error(s)
• (W11_gate_typescript at docs/gate-evidence/W11_gate_typescript-oms-user-management.txt could not be attached — see log above)
• W12_gate_lint: PASS — 0 error(s), 0 warning(s)
• (W12_gate_lint at docs/gate-evidence/W12_gate_lint-oms-user-management.txt could not be attached — see log above)
• W13_gate_dead_code: PASS
• (W13_gate_dead_code at docs/gate-evidence/dead-code-3246-user-management.txt could not be attached — see log above)
• W14_gate_quality_audit: FAIL
• (W14_gate_quality_audit at docs/gate-evidence/quality-audit-3246-user-management.txt could not be attached — see log above)
• W15_gate_design_consistency_audit: PASS
• (W15_gate_design_consistency_audit at docs/gate-evidence/design-consistency-audit-3246.txt could not be attached — see log above)
• W16_gate_responsive_audit: FAIL
• (W16_gate_responsive_audit at docs/gate-evidence/responsive-audit-3246.txt could not be attached — see log above)
• W20_code_review: PASSED
• W21_ui_verify: FAIL
• (W21_ui_verify at docs/gate-evidence/ui-verify-3246-measurements.md could not be attached — see log above)

UI Verification¶

FAIL

• Match: 40/75 fields (53.3%)
• Screens verified: SCR_USER_LIST, SCR_ADD_USER
• (Verified UI evidence at docs/gate-evidence/ui-verify-3246-measurements.md could not be attached — see log above)
  Live verification: PASSED
• (Live verification evidence at no persisted artifact — sandbox has read-only filesystem access; full transcript of build/seed/curl/psql commands and observed HTTP status codes is in this run's tool-call history could not be attached — see log above)

Orchestration slug: oms-user-management (side: web)