Aman-Mittal opened a new issue, #513:
URL: https://github.com/apache/fineract-backoffice-ui/issues/513
## What happens
`interest-pause-form.component.ts` renders its pickers immediately and
fetches the pause afterwards. When the response arrives it writes into the same
signals the user has been editing:
```ts
// :184
private loadPause(): void {
if (!this.loanId || !this.variationId) return;
this.pauseService.getLoansLoanIdInterestPauses(this.loanId).subscribe({
next: (pauses) => {
const pause = pauses.find(({ id }) => id === this.variationId);
if (pause) {
this.startDate.set(this.toFormDate(pause.startDate)); //
unconditional
this.endDate.set(this.toFormDate(pause.endDate));
}
},
```
Nothing disables the form while that request is outstanding and nothing
checks whether the user has already touched the fields, so on a slow link the
picked dates are replaced by the stored ones.
## Reproduced against a live platform
Loan 26, pause id 1 (2026-08-17 to 2026-08-27), with the populating `GET`
held for five seconds — a delay, not a fabricated response. Dates picked while
it was in flight:
The same screen once the response landed:
Read off the controls directly:
```
stored pause : 2026-08-17 .. 2026-08-27
user picked : {"start":"2026-10-10","end":"2026-10-20"}
after GET landed : {"start":"2026-08-17","end":"2026-08-27"}
```
[Screen
recording](https://github.com/Aman-Mittal/fineract-backoffice-ui/raw/assets/issue-screenshots/interest-pause-overwrite.webm).
## Why it matters
The reversion is silent and it lands on a form the user is about to submit.
Someone correcting a pause on a slow connection picks the right dates, watches
them change back, and — if they do not happen to be looking at that moment —
saves the values they meant to replace. The result is an unchanged relief
period that the operator believes they corrected, on a loan where the pause
range determines interest.
Five seconds is generous for a lab, but a field branch on a poor link is
exactly where this bites, and it is also the setting where a user is most
likely to start typing before the screen has settled.
## Suggested fix
Do not let a late response win over a user edit. Two workable shapes, in
rough order of preference:
1. **Do not show editable controls until the data is there.** A loading
state over the form removes the race rather than arbitrating it, and matches
what the screen is actually doing — it has nothing to edit yet.
2. **Only apply the response if the fields are still untouched**, tracked
with the form's own pristine state, and drop the response otherwise.
Whichever is chosen, guarding the submit button while the load is
outstanding is worth having too — the user can currently save before the form
knows what it is editing.
## Regression guard
A unit case that sets a date before the stubbed
`getLoansLoanIdInterestPauses` emits, then emits, and asserts the signal still
holds the user's value. The existing spec already controls that observable, so
it is a case rather than new scaffolding.
## Environment
`main` at `3c6d7479`. `apache/fineract:latest` via
`deploy/docker-compose-e2e.yml`.
Separate from #512, which is about a non-numeric `:variationId` on the same
screen, and from #496, which concerns how these dates are formatted on the way
out. All three are in the same component and would sensibly be looked at
together.
--
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]
