OMS Web

Overview¶

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

Requirement¶

UI/UX + functionality bug-fix sweep across OMS: detail-page headers, edit/detail form layout, list-screen action row, table header/sort-icon/status-colors/action-icons/search-placeholders/action-column, Order List search+Process-link, confirmation modal, filter row layout, collapsible sidebar, dynamic add-from-dropdown for master data, repeating-row headers, browser tab titles, Users module (Super Admin restrictions + Add User design), Order module (Supplier/Manufacturer detail differences), Expenses attachment UI, refresh-token handling, toggle/switch controls, and removal of unwanted fields (UOM Symbol, Item Model No, Supplier Supplier No). Full requirements below -- treat every numbered item as mandatory, not a subset. Do NOT start implementation before inspecting the current code and producing the full checklist/mapping described at the end of this message. --- FULL REQUIREMENTS BELOW --- Hi Claude, We have completed testing of the OMS application and identified the following UI, functionality, and validation issues. Please review every single item listed below without skipping anything. In the previous implementation, only 3-4 issues were fixed while several other reported issues were missed. We do not want that to happen again. You must create a complete checklist from the requirements below, verify each item individually, implement the required fixes, and perform final verification for every item. Do not consider the task complete until every checklist item has been either: - Fixed and verified, or - Confirmed as already correct, with evidence/reasoning. Do not assume that fixing a common component automatically means all affected screens are correct. Verify all applicable screens individually. --- # 1. General UI ## 1.1 Detail Page Header - All Detail page headers must have a bottom border. - Refer to the provided design and match the border style, spacing, and positioning. ## 1.2 Edit / Detail Form Section Currently, Edit/Detail pages are showing the form inside an additional boxed/container section. This does not match the design. Please: - Remove the unnecessary box/container if it is not present in the design. - Add the missing section title above the form. - Match the design's spacing, typography, alignment, and layout. - Check ALL Edit and Detail screens, not just one screen. ## 1.3 List Screen Action Area On list screens: - The New/Add button and Filter should appear in the same row. - Search should appear on the right side after Filter. - They should not appear vertically one below another. Expected structure: [New/Add] [Filter] [Search] Refer to the design and verify alignment, spacing, sizing, and responsiveness. ## 1.4 Table UI Review all tables and fix the following: ### Table Header - Header background color does not match the design. - Use the exact design styling. ### Sort Icon - Current sort icon is different from the design. - Replace it with the correct icon/style. - Verify all sortable tables. ### Status Colors Status colors must match the design. For example: - Partially Fulfilled - Pending - Fulfilled - Any other applicable statuses The current colors are different from the design. Fix them consistently across all screens. ### Action Icon Colors - Action icons must use the correct colors from the design. - Verify Edit, View, Delete and other applicable actions. ### Search Placeholder Currently some search placeholders are displaying incorrectly, such as: <search Fix all search placeholders. They should be meaningful and screen-specific, for example: Search Order No Search Supplier Search User Review every list screen. ### Table Action Column Some screens are showing text actions such as: Edit View Details We should use icon-based actions similar to the Supplier List design. For example: Edit Icon | View Icon | Delete Icon Use the appropriate icons based on the available functionality and permissions. --- # 2. Order List ## 2.1 Search Behaviour In the Order List: - Initially show only the Search icon. - When the user clicks the Search icon, display/expand the search input. - Do not show the search input by default if the design uses the icon-only initial state. Verify this behaviour against the design. ## 2.2 Remove Process Link Remove the Process link from the Order List. Users should navigate/process the order through the appropriate action button. There should not be duplicate navigation options. --- # 3. Confirmation Modal Currently, additional/extra text is being displayed outside the confirmation modal. This is incorrect. Please: - Keep all confirmation-related content inside the modal. - Remove any unexpected text rendered outside the modal. - Verify modal overlay, positioning, spacing, buttons, and behaviour. - Verify Cancel and Confirm actions. --- # 4. Filter UI Currently, clicking Filter opens a popup where filter options are selected. This does not match the design. The filters should be displayed in a single horizontal row as shown in the design. For example: Filter 1 Filter 2 Filter 3 Filter 4 Please: - Remove the unnecessary popup behaviour where applicable. - Match the provided design. - Check all screens that use filters. - Verify responsive behaviour. --- # 5. Sidebar The current sidebar is displaying menu titles and menu items in a non-collapsible structure. We need a proper collapsible sidebar based on the design. Requirements: - Sidebar should be collapsible. - Parent menu items should expand/collapse their child menus. - Active menu should be clearly indicated. - Submenu behaviour should be consistent. - Permission-based menu visibility must continue to work. - The sidebar should match the provided design. Do not implement this separately for each screen. Fix the shared sidebar/menu implementation if one exists. --- # 6. Dynamic Add for Select/Dropdown Options We need to support adding master data directly from relevant Select/Dropdown fields. For example, in Add Order: Supplier [Select v] [+ Add Supplier] Project [Select v] [+ Add Project] An Admin user with the appropriate permission should be able to add a Supplier or Project without leaving the current screen. Requirements: - Identify all applicable Select/Dropdown fields across the OMS application. - Determine which master data can be dynamically created from each field. - Provide an Add action where applicable. - Add action must be permission-based. - If the user does not have Create permission, the Add action must not be shown. - Open the appropriate Add modal/form. - Create the record. - Refresh the dropdown options. - Select the newly created option where appropriate. - Backend/API authorization must also be enforced. Do not implement this only for Supplier and Project if the same requirement applies to other master data. First identify all applicable cases. --- # 7. Add Row / Repeating Form Fields In screens that support Add Row, each row currently displays the field title/label again. For example: Item Quantity Price -------------------------------- Row 1 Item Quantity Price Row 2 Item Quantity Price Instead, the headers should be displayed once: Item Quantity Price -------------------------------- [Input] [Input] [Input] [Input] [Input] [Input] [Input] [Input] [Input] Please check all Add Row/repeating form sections and apply the correct design. --- # 8. Browser Tab Title The browser tab title should be updated based on the current screen. Examples: User List -> Users Add User -> Add User Order List -> Orders Order Details -> Order Details Expenses -> Expenses Review all OMS screens and ensure meaningful screen-specific titles are used. --- # 9. Users Module ## 9.1 Super Admin Role When creating a user: - Super Admin must NOT appear as a selectable role. - This restriction must also be enforced by the backend. ## 9.2 Super Admin in User List - Super Admin user must NOT appear in the User List. ## 9.3 Super Admin Delete - Super Admin user must NOT be deletable. - This must be protected at both frontend and backend levels. Do not rely only on hiding the Delete button. ## 9.4 Add User UI The current Add User screen does not match the provided design. Please compare it carefully against the attached/provided design and fix: - Layout - Fields - Labels - Spacing - Input styles - Select styles - Toggle/switch - Buttons - Typography - Alignment - Overall structure The provided design is the source of truth. --- # 10. Order Module ## 10.1 Supplier User Order Details For Supplier user type: - Order Detail screen should follow the provided HTML/design. - Verify the complete layout and fields against the design. ## 10.2 Manufacturer User Order Details For Manufacturer user type: - Due Date must NOT be displayed. - Due Date should only be displayed for Supplier Order Detail. Expected: Supplier Order -> Due Date: Visible Manufacturer Order -> Due Date: Hidden Verify this based on the actual user type and not through a hardcoded screen condition. --- # 11. Expenses Module ## 11.1 Add Expenses Attachment In Add Expenses, the Add Row contains an Attachment column. The current Attachment column does not match the design. Please: - Compare it against the provided design. - Fix the UI. - Match icon, size, spacing, alignment, and interaction. - Verify Add Row functionality with multiple rows. --- # 12. Refresh Token Handling There is also an issue/requirement around refresh token handling. Please inspect the existing authentication/token implementation and verify: - Access token expiry handling. - Refresh token flow. - Automatic token refresh. - API retry after successful refresh. - Behaviour when refresh token is expired/invalid. - Logout/session handling when refresh fails. - Prevention of multiple simultaneous refresh requests. - Proper handling across all API calls. Please identify the current implementation and fix any issues found. --- # 13. Toggle / Switch Controls In Add/Edit screens, some boolean fields are currently displayed as checkboxes. The design uses a Toggle/Switch control. Please: - Replace applicable checkboxes with the correct Toggle/Switch UI. - Match the provided design. - Check ALL Add/Edit screens. - Ensure the value/state is correctly persisted. - Ensure the toggle works correctly for both Add and Edit. Do not fix this only on one screen. --- # 14. Remove Unwanted Fields The following fields should NOT be present: ### UOM Remove: Symbol ### Item Remove: Model No ### Supplier Remove: Supplier No Please check: - Add screen - Edit screen - Detail screen - List screen - API request/response where applicable - Database/model usage where applicable Make sure these fields are not simply hidden in the UI while still being incorrectly required by the application. --- # Important: Complete Verification Requirement We have previously faced an issue where only a few reported bugs were fixed while several others were missed. This time, this must NOT happen. Create an explicit checklist from every requirement in this prompt. Before implementation: 1. Inspect the existing implementation. 2. Identify the affected files/components. 3. Identify common/shared components. 4. Identify all screens affected by each issue. 5. Provide the implementation plan. During implementation: 1. Fix the common/root cause where possible. 2. Avoid one-off screen-specific workarounds. 3. Do not remove existing functionality unnecessarily. 4. Maintain the existing permission system. 5. Maintain existing API/backend behaviour unless a change is required. After implementation: Verify EVERY item individually. Use a final verification table like: | # | Requirement | Screen/Module | Status | Fixed/Already Correct | Verification | |---|---|---|---|---|---| | 1 | Detail header bottom border | All Details | Done | Fixed | Verified | | 2 | Edit form container | All Edit | Done | Fixed | Verified | | 3 | List action alignment | All Lists | Done | Fixed | Verified | | ... | ... | ... | ... | ... | ... | The final report must contain every requirement from this prompt, not just the items that were changed. If any item cannot be fixed, clearly explain: - Why it cannot be fixed. - What is blocking it. - What needs to be done. - Whether it requires backend/design/API changes. ## Final Acceptance Criteria The task is complete only when: - Every listed issue has been reviewed. - Every applicable screen has been checked. - Every required fix has been implemented. - UI has been compared against the provided designs. - Functional behaviour has been verified. - Permission behaviour has been verified. - Backend/API restrictions have been verified where applicable. - No previously working functionality is broken. - Final checklist contains all requirements. - No requirement is silently skipped. Please do not start making changes immediately. First inspect the current implementation, create the complete issue/checklist mapping. After that, proceed with implementation and full verification.

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

