Aman-Mittal opened a new pull request, #815:
URL: https://github.com/apache/fineract-backoffice-ui/pull/815
Three things, each measured against a running `apache/fineract:latest`.
## A mutated signal, and the shard failure it was causing
`floating-rate-form` added a rate period with `periods().push(...)`, which
mutates the array the
signal already holds. The signal's value never changes, so nothing is
notified — the row reaches
the screen only because this component runs with default change detection
and the `@for` is
re-evaluated on the next pass for unrelated reasons. `removePeriod()`
spliced the same array.
That made a row's arrival a matter of timing. `date-picker-revisit.spec.ts`
adds two periods and
counts the date pickers; it found one of them, **deterministically**, in
mocked shard 1/4 — on
`main` as much as on a branch, which I confirmed with a clean worktree. It
would stop arriving at
all under `OnPush` or without zones.
The spec was racing too: it read the picker ids immediately after adding the
rows. It now waits
for the count it expects, which is what makes the unique-id assertion mean
anything. The shard is
green.
## The rest of #758
#758 asked for one shared source of "tenant today" and the first pass
covered the seven create
forms the issue reproduced. The other forty-odd seeds now read the same
source, so no screen
dates a record by the browser's clock: the savings account view's three
stamped dates, the client,
group, centre, officer and disbursement dialogs, the working-capital
actions, the loan, savings
and both deposit transaction forms, the three charge due-date defaults, and
the office, staff,
journal entry, closure, reschedule, standing instruction, collection sheet
and rate-chart forms.
Report filters moved with them — a range defaulting past the tenant's today
answers an empty
report, which reads as no data rather than as a date problem.
Read synchronously: by the time any of these renders, the header has
resolved the date for the
session, and where it has not, `today()` answers the browser's date exactly
as the old
initialiser did. **No test changed** — all 2487 pass untouched.
`deposit-chart.ts` is deliberately left: a pure function module with no
injector, whose `fromDate`
is a request envelope rather than a user-facing default.
## The spec sync, and the two screens it caught
The spec in `apache/fineract:latest` has moved since 12 October (`7b23f0ae…`
→ `f9251770…`). Same
602 paths and 967 operations — nothing removed, no call site loses its
endpoint — but sixteen new
schemas, twenty-one operations that stop taking `object` or `string`, and no
more
`CommandWrapper`.
That precision caught two screens posting bodies the platform has always
refused:
**Email Messages could never send a message.** It posted `JSON.stringify({
to, subject, body })`
— a JSON string where an object belongs, with three field names the endpoint
does not accept:
> The JSON syntax provided in the body of the request is invalid: Expected
BEGIN_OBJECT but was
> STRING at line 1 column 2
The request is `{ clientId, emailSubject, emailMessage, locale }` — the
recipient is a *client*,
and the platform reads the address off their record. The free-text To field
becomes the client
search the rest of the app already uses, and the send now succeeds
(`resourceId: 2`) where the
old payload got a 400.
**An SMS campaign could not be activated.** `activate()` passed the string
`'activate'` as the
request *body* and sent no `command`. The command belongs in the query, the
body carries the
date: `?command=activate` with `activationDate`, and `?command=close` for
the counterpart.
Creating an SMS campaign is still refused, for a third reason the new DTO
makes visible —
`runReportId` and `paramValue` are mandatory and the form collects neither.
The payload is typed
now, which is what names the gap; filling it means asking for a report and
its parameters, which
is a change to the form rather than to this sync.
`public/api/fineract.provenance.json` is updated the way the weekly workflow
writes it, and
`verify-api-client` exits 0 against the committed client.
## Verification
- **2487 unit tests / 310 files** green, in UTC and under deliberate load
- mocked shard 1/4 green (the one that failed on `main`), and the picker
spec green alone
- backend e2e against a real platform: the date-default and double-submit
specs, plus the deposit
servicing set
- `lint`, `lint:prune`, `prettier --check`, `check-api-surface`,
`verify-api-client`, translation
check: all clean
--
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]
