OMS Web

Overview¶

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

Requirement¶

Hi Claude, We have completed the OMS implementation, but we have several UI and functionality issues that need to be fixed. Please review the existing implementation against the provided Figma/HTML designs and make the required changes. The design should be followed accurately and consistently across all screens. Do not fix these issues only on individual screens if the same problem exists across the application. Identify reusable/common components and fix them at the common level wherever possible. --- # 1. General UI Changes ## Detail / Edit Screens - All detail-page headers should have a bottom border, as shown in the design. - In all Edit/Details pages, the form section is currently displayed inside an additional box/container. The design does not have this extra box. Remove it and match the design. - The form section should have the appropriate section title/header above it as shown in the design. Currently, this title is missing. - Review all Edit/Details screens and apply the same design consistently. ## List Screens The action area on list screens should follow the design. Expected layout: text + New / Add Filter Search ```` * Add/New action and Filter should be on the **same row**. * Search should appear on the **right side after Filter**. * Do not stack these controls vertically. * Check the provided designs carefully and make the spacing/alignment consistent. ## Table UI Review all tables and fix the following: ### Table Header * The table header row should have the **same background color as the design**. * Current background color does not match. ### Sort Icons * The current sort icon does not match the design. * Use the correct icon/style shown in the design. * Apply it consistently across all sortable columns. ### Status Colors Status badges should use the exact colors from the design. For example: text Partially Fulfilled Pending Fulfilled Each status should have its appropriate background/text color. Currently, different colors are being used, but they do not match the design. ### Action Icons * Action icon colors should match the design. * Use the same icon style and color consistently across all list screens. ### Search Placeholders Search placeholders should be meaningful and screen-specific. For example: text Search Order No Search Supplier Search User Do not show generic or malformed placeholders such as: text <search Review all list screens and correct them. ### Table Actions Some screens currently show text actions such as: text Edit View Details Instead, we should use the **icon-based action style** used in the Supplier List screen. For example: text ✏ Edit 👁 View 🗑 Delete Use the appropriate icons based on the available permissions/actions. --- # 2. Order List There is a specific issue with the Order List action/search area. Currently, the actions/search behaviour is not matching the design. Please check the design and implement it correctly. Expected behaviour: * Initially, only the **Search icon** should be visible. * When the user clicks the Search icon, the search input should expand/show. * Do not show the full search input by default if the design uses the icon-first approach. * Remove any unnecessary actions from the Order List. --- # 3. Confirmation Modal There is extra text/content currently appearing **outside the confirmation modal**. This should not happen. The confirmation message and related content should be contained properly inside the modal. Please: * Inspect the modal implementation. * Remove any content rendered outside the modal. * Ensure the overlay/modal behaves correctly. * Verify Cancel and Confirm/Delete actions. --- # 4. Filter UI Currently, clicking Filter opens a popup/dropdown where the options are selected. However, according to the design, the filter controls should be displayed as a **single horizontal row**, not as a popup. Please refer to the design and implement the filter UI accordingly. Expected: text Filter 1 Filter 2 Filter 3 Filter 4 rather than: text Filter ↓ Popup ↓ Options Make sure this is consistent across all applicable list screens. --- # 5. Sidebar / Side Menu The current sidebar is displaying menu titles and their menu items in a non-collapsible structure. We need a proper **collapsible sidebar menu** based on the provided design. Expected behaviour: text Admin ├── Users ├── Supplier ├── Item ├── Project └── UOM The parent menu should be expandable/collapsible. Please: * Match the design. * Maintain active-menu state. * Maintain submenu state. * Ensure the sidebar works consistently across all screens. * Ensure permission-based menu visibility continues to work. * Avoid duplicating sidebar logic between screens. --- # 6. Order List Navigation In the Order List, remove the existing **Process link/navigation**. Users should navigate/process the order using the appropriate action button in the Actions column. Do not provide duplicate navigation paths. --- # 7. Dynamic Add Option Based on Permissions We need a reusable **dynamic Add functionality for Select/Dropdown options**. For example, in the Add Order screen we may have: text Supplier [Select ▼] [+ Add Supplier] Project [Select ▼] [+ Add Project] An Admin user should be able to add a new Supplier/Project directly from the Add Order screen. However, this functionality must be **permission-based**. For example: text User has Create Supplier permission ↓ Show "Add Supplier" User does not have Create Supplier permission ↓ Do not show "Add Supplier" This should not be implemented only for Supplier and Project. Please review **all Select/Dropdown fields across the OMS application** and identify where this dynamic-add functionality makes sense. For every applicable option: * Identify the related master/module. * Provide Add functionality where appropriate. * Open the appropriate modal/form. * Create the record. * Refresh the dropdown options automatically. * Select the newly created option where appropriate. * Respect the user's permissions. * Ensure backend authorization is also enforced. Please avoid hardcoding this separately for every dropdown. Build a reusable approach where possible. --- # 8. Add Row / Repeating Form Sections In screens where we have an **Add Row** functionality, each newly added row currently displays its own field labels. For example: text Row 1 Item | Quantity | Price | Amount Row 2 Item | Quantity | Price | Amount Row 3 Item | Quantity | Price | Amount Instead, based on the design, the field headers should be displayed **only once** and reused for all rows. Expected: text Item Quantity Price Amount ------------------------------------------------ [Select] [Input] [Input] [Input] Row 1 [Select] [Input] [Input] [Input] Row 2 [Select] [Input] [Input] [Input] Row 3 Review all repeating/add-row forms and apply this pattern where applicable. --- # 9. Browser Tab Title The browser tab title should be dynamically updated based on the current screen. For example: text User List → Users Add User → Add User Order List → Orders Order Details → Order Details Expenses → Expenses Review all OMS screens and ensure the page title is meaningful and consistent. Do not use the same generic title for every screen. --- # 10. Users Module We have the following requirements for the User module. ### Super Admin The system has a Super Admin user. The Super Admin should be treated specially: * Super Admin role should **not be available** as an option when creating a new user. * Super Admin user should **not appear in the User List**. * Super Admin user must **not be deletable**. * Ensure these restrictions are enforced at both frontend and backend levels. Do not simply hide the Super Admin from the UI while allowing API-level modification/deletion. ### Add User UI The current Add User screen does not match the provided design. Please compare the existing implementation with the attached Add User design and fix: * Layout * Form fields * Spacing * Typography * Labels * Input styles * Select styles * Status control * Buttons * Overall alignment The attached design should be treated as the source of truth. --- # 11. Order Module There are different Order Detail requirements based on the user type. ## Supplier User For Supplier users, the Order Detail screen should follow the provided HTML/design. Please implement the Supplier-specific Order Detail UI exactly according to the design. ## Manufacturer User For Manufacturer users: * **Do not show Due Date** in the Order Detail screen. * Due Date should only be displayed for the Supplier Order Detail view. Expected: text Supplier Order Details → Due Date: Visible Manufacturer Order Details → Due Date: Hidden ``` This should be controlled based on the user's type/role and not hardcoded based on the screen. --- # 12. Expenses Module In the Add Expenses screen, there is an Add Row section. The Attachment column currently does not match the provided design. Please: * Compare it with the design. * Fix the Attachment column UI. * Match the correct size, alignment, icon, spacing, and interaction. * Verify the Add Row behaviour. * Ensure multiple expense rows continue to work correctly. --- # Implementation Expectations Before making changes, please inspect the existing OMS architecture and identify: 1. Common UI components. 2. Shared table component. 3. Shared filter component. 4. Shared search component. 5. Shared sidebar/menu component. 6. Shared modal components. 7. Shared form components. 8. Permission-checking mechanism. 9. User/role implementation. 10. Existing Order and Expense components. Where an issue is caused by a shared component, fix it at the shared component level instead of creating screen-specific workarounds. --- # UI Verification After implementation, perform a complete UI verification against the provided Figma/HTML designs. Check: * Layout * Spacing * Typography * Colors * Icons * Borders * Tables * Buttons * Forms * Modals * Filters * Search * Sidebar * Responsive behaviour * Empty states * Loading states * Error states Do not consider the task complete just because the functionality works. The UI must also match the provided design accurately. --- # Final Verification Checklist Please verify all of the following: * [ ] Detail headers have the correct bottom border. * [ ] Edit/Detail form containers match the design. * [ ] Form section titles are present. * [ ] List action controls are aligned correctly. * [ ] Search appears in the correct position. * [ ] Table header colors match the design. * [ ] Sort icons match the design. * [ ] Status colors match the design. * [ ] Action icon colors match the design. * [ ] Search placeholders are correct. * [ ] Table actions use icons instead of text where required. * [ ] Order search initially shows only the search icon. * [ ] Confirmation modal does not render extra content outside. * [ ] Filters are displayed according to the design. * [ ] Sidebar is collapsible. * [ ] Order Process link is removed. * [ ] Dynamic Add options are implemented where applicable. * [ ] Dynamic Add options respect permissions. * [ ] Add-row headers are displayed only once. * [ ] Browser tab titles are screen-specific. * [ ] Super Admin cannot be created. * [ ] Super Admin is not shown in User List. * [ ] Super Admin cannot be deleted. * [ ] Add User matches the provided design. * [ ] Supplier Order Detail matches the provided design. * [ ] Manufacturer Order Detail hides Due Date. * [ ] Expenses Attachment column matches the design. * [ ] Existing functionality is not broken. * [ ] Permission-based functionality continues to work. * [ ] Frontend and backend authorization are properly enforced. Please first review the current implementation and the provided designs, identify all affected components/files, and then implement the fixes systematically. Avoid one-off fixes when the issue can be solved through a reusable/common component.