Explicit Constraints¶

• Do NOT start implementation before inspecting the current code and producing the full checklist/mapping described at the end of this message. scope/process
• Do not consider the task complete until every checklist item has been either fixed and verified, or confirmed as already correct, with evidence/reasoning. scope/process
• Do not assume that fixing a common component automatically means all affected screens are correct. Verify all applicable screens individually. scope/process
• Do not implement the sidebar fix separately for each screen. Fix the shared sidebar/menu implementation if one exists. sidebar implementation
• Do not implement dynamic add-from-dropdown only for Supplier and Project if the same requirement applies to other master data. First identify all applicable cases. dynamic add/dropdown feature
• Do not fix toggle/switch replacement only on one screen. Check ALL Add/Edit screens. toggle/switch controls
• Do not remove existing functionality unnecessarily. existing behavior
• Maintain the existing permission system. existing behavior/permissions
• Maintain existing API/backend behaviour unless a change is required. existing behavior/API
• Super Admin must NOT appear as a selectable role when creating a user. Users module/UI
• Super Admin role restriction must also be enforced by the backend. Users module/backend
• Super Admin user must NOT appear in the User List. Users module/UI
• Super Admin user must NOT be deletable. This must be protected at both frontend and backend levels. Do not rely only on hiding the Delete button. Users module/UI and backend
• Due Date must NOT be displayed for Manufacturer user type. Verify this based on the actual user type and not through a hardcoded screen condition. Order module/Manufacturer Order Detail screen
• Remove the Process link from the Order List. Order List screen
• Remove the UOM Symbol field from Add, Edit, Detail, List screens and API request/response where applicable. UOM module/all screens
• Remove the Item Model No field from Add, Edit, Detail, List screens and API request/response where applicable. Item module/all screens
• Remove the Supplier Supplier No field from Add, Edit, Detail, List screens and API request/response where applicable. Supplier module/all screens
• Make sure removed fields are not simply hidden in the UI while still being incorrectly required by the application. removed fields/all screens and API
• If the user does not have Create permission, the Add action for dynamic add-from-dropdown must not be shown. dynamic add/dropdown feature/permissions
• No requirement is silently skipped. scope/process
• No previously working functionality is broken. existing behavior

