Aman-Mittal opened a new pull request, #303:
URL: https://github.com/apache/fineract-backoffice-ui/pull/303
Fixes the two `group-membership.spec.ts` failures on the backend e2e job.
```
[backend] › a group is activated, staffed, given members and a committee,
then emptied
[backend] › an empty group is closed with a reason, and a group with members
is refused
Expected substring: "Active"
Received string: " Pending "
44 × locator resolved to <app-status-badge data-testid="group-status">
```
Not flaky — all three retries failed identically.
## What was wrong
A timezone disagreement between the browser and the tenant.
Fineract's default tenant runs in `Asia/Kolkata` and stamps
`submittedOnDate` using **tenant** time. The activation dialog defaulted its
date from the **browser's** clock. CI runners are UTC, and for part of every
day those are different calendar days:
```
UTC 2026-08-08 19:40
IST 2026-08-09 01:10 ← the tenant is already on tomorrow
```
So the group is submitted on the 9th, the browser offers the 8th, and the
platform refuses:
```json
{
"userMessageGlobalisationCode":
"error.msg.group.submittedOnDate.after.activation.date",
"defaultUserMessage": "Submitted on date cannot be after the activation
date",
"args": [{ "value": "2026-08-09" }]
}
```
The screen handles the refusal correctly — `errorInterceptor` raises a toast
carrying the platform's own message — but the group stays pending, and that is
what the assertion sees.
The window is **18:30–24:00 UTC**, five and a half hours a day. Outside it
the two zones agree and everything passes, which is why this reads as
intermittent and why it does not reproduce for anyone developing in IST.
## The fix
The dialog now takes a floor: the date Fineract has already committed to —
the group's submitted-on date for an activation, its activation date for a
closure. It becomes the picker's `min`, and the default moves up to meet it
when the browser is behind. Those dates arrive rendered in the tenant's
timezone, which is exactly what makes them usable as a floor for a picker that
otherwise only knows what day it is in the browser's.
Both sides are zero-padded `YYYY-MM-DD` and are compared lexically. Parsing
them back into `Date` would put the browser's timezone back into a comparison
this exists to keep it out of.
Where the two constraints cannot both hold — a business date earlier than
the floor — the floor wins and the cap is dropped. It is the constraint the
command itself validates, and a range with `max < min` is one no date satisfies.
## Verifying it
Reproduced two ways: the raw API call above against a live platform, and
`TZ=UTC` on the Playwright run, which fails exactly as CI does.
| | |
|---|---|
| `TZ=UTC` backend e2e — the failing condition | 4 passed |
| backend e2e in local TZ | 4 passed |
| mocked `group-detail.spec.ts` | 6 passed |
| `groups/*.spec.ts` unit | 21 passed |
| `npm run lint`, `tsc` | clean |
`group-action-dialog.component.spec.ts` is new. The e2e only catches this
during that 5.5-hour window, so the regression guard has to be a unit spec —
those five cases hold whatever time it is.
## Not addressed here
**The `NG0100` noise in the job log is unrelated.** Those `ng-untouched`
errors come from `ClientFormComponent` / `StaffFormComponent` /
`GroupFormComponent` on pages visited earlier in each test, and they appear
identically on runs that pass.
**The same skew almost certainly exists elsewhere.** Any screen that derives
a date from the browser and sends it to a command Fineract validates against a
server-stamped date has this bug; groups is just where a test caught it.
`formatDateToFineract` compounds it — it does `new Date('2026-08-09')`, which
parses as UTC midnight and then reads `getDate()` in local time, so a user west
of Greenwich sends the wrong day. That is a shared utility with many call sites
and belongs in its own change.
--
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]