Explicit Constraints¶

• Do not fix these issues only on individual screens if the same problem exists across the application. scope/approach
• Do not stack these controls vertically. screens/UI — list screen action area
• Do not show the full search input by default if the design uses the icon-first approach. screens/UI — Order List search
• Remove any unnecessary actions from the Order List. screens/UI — Order List
• Do not show generic or malformed placeholders such as: <search screens/UI — search placeholders
• This should not happen. The confirmation message and related content should be contained properly inside the modal. Remove any content rendered outside the modal. screens/UI — confirmation modal
• Super Admin role should not be available as an option when creating a new user. screens/UI and backend — Users module
• Super Admin user should not appear in the User List. screens/UI and backend — Users module
• Super Admin user must not be deletable. screens/UI and backend — Users module
• Do not simply hide the Super Admin from the UI while allowing API-level modification/deletion. backend authorization — Users module
• Do not show Due Date in the Order Detail screen for Manufacturer users. screens/UI — Manufacturer Order Detail
• This should not be implemented only for Supplier and Project. Review all Select/Dropdown fields across the OMS application. scope — dynamic Add functionality
• Please avoid hardcoding this separately for every dropdown. Build a reusable approach where possible. scope/approach — dynamic Add functionality
• Do not use the same generic title for every screen. screens/UI — browser tab title
• Remove the existing Process link/navigation in the Order List. screens/UI — Order List navigation
• Do not provide duplicate navigation paths. screens/UI — Order List navigation
• Avoid duplicating sidebar logic between screens. existing behavior/code — sidebar
• Where an issue is caused by a shared component, fix it at the shared component level instead of creating screen-specific workarounds. scope/approach
• Do not consider the task complete just because the functionality works. The UI must also match the provided design accurately. scope — completion criteria
• Ensure backend authorization is also enforced. backend authorization — dynamic Add / permissions

