[I] ADR 0006: TELLER_API — a reach-only case, with no shape disagreement behind it (7 files) [fineract-backoffice-ui]

["Aman-Mittal (via GitHub)" <gi...@apache.org>]

Aman-Mittal opened a new issue, #687:
URL: https://github.com/apache/fineract-backoffice-ui/issues/687

   Split out of #686, which covered offices, staff and holidays. Tellers were in scope for that batch and dropped on purpose, and the reason is the useful part of this issue.
   
   ## There is no disagreement to fix here
   
   Checked against a running `apache/fineract`, the teller types are **right**:
   
   ```
   GET /tellers              → "startDate":"2026-10-02"   ← string, as GetTellersResponse declares
   GET /tellers/1/cashiers   → {"tellerId":1, …, "cashiers":[…]}
   ```
   
   - `GetTellersResponse.startDate` is declared `string` and really is one — unlike `GET /offices`, and unlike all three holiday dates.
   - `CashierData` agrees field for field with the payload (`startDate`, `endDate`, `isFullDay`, `staffName`, …).
   - `GetTellersTellerIdCashiersResponse` correctly models the envelope, and `cashiers-list.component.ts` already has a comment explaining it — read from `/tellers/{id}/cashiers` rather than the top-level collection, because the latter rendered empty however many cashiers were allocated.
   
   So this is not the case the other ADR 0006 contracts have made. It is the **entity-notes** case: a contract that earns its place on reach and on tightening optional fields, not on correcting a lie.
   
   ## What it would be worth
   
   Seven files stop importing the generated client:
   
   ```
   src/app/features/tellers/teller-form.component.ts
   src/app/features/tellers/teller-form.component.test.ts
   src/app/features/tellers/tellers-list.component.ts
   src/app/features/tellers/cashiers/cashiers-list.component.ts
   src/app/features/tellers/cashiers/cashier-form.component.ts            (also needs STAFF_API)
   src/app/features/tellers/cashiers/cashier-transaction-form.component.test.ts
   src/app/features/tellers/cashiers/cashier-transactions.component.test.ts
   ```
   
   `cashier-form` needs `STAFF_API` as well, which #686 adds — cashiers are staff allocated to a teller, so that dependency is the domain, not an accident.
   
   Operations with callers today: `list(officeId?)`, `get(id)`, `create`, `update(id)`, `listCashiers(tellerId)`, `createCashier(tellerId, draft)`. Nothing else — a contract wider than its callers is the speculative abstraction ADR 0006 warns against.
   
   ## Worth doing properly rather than mechanically
   
   Three things the migration should pick up, since they are the actual value when the types already agree:
   
   - **Flatten the cashiers envelope.** `listCashiers()` should answer `Cashier[]`, not the `{tellerId, tellerName, officeId, officeName, cashiers}` wrapper. The component currently does `data.cashiers ?? []`; that unwrapping is transport shape, and the enclosing teller fields are already known to the caller.
   - **Own the date format.** The teller forms send dates, so `dateFormat` and `locale` belong in the adapter — rule 2 in `DOCS/ADAPTERS.md`. Fineract parses strictly against the format it is told, so a form that owns that pairing is a form that can produce a 500.
   - **Make `status` branchable.** `GetTellersResponse.StatusEnum` is a real enum here, so the model should expose it as such rather than as a display string. #686's holiday status derives an `isPending` flag once in the mapper for exactly this reason — the loans list had been comparing English display text as control flow before `LOAN_API`.
   
   ## Acceptance
   
   - The seven files above are gone from `eslint-suppressions.json` after `npm run lint:prune` (444 → 437).
   - Specs mock the contract, not `TellerCashManagementService`.
   - `DOCS/ADAPTERS.md` records this as a reach-only contract, so the next reader does not infer a disagreement that is not there.
   - A mutation test on whatever the mapper decides — if nothing in the mapper is worth mutating, that is a signal the contract is too thin and should be reconsidered.
   
   Background: `DOCS/adr/0006-generated-api-boundary.md`, and the entity-notes section of `DOCS/ADAPTERS.md` for the precedent.
   


-- 
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: issues-unsubscribe@fineract.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] ADR 0006: TELLER_API — a reach-only case, with no shape disagreement behind it (7 files) [fineract-backoffice-ui]

["Aman-Mittal (via GitHub)" <gi...@apache.org>]

Aman-Mittal closed issue #687: ADR 0006: TELLER_API — a reach-only case, with no shape disagreement behind it (7 files)
URL: https://github.com/apache/fineract-backoffice-ui/issues/687


-- 
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: issues-unsubscribe@fineract.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org