Acceptance Criteria¶

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

Test Cases¶

☐ Every Detail page header renders a bottom border matching the design's style, spacing, and positioning.
☐ Edit/Detail pages do not wrap the form in an extra boxed/container element where the design does not call for one.
☐ Every Edit/Detail form displays a section title above the form.
☐ Edit/Detail form spacing, typography, alignment, and layout match the design.
☐ All Edit and Detail screens across OMS (not just one) have been individually verified to match the design.
☐ On every list screen, the New/Add button and Filter control appear in the same row.
☐ Search sits on the right side of the action row, after Filter.
☐ New/Add, Filter, and Search controls are never stacked vertically on any list screen.
☐ List-screen action row alignment, spacing, sizing, and responsiveness match the design across all list screens.
☐ Table header background color matches the design across all tables.
☐ The sort icon matches the design's icon/style on every sortable table.
☐ Status colors (Partially Fulfilled, Pending, Fulfilled, and other applicable statuses) match the design and are consistent across all screens.
☐ Action icon colors (Edit, View, Delete, and other applicable actions) match the design.
☐ Every list screen has a meaningful, screen-specific search placeholder with no malformed placeholder text.
☐ Table action columns use icon-based actions (Edit/View/Delete icons), not text links, consistent with the Supplier List design and gated by permission.
☐ The Order List initially shows only a Search icon, without an expanded search input.
☐ Clicking the Search icon on the Order List expands/displays the search input.
☐ The Process link is removed from the Order List.
☐ Order processing/navigation is available only via the designated action button, with no duplicate navigation options.
☐ All confirmation-related content renders inside the confirmation modal.
☐ No unexpected or extra text renders outside the confirmation modal.
☐ The confirmation modal's overlay, positioning, spacing, and buttons behave correctly.
☐ The confirmation modal's Cancel action functions correctly.
☐ The confirmation modal's Confirm action functions correctly.
☐ Filters are displayed in a single horizontal row (not a popup) matching the design, on every screen that uses filters.
☐ Popup-based filter selection behavior is removed wherever the design specifies the horizontal-row layout.
☐ The filter row's responsive behavior matches the design.
☐ The sidebar is collapsible.
☐ Parent menu items expand/collapse their child menus.
☐ The active menu item is clearly indicated in the sidebar.
☐ Submenu behavior is consistent throughout the sidebar.
☐ Permission-based menu visibility continues to function correctly in the new sidebar.
☐ The sidebar matches the provided design.
☐ The sidebar/menu fix is implemented once in a shared component rather than per-screen.
☐ All applicable Select/Dropdown fields across OMS that should support master-data creation have been identified.
☐ An Add action is shown next to each applicable dropdown only for users with the corresponding Create permission.
☐ The Add action is hidden for users who lack Create permission for that master data.
☐ Clicking Add opens the appropriate Add modal/form for that master-data type.
☐ Submitting the Add modal/form creates the corresponding master-data record.
☐ The dropdown's options refresh to include the newly created record after creation.
☐ The newly created option is auto-selected in the dropdown where appropriate.
☐ The backend/API enforces authorization on the create action independent of UI-level hiding.
☐ The dynamic-add-from-dropdown behavior is implemented for every applicable master-data field, not limited to Supplier and Project.
☐ In Add Row/repeating form sections, field labels/headers are displayed once above the rows rather than repeated per row.
☐ All Add Row/repeating form sections across OMS use the single-header-row layout.
☐ Every OMS screen sets a meaningful, screen-specific browser tab title.
☐ All OMS screens have been reviewed for correct browser tab titles.
☐ Super Admin does not appear as a selectable role in the Add User frontend form.
☐ The backend rejects assignment of the Super Admin role during user creation.
☐ The Super Admin user does not appear in the User List.
☐ The Super Admin user cannot be deleted from the frontend.
☐ The backend rejects deletion of the Super Admin user, independent of frontend UI restrictions.
☐ The Add User screen's layout, fields, labels, spacing, input/select styles, toggle/switch, buttons, typography, alignment, and structure match the provided design.
☐ For Supplier user type, the Order Detail screen matches the provided HTML/design layout and fields.
☐ For Manufacturer user type, the Order Detail screen does not display Due Date.
☐ For Supplier user type, the Order Detail screen displays Due Date.
☐ Due Date visibility is determined by the actual user type at runtime, not by a hardcoded per-screen condition.
☐ The Add Expenses Attachment column UI (icon, size, spacing, alignment, interaction) matches the provided design.
☐ Add Row functionality for the Expenses Attachment column works correctly with multiple rows.
☐ Access token expiry is correctly detected and handled.
☐ The refresh token flow successfully obtains a new access token when the access token expires.
☐ Token refresh happens automatically without requiring user action.
☐ API calls that failed due to an expired access token are automatically retried after a successful token refresh.
☐ The application explicitly handles the case where the refresh token itself is expired or invalid, rather than failing silently.
☐ The user is logged out / the session is ended when token refresh fails.
☐ Multiple simultaneous refresh-token requests are prevented; only one refresh is in flight at a time.
☐ Token refresh handling is applied consistently across all API calls, not only a subset.
☐ Boolean fields on Add/Edit screens use a Toggle/Switch control instead of a checkbox, matching the design.
☐ All Add/Edit screens containing boolean fields have been checked and updated, not just one screen.
☐ The Toggle/Switch value/state is correctly persisted when the record is saved.
☐ The Toggle/Switch control functions correctly in both Add and Edit modes.
☐ The UOM 'Symbol' field is removed from the UOM Add, Edit, Detail, and List screens.
☐ The Item 'Model No' field is removed from the Item Add, Edit, Detail, and List screens.
☐ The Supplier 'Supplier No' field is removed from the Supplier Add, Edit, Detail, and List screens.
☐ The removed fields (UOM Symbol, Item Model No, Supplier Supplier No) are also removed from API request/response payloads where applicable.
☐ None of the removed fields remain UI-hidden while still being required by frontend or backend validation.
☐ A final verification table covering every requirement in this prompt, with Status, Fixed/Already-Correct classification, and verification evidence for each row.
☐ For any requirement that cannot be fixed, the report explicitly states why, what is blocking it, what is needed to unblock it, and whether it requires backend/design/API changes.

