OMS Web

Overview¶

Feature for the web side. 21 acceptance criteria identified. 19 test case(s) generated.

Requirement¶

"Signin"

Attached file (read it directly for the real content): /opt/drcarrot-deploy/cross-repo-orchestration/contracts/.attachments/dev-hub-spec-yX33DRTS9JnMNers7-requirement-1.md

Attached file (read it directly for the real content): /opt/drcarrot-deploy/cross-repo-orchestration/contracts/.attachments/dev-hub-spec-8Ykc7jREDxEcyJrmn-OMS_Screens__standalone___2_.html

Acceptance Criteria¶

• {'id': 'AC-5c205bb3', 'text': 'Existing authentication/API functionality is unchanged after the redesign — the sign-in request still uses the existing authentication logic/API contract, not new or modified logic.'}
• {'id': 'AC-2ca4d7f2', 'text': 'Submitting valid credentials successfully authenticates the user and navigates them to the correct post-login screen.'}
• {'id': 'AC-3cb403ed', 'text': 'Submitting invalid credentials shows an error message and keeps the user on the Sign In screen (no navigation away).'}
• {'id': 'AC-c2f4c710', 'text': 'Required-field client-side validation (e.g. missing mobile number/password) continues to work and blocks submission.'}
• {'id': 'AC-2e28c10a', 'text': 'Validation error messages are displayed correctly for invalid/missing input.'}
• {'id': 'AC-76d02a80', 'text': 'A loading state is shown on the Login button/form while a sign-in request is in progress.'}
• {'id': 'AC-07cfe3fe', 'text': 'The Login control prevents duplicate submission (e.g. disabled state) while a sign-in request is in progress.'}
• {'id': 'AC-ef6d6425', 'text': 'API errors returned during sign-in are caught and surfaced to the user as an error state without breaking the screen.'}
• {'id': 'AC-ddba5fdf', 'text': "The password field's visibility can be toggled (show/hide) via the eye icon shown in the HTML, if that behaviour is present in the redesigned screen."}
• {'id': 'AC-51a4c52d', 'text': 'After a successful login, the user is navigated to the correct next screen per the existing post-login navigation behaviour.'}
• {'id': 'AC-cf4898f9', 'text': 'When unauthenticated, only the Sign In screen is rendered/reachable — no other application UI is accessible.'}
• {'id': 'AC-6baad6d8', 'text': 'The Sign In screen renders a two-panel split layout: a left brand/marketing panel (~45% width, full height, dark background) and a right form panel (centered, ~360px wide), matching the HTML.'}
• {'id': 'AC-68569470', 'text': "The left panel displays the 'OMS' logo badge, 'Company Name' label, heading 'Manage your orders, expenses and suppliers in one place.', and supporting text 'A single workspace for procurement, expense tracking and supplier management.'"}
• {'id': 'AC-76385665', 'text': "The right panel displays the heading 'Sign In' and subtext 'Sign in to continue to OMS'."}
• {'id': 'AC-e3fb582a', 'text': "The form includes a labeled 'Mobile Number' input field as shown in the HTML."}
• {'id': 'AC-25ac2d6d', 'text': "The form includes a labeled 'Password' input field with a masked value and a visibility-toggle icon as shown in the HTML."}
• {'id': 'AC-75c0b6a8', 'text': "The form includes a full-width 'Login' button styled with the brand dark background and a defined hover state."}
• {'id': 'AC-eba3cb27', 'text': "The footer text 'Need access? Contact your administrator.' is displayed below the Login button."}
• {'id': 'AC-2bc5f3f0', 'text': 'Overall layout, spacing, typography (font sizes/weights), and colors match the values specified in the HTML design.'}
• {'id': 'AC-aa6a0e69', 'text': 'The Sign In screen displays and functions correctly across different screen sizes (responsive behaviour).'}
• {'id': 'AC-ce4b1895', 'text': "If the HTML's 'Mobile Number' identifier field conflicts with the credential type (e.g. email/username) the existing authentication API actually expects, the existing API contract takes priority and the discrepancy is documented as a deviation in the final implementation summary."}

Test Cases¶

☐ The redesigned Sign In screen submits credentials using the exact same authentication API contract (endpoint, HTTP method, payload shape, headers) as the pre-redesign screen — no new or parallel auth logic was introduced.
☐ Submitting valid Mobile Number and Password credentials successfully authenticates the user and navigates them to the correct post-login screen.
☐ Submitting invalid credentials shows an error message and keeps the user on the Sign In screen with no navigation.
☐ Client-side required-field validation blocks submission when Mobile Number and/or Password are missing.
☐ Validation error messages are displayed correctly for invalid or missing input.
☐ A loading state is shown on the Login button/form while a sign-in request is in progress.
☐ The Login control prevents duplicate submission by becoming disabled while a sign-in request is in progress.
☐ API errors returned during sign-in are caught and surfaced to the user as an error state without breaking the screen.
☐ The password field's visibility can be toggled between masked and plain text via the eye icon.
☐ When unauthenticated, only the Sign In screen is rendered/reachable — no other application UI is accessible.
☐ The Sign In screen renders a two-panel split layout: a left brand panel (~45% width, full height, dark background) and a right form panel (centered, ~360px wide), matching the HTML.
☐ The left panel displays the 'OMS' logo badge, 'Company Name' label, the heading 'Manage your orders, expenses and suppliers in one place.', and the supporting text 'A single workspace for procurement, expense tracking and supplier management.'
☐ The right panel displays the heading 'Sign In' and the subtext 'Sign in to continue to OMS'.
☐ The form includes a labeled 'Mobile Number' input field as shown in the HTML.
☐ The form includes a labeled 'Password' input field whose value is masked, with a visibility-toggle icon, as shown in the HTML.
☐ The form includes a full-width 'Login' button styled with the brand dark background and a defined hover state.
☐ The footer text 'Need access? Contact your administrator.' is displayed below the Login button.
☐ Overall layout, spacing, typography (font sizes/weights), and colors of the rendered Sign In screen match the values specified in the HTML design.
☐ The Sign In screen displays and functions correctly across different screen sizes (responsive behaviour).

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-signin-flow (side: web)