Aman-Mittal opened a new pull request, #549:
URL: https://github.com/apache/fineract-backoffice-ui/pull/549

   ## What changed
   
   Broadens the regression coverage for #541 from two routed forms to six, 
spread across feature areas rather than concentrated in one:
   
   | Form | Route | Pickers |
   | --- | --- | ---: |
   | Office | `/organization/offices/create` | 1 |
   | Staff | `/organization/staff/create` | 1 |
   | Holiday | `/settings/holidays/create` | 3 |
   | Teller | `/tellers/create` | 1 |
   | Accounting closure | `/accounting/closures/create` | 1 |
   | Floating rate | `/products/floating-rates/create` | 1 (see below) |
   
   Each case enters its form three times without a reload and asserts no 
`ion-datetime-button` is left unbound. The spec is matched by 
`DUAL_VIEWPORT_SPECS`, so every case runs at **both the desktop and mobile 
viewports**.
   
   The list pages behind the new cases only need to render, so they are mocked 
as empty collections rather than dragging in a fixture per feature.
   
   ## The coverage is not vacuous
   
   Each new case was checked against the broken shape: with `@if 
(pickersReady())` stripped from `holiday-form` and `teller-form`, both fail 
with `visit 2 left a picker unbound`. A test that cannot fail is not coverage, 
so this matters more than the count.
   
   ## A second bug this turned up — #548
   
   The floating rate form is covered with `test.fail()`, because its pickers 
are genuinely broken and this PR does not fix them.
   
   Its date controls live inside `@for (period of periods(); track $index)`, so 
they are created when the user clicks **Add Period**, not with the page. The 
button and its `ion-modal[keepContentsMounted]` then mount in the same 
change-detection pass, the modal's contents are not in the DOM yet, and the 
button binds to nothing. It fails on the **first** visit — no revisit needed.
   
   `createPickersReady()` does not reach this: it gates the initial render, and 
by the time a row is added the flag is already `true`. Confirmed 
**pre-existing, not a regression from #547** — with the `@if` wrapper removed 
the picker fails identically. Moving `<ion-modal>` ahead of the button does not 
help either. Fixing it needs a per-instance deferral, which is a refactor 
rather than a test change, so it is filed as #548 with the analysis.
   
   `test.fail()` rather than a skip is deliberate: the case runs, the suite 
asserts the bug is still there, and it turns red the moment someone fixes it — 
prompting removal of the marker instead of leaving a quietly skipped test 
behind.
   
   #548 also records that the same `@for` gives every rate period the identical 
picker ID, so two periods put two `id="periodfromDate-picker"` elements in the 
document and both rows' buttons target the first one.
   
   ## Testing
   
   - `npx playwright test date-picker-revisit --project=mocked` — 7 passed (6 
cases plus the client-form spec; the floating rate case fails as expected)
   - `npx playwright test --project=mobile` — 23 passed, the whole mobile 
project
   - `npm run typecheck:e2e`, `prettier --check`
   
   Related: #541, #546, #547, #548


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to