Implementation Details¶

Diagnosis & Fix¶

Ticket #3248 is a 14-section, 78-test-case UI/UX + functionality sweep over the whole OMS web app, explicitly written as a re-do of a prior pass that fixed only 3-4 of the reported issues. A full codebase scan against the named design bundle finds a mix: several items are already correct from ticket #3247's work (repeating-row headers, page-header bottom border, Super Admin server-side restrictions, quick-create for Supplier/Project/Item, toggle-not-checkbox), several are genuinely broken (New button in a different row from Filter/Search, filters in a popup instead of an inline row, no table-header background, wrong sort icon, text-not-icon actions on the Expenses list, no action column at all on the Orders list, exactly one metadata title for the entire app, Due Date unconditionally shown), one has no static defect and needs live reproduction (confirmation-modal stray text), one has no design reference in the named bundle (Add User), one is a destructive schema change (field removal), and one is an auth-architecture question that the current design does not have an answer to (refresh tokens — this app has no access/refresh token pair at all). The plan below classifies every one of the 14 sections, because the ticket's acceptance criteria make silent omission a failure.

Merge Request¶

• Repository: oms/oms-web
• Branch: feat/3248-oms-ui-ux-and-functional
• MR: https://gitlab.techbumbles.co.in/oms/oms-web/-/merge_requests/9

Commits¶

• 25a8575 Contract (oms-ui-bug-fx)
• e8fb724 4. Dead Code (oms-ui-bug-fx)
• cfd9f04 1. Unit Tests (oms-ui-bug-fx)
• 884386c UI Implementation (oms-ui-bug-fx)
• 5214e01 Data Layer (oms-ui-bug-fx)

Verification¶

Quality Gates¶

• 1. Unit Tests: PASS — 630 passed / 0 failed, 94.92% coverage
• 1. Unit Tests attached: unit-tests-3248-oms-ui-ux-and-functional.txt
• 2. TypeScript: PASS — 0 error(s)
• 2. TypeScript attached: W11_gate_typescript-oms-ui-bug-fx.txt
• 3. Lint: PASS — 0 error(s), 0 warning(s)
• 3. Lint attached: W12_gate_lint-oms-ui-bug-fx.txt
• 4. Dead Code: PASS
• 4. Dead Code attached: W13_gate_dead_code-oms-ui-bug-fx.txt
• 5. Code & Style Quality Audit: PASS
• 5. Code & Style Quality Audit attached: quality-audit-3248-oms-ui-ux-and-functional.txt
• 6. Design Consistency Audit: FAIL
• 6. Design Consistency Audit attached: design-consistency-audit-3248.txt
• 7. Responsive Audit: FAIL
• 7. Responsive Audit attached: responsive-audit-3248.txt
• Code Review: NEEDS_CHANGES
• UI Verify: FAIL
• UI Verify attached: ui-verify-3248-measurements.md

UI Verification¶

FAIL

• Match: 144/207 fields (69.6%)
• Screens verified: SCR_ORDER_LIST, SCR_ORDER_DETAIL, SCR_ITEM_LIST, SCR_UOM_LIST, SCR_SUPPLIER_LIST, SCR_PROJECT_LIST, SCR_EXPENSE_LIST, SCR_EXPENSE_SUMMARY, SCR_USER_LIST, SCR_ADD_ITEM, SCR_ADD_SUPPLIER, SCR_ADD_UOM, SCR_ADD_PROJECT, SCR_ADD_USER, SCR_ADD_EXPENSE
  Live verification: PASSED

Orchestration slug: oms-ui-bug-fx (side: web)