niteshandClaude Sonnet 5
811c535d99
Two share-account charge bugs found while chasing why a share account's
entry-fee charge wasn't showing up in the "Apply Share Advance
Collection" flow:
- create-shares-account.component.ts / edit-shares-account.component.ts:
the submit payload built charges as { chargeId: charge.id, amount }.
A charge seeded from the product's own default template arrives as
ShareAccountChargeData, where the real charge id lives in `chargeId`
and `id` is null (no saved ShareAccountCharge row yet); only a charge
picked from this step's own "Charge" dropdown (plain ChargeData) has
it in `id`. So `charge.id` alone silently produced chargeId: undefined
for the common case (accepting the product's own default charges),
Angular's JSON.stringify dropped the undefined field, and the backend
received a charge with no id to attach -- the account got created with
zero persisted charges no matter what the product had configured.
Verified via the actual submitted command JSON in the DB
(charges:[{"amount":200}], chargeId missing entirely). Fixed by
falling back to charge.chargeId || charge.id in both places.
- shares-account-charges-step.component.ts: on the "edit an existing
account" flow, the account's real saved charges (possibly a correctly
empty array) get patched into chargesDataSource once the shared
currencyCode control settles, but that patch never cleared the
`pristine` guard. ngOnChanges fires again on the same input-update
cycle (the sibling Terms step, declared earlier in the wizard, patches
currencyCode from its own ngOnChanges, which synchronously triggers
this component's currencyCode subscription, and Angular then runs
this component's own ngOnChanges right after) -- with `pristine` still
true, that re-seeded chargesDataSource from the product's *current*
default template, silently overwriting the real (possibly empty)
saved state. Set pristine = false once the real charges are patched
in, so a later ngOnChanges can't clobber it.
Also: offices.component.ts now distinguishes an office delete that
actually completed from one that was queued for checker approval
(response.rollbackTransaction, the same signal every other
maker-checker-eligible screen in this app already keys off), instead of
always claiming "Office Removed" regardless of which happened.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>