Acceptance Criteria¶

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

Test Cases¶

☐ Every Edit/Details screen header renders the bottom border style specified in the design, consistently across all such screens.
☐ Edit/Details form sections no longer render inside an extra wrapping box/container.
☐ Every Edit/Details form section displays its section title/header above the form fields, matching the design.
☐ List-screen toolbars place Add/New and Filter on the same row with Search positioned to the right of Filter, not stacked vertically.
☐ The table header row background color matches the design's specified color across all list/table screens.
☐ Sort icons on sortable table columns match the design icon/style, applied consistently across all sortable columns and screens.
☐ Status badges use the exact background/text colors specified in the design for each status value.
☐ Action icon colors in table rows match the design and are applied consistently across all list screens.
☐ Search input placeholders are screen-specific and meaningful, with no generic or malformed placeholder text remaining on any list screen.
☐ Table row actions use icon-based controls instead of text links, showing only the icons the current user's permissions allow, consistently across all list screens.
☐ On the Order List, only a Search icon is visible by default; clicking it expands/reveals the search input.
☐ Unnecessary actions beyond the required set are removed from the Order List action/search area.
☐ The confirmation modal renders its message and related content entirely inside the modal container, and the overlay/modal opens and closes correctly.
☐ Cancel and Confirm/Delete actions in the confirmation modal each perform their correct respective behavior.
☐ Filter controls on applicable list screens display as a single horizontal row of filters rather than a popup/dropdown.
☐ The sidebar supports collapsible parent menu items that expand/collapse to show/hide their child menu items, matching the design.
☐ The sidebar preserves which menu item is currently active across navigation.
☐ The sidebar preserves submenu expand/collapse state consistently across screens.
☐ Sidebar menu items are shown/hidden according to the current user's permissions, with no duplicated sidebar logic between screens.
☐ The Order List no longer shows a Process link/navigation; processing an order is only reachable via the Actions-column action button.
☐ For Select/Dropdown fields backed by an add-capable master/module, a "+ Add " option is available and opens the create modal/form.
☐ The "+ Add " option is shown only when the current user has the corresponding create permission, hidden otherwise.
☐ Backend authorization enforces the same create permission for each dynamic-add entity independent of frontend visibility.
☐ After creating a record via a dynamic Add dropdown option, the dropdown's options refresh to include the new record and select it where appropriate.
☐ In Add Row / repeating form sections, field/column headers render once at the top of the section and are reused for all rows.
☐ The browser tab title updates dynamically per screen to a meaningful, screen-specific value.
☐ The Super Admin role is not offered as a selectable option in the role selector when creating a new user.
☐ The Super Admin user does not appear as a row in the User List.
☐ Attempting to delete the Super Admin user is prevented in the UI.
☐ The backend rejects a request to create a user with the Super Admin role, independent of frontend restrictions.
☐ The backend rejects a request to delete the Super Admin user, independent of frontend restrictions.
☐ The Add User screen's layout, fields, spacing, typography, styles, and alignment match the provided Add User design.
☐ For Supplier-type users, the Order Detail screen matches the provided Supplier Order Detail HTML/design.
☐ For Manufacturer-type users, the Order Detail screen does not display the Due Date field.
☐ For Supplier-type users, the Order Detail screen displays the Due Date field.
☐ Due Date visibility on the Order Detail screen is determined by the viewing user's type/role rather than being hardcoded per screen.
☐ In the Add Expenses Add Row section, the Attachment column's size, alignment, icon, spacing, and interaction match the provided design.
☐ Adding multiple expense rows in the Add Expenses screen continues to function correctly after the Attachment column UI change.
☐ Where a defect originates in a shared/common UI component (table, filter, search, sidebar, modal, or form component), the fix is applied at that shared component level rather than duplicated as a screen-specific workaround.

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-hi-claude-have-completed (side: web)