Aman-Mittal opened a new pull request, #309: URL: https://github.com/apache/fineract-backoffice-ui/pull/309
Closes #291. Part of #288 and #292. Extends the accounting section from #306 to savings, fixed deposit and recurring deposit products — and fixes the three defects that made the two deposit forms unusable, which is why this is larger than "add some dropdowns". ## Three things that were broken Found while trying to write the edit round-trip test #292 asks for. All verified against a running platform. **Fixed deposit products could not be edited.** `charts` is mandatory on update as well as create, and the form invented one on every save — a single slab at 5% from today, with no ids: ``` PUT /fixeddepositproducts/2 (form's own body) → 500 Internal Server Error PUT /fixeddepositproducts/2 (no charts) → 400 "The parameter `charts` is mandatory" PUT /fixeddepositproducts/2 (its own chart, ids) → 200 ``` **Recurring deposit products could not be created *or* edited.** The form collected the recurrence and then deleted it on the way out, along with two `recurringDeposit…` spellings the API does not accept: ```ts delete payload['recurringEvery']; delete payload['recurringFrequencyType']; delete payload['recurringDepositFrequency']; delete payload['recurringDepositFrequencyTypeId']; ``` The accepted parameters are `recurringFrequency` and `recurringFrequencyType`. The 400 that came back named `recurringDepositFrequency` — the *entity's* field, not the parameter — which is what sent the original guess wrong. **Both load paths discarded the product.** They read six fields and hardcoded `depositAmount: 1000, // Fallback` and `accountingRule: 1`; the savings form re-seeded its four interest fields with the create defaults. These forms rebuild the request from that object, so an edit rewrote whatever it had not read — deposit amount, posting period, accounting rule, and every GL mapping under it. ## The slot lists Enumerated against the platform, not documentation. Savings takes **two passes** to see: supplying the first seven makes it ask for `overdraftPortfolioControlId` and `incomeFromInterestId` as well, which a single 400 never shows. | Family | CASH | Accrual adds | |---|---|---| | Savings | 9 | `feesReceivable`, `penaltiesReceivable`, `interestPayable` | | Fixed / recurring deposit | 6 | the same 3 | `interestOnSavings` is an **expense**, not income — interest on a loan is money coming in, interest on a deposit is money going out, and the platform refuses the wrong class with a 403. Deposit products take the savings set minus the three that need an account you can draw against: no write-off, no overdraft control, no income from interest. Both deposit families ask for exactly the same set, so they share one spec. Also marks `description` required on both deposit forms — the platform has always demanded it and the forms did not, so a save failed with a toast and no indication which field was at fault. ## Verifying it `e2e/deposit-product-configuration.spec.ts` covers the three broken paths against a real Fineract: create a fixed deposit product, **edit it**, create a recurring deposit product, and check the savings accounting section shows the cash slots and hides the receivables. | | | |---|---| | `deposit-product-configuration.spec.ts` (real backend) | 3 passed | | Full unit suite | 874 passed | | `npm run lint`, `npm run i18n:check`, `npm run build`, `tsc` | clean | ## Share products (#293) are blocked, not skipped `GET /shareproducts/template` answers **404** on this platform, so there is no tenant-provided rule list and no account options to render from — and #289 is explicit that hardcoding account ids "would break on every tenant but the one you tested against". The share product form's `accountingRule: 1` hardcode is left in place rather than replaced with a guess. Worth reopening #293 with that finding, or scoping it to read `/glaccounts` directly. While writing the e2e I also hit two known issues from the other direction: the list screens' action buttons are icon-only with no accessible name (#233), and an `ion-input`'s accessible name sits on the host rather than the inner `<input>` (#287). Both are worked around in the spec with attribute locators rather than fixed here. -- 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]
