Aman-Mittal opened a new issue, #289: URL: https://github.com/apache/fineract-backoffice-ui/issues/289
Part of #288. ## Business value This is the foundation sub-task. Every other product family reuses what it builds, so it lands first and alone. Today `accountingRule: 1` (NONE) is hardcoded in all five product forms. This adds the control that lets a user pick anything else, plus the one reusable component that renders GL-account pickers for whichever mappings the chosen rule requires. ## What to build **1. An accounting-rule selector.** Four options, from the platform's enum: | Value | Meaning | |---|---| | `1` | None | | `2` | Cash | | `3` | Accrual (periodic) | | `4` | Accrual (upfront) | Default stays `1` so existing behaviour is unchanged until a user chooses otherwise. **2. A shared `<app-gl-account-select>`** — a labelled picker over the GL accounts returned by the product template endpoint, filtered to a given account type (asset / liability / income / expense / equity). This is what every mapping field in sub-tasks 2–5 will be made of. **3. A shared container** that shows or hides the mapping fields based on the selected rule — nothing when `NONE`, the cash set for `CASH`, the cash set plus receivables for the two accrual rules. Put both in `src/app/features/products/` if they are product-specific, or `src/app/shared/components/` if they are not — your call, but say which and why in the PR. **Wire it into the loan product form only.** The other four forms come in later sub-tasks; touching them here makes the PR unreviewable and guarantees conflicts. ## Two things to get right 1. **Read the account options from the template endpoint, do not hardcode them.** `loan-product-form.component.ts` already calls the template for other option lists; the GL accounts come back on the same response. Hardcoding account ids would break on every tenant but the one you tested against. 2. **Editing an existing product must show its current mappings.** The load path in each form currently drops accounting entirely. If a user opens a configured product and saves it, the mappings must survive. This is the same class of defect as the deposit-product edit path, which silently overwrites the rate chart — do not add a second one. ## Testing - **Unit spec:** selecting each rule shows the expected mapping fields and hides the rest; the submitted body carries `accountingRule` and the mapped account ids; loading a product with existing mappings populates them. - **Unit spec:** with rule `NONE`, the submitted body contains no mapping keys at all — a stray `null` mapping is a validation error from the platform. - **Mocked e2e:** intercept the product `POST` and assert the body. Use the `Probe` pattern in `e2e/client-servicing-gaps.spec.ts`. ## Scope In scope: the selector, the shared picker, the show/hide container, and wiring into the loan product form. Out of scope: savings, deposit and share products; advanced mappings (payment channel, fee and penalty income) — that is sub-task 6. ## Getting started - `src/app/features/products/loan-product-form.component.ts` (large file, under active development — rebase before opening the PR) - Agree the component API on this issue before writing much of it; four later sub-tasks depend on the shape. -- 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]
