Aman-Mittal opened a new issue, #300:
URL: https://github.com/apache/fineract-backoffice-ui/issues/300
Part of #299. Do this one first — it is the correctness fix.
## Business value
`run-report.component.ts` offers exactly three parameters — Office, From
Date, To Date — regardless of what the report being run actually declares. The
parameter-template endpoint that says which parameters a report needs is never
called.
The platform does not reject a report run with parameters missing. **It runs
it, and returns rows for the wrong scope.** So a branch manager filtering
portfolio-at-risk by loan officer gets a figure covering every officer, and
nothing on screen says so. A number that is quietly wrong is worse than a
screen that fails, because it gets acted on.
This is a correctness bug that happens to look like a missing feature.
## What to build
On selecting a report, call the report's parameter template and render a
control per declared parameter, driven by its `displayType`:
| displayType | Control |
|---|---|
| `select` | dropdown, options from the parameter's own lookup |
| `date` | date picker |
| `text` | text input |
| `none` / hidden | not rendered, value passed through |
Then pass every collected value on the run call.
**Read the run-reports signature very carefully.**
`src/app/api/api/runReports.service.ts:137` is:
```ts
getRunreportsReportName(reportName, exportCSV?, parameterType?, outputType?,
rOfficeId?, rLoanOfficerId?, rFromDate?, rToDate?,
rCurrencyId?, rAccountNo?, ...)
```
Seven consecutive optional strings. The current call site (`:303`) passes
them positionally, so **an argument in the wrong slot type-checks cleanly and
sends the wrong value** — `officeId` silently becomes `outputType`, `fromDate`
becomes `rLoanOfficerId`. Count the positions, and consider naming each
argument in a comment as `journal-entries-list.component.ts:136-151` does.
## Two things to get right
1. **A parameter the report declares but the UI cannot render must not be
silently dropped.** Either render something for it or tell the user the report
cannot be run here. Silently omitting it reproduces the exact bug this issue
exists to fix.
2. **Keep the three current parameters working.** Whatever reports people
run today must keep returning the same rows.
## Testing
- **Unit spec:** given a template declaring five parameters, five controls
render, one per `displayType`.
- **Unit spec:** collected values reach the correct positional argument.
Assert the full argument list, not just that the call happened — position is
the whole risk here.
- **Unit spec:** a report declaring only Office renders only Office.
- **Mocked e2e:** intercept the run call and assert the query string carries
the selected loan officer.
- **Backend e2e** (add to `BACKEND_SPECS` in `playwright.config.ts`): run a
report with two different values for a parameter and assert the row sets
differ. **This is the test that proves the bug is fixed** — one that only
checks the table renders would have passed all along.
## Scope
In scope: parameter discovery, rendering by `displayType`, and passing
values correctly.
Out of scope: cascading parameters (#301); output formats and renderers;
report definition CRUD.
## Getting started
- `src/app/features/reporting/run-report.component.ts`
- `src/app/api/api/runReports.service.ts`
- `npm run e2e:stack` for a live instance to inspect real template responses.
- `npm test`, `npm run lint:prune`, `npm run i18n:check`, `npm run build`
--
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]
