Current account passbook hardcoded "LincPay Co-operative Bank Ltd." and had
no branch identification line at all, unlike the savings passbook which
pulls the bank name and branch/IFSC/MICR details from the Institution and
Branch Profile. Wire up the same OrganizationService lookup so the current
account statement shows real bank/branch details too.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Manager withdrawal-review screen always searched the Savings account
type regardless of the request's actual account_type, so reviewing a
Current-account withdrawal failed with "Account not found". Reuse the
existing SEARCH_ACCOUNT_TYPE_TO_AC_TYP mapping (already used by the
cashier lookup path) instead of a hardcoded 'SD'.
- Point the UI tenant id at utkarshbank (was lincpay) to match the new
backend tenant.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Payment showed for both Active and Matured FDs, even though an Active FD
already has Premature Close for closing early. Now Matured-only.
That also meant a genuinely matured, past-grace FD closed via the account's
own Payment button (rather than the FD Dashboard's Renew action) silently
skipped crediting its gap-period interest -- the date-locking and
gap-interest preview/crediting were gated behind dashboard-only data, not
the account's actual matured state. Both now key off the same
renewal-preview response regardless of entry point, so Payment and Renew
are functionally identical once an FD has matured, as they should be since
they're already the same dialog component.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Was a full-page form at a dedicated route, reached by navigating away from
the account -- now a popup dialog in the same visual language as the
Payment/Renew dialog, just in this Danger Zone action's own red accent.
Also fixes a real gap in the form it replaces: the premature amount/action
options never loaded until a maker happened to touch the date picker, since
the calculation was only ever triggered on value change, never on open.
Added a breakdown panel showing exactly how the shown Maturity Amount was
reached -- Deposit Amount, Contracted Interest Rate, Pre-Closure Penalty
(when applicable), and the resulting Interest Earned -- using data the
account-view page already had, since the calculation endpoint itself only
ever returns the final number.
Removed the now-dead full-page component/route target it replaces.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The table fell back to the backend's own default order (entry_date, id
ascending) until a maker clicked a column header, so the oldest entries
sat at the top on every fresh load. Defaults the table's sort to id
descending instead.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The preview panel said interest would go to "the linked Savings account"
without saying which one. Now shows its actual account number, both as its
own row and in the highlighted "paid to" line.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Removing the forced default on this hidden, backend-mandatory field fixed
a false "changed" diff on product edit, but also broke plain product
create -- there's no saved value yet for a brand-new product, so it went
in blank and the backend rejected it as missing. Now only skips the
default when editing an existing product (which always has its own saved
value); create still defaults to 1, same as before that diff-dialog fix.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Fetches current balance, gap days since maturity, the linked savings
account's rate, and the resulting gap-interest amount and projected new
balance, and displays them above the dashboard-renewal timing text --
so staff see exactly what a late renewal is about to credit before
confirming anything. Read-only; failure to load the preview doesn't
block the renewal itself, since the existing timing text already
explains the action.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The Payment dialog (Transfer to Savings / Reinvest Full / Reinvest Principal Only / Partial
Reinvest, works whether an FD is Active or Matured) already had a complete, correct backend
implementation for every closure type -- including one this session found and fixed a real gap
in on the backend side (Reinvest Principal Only silently stranded its leftover interest). Rather
than duplicating that logic in a second, narrower dialog, the FD Dashboard's Renew action now
opens this same dialog in a `dashboardRenewal` mode: every closure type is still available, but
the Closed On Date is computed from the product's grace window instead of picked freely
(backdated to the original maturity date within grace, today once it's passed, picker hidden so
it can't be moved off that value), and submit() calls the new gap-interest pre-step endpoint
first when past grace, before the same generic `payment` command every other caller already used.
Also: full visual redesign (bigger dialog, gradient header, per-option accent colors, refined
spacing) applied to both entry points since they're the same component now; removes the native
"Close" action from a Matured FD's Account Actions menu, since what happens at maturity now
goes through the nightly job or this dialog, not a separate close command that bypassed both.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Maturity Instructions can now be left unselected when opening a SINGLE/DOUBLE/SPECIAL FD --
a new "-- Not selected (decide later via FD Dashboard) --" option, plus a clear button next to
the field, since a maker had no way to go back to blank once something was picked. An account
left this way is never touched by the nightly maturity job; what happens to it at maturity is
decided later, manually, from the FD Dashboard's Renew action (see the backend/dashboard
commits) -- an explicit choice here still auto-processes on its own exactly as before.
Also fixes a real, separate pre-existing bug found in the same step: editing an existing
account never read back its own already-saved Maturity Instructions/transfer-target choice --
the Edit screen always opened onto a blank picker even for an account that genuinely had one
set, because it was being read from the wrong template object (the blank per-product default
template refetched from the Product dropdown, not the actual account+template response that
carries the account's own saved values).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Three separate bugs in the checker's "Proposed changes" dialog, found while adding the
Renewal Grace Period field above:
- The "current" side resolved an enum field's value against the wrong payload key
(preClosurePenalInterestOnTypeId, minDepositTermTypeId, etc. are exposed on the stored
product as an object under a differently-named field, e.g. preClosurePenalInterestOnType.id)
so it always read as blank -- these fields showed as changed on every single edit, never
just the ones a maker actually touched.
- Enum/option fields resolved their label against a naive `<field>Options` key that doesn't
match Fineract's actual (inconsistent) naming, so a genuinely changed field showed its raw
numeric id instead of the option a maker picked.
- Renewal Grace Period Days and other newer fields never appeared at all, because the
maker-checker pending-edit mirror table didn't carry them (see the backend commit for that).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Frontend half of the new per-product grace-period field: number input alongside the existing
term fields, and stops forcing real default values (1 / the first period-frequency option) onto
minDepositTerm/minDepositTermTypeId, two hidden fields nobody actually edits through this form
-- left blank like their max-/in-multiples-of- siblings already correctly were, so a governed
product edit's "Proposed changes" diff no longer showed these as changed on every unrelated edit.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
New screen (Deposits menu, repurposing the dead "FD Maturity Report" shell button): every
active Fixed Deposit positioned against its own maturity date (Matured / Due Soon / Upcoming /
On Track), computed client-side from maturityDate so it can never drift out of step with the
account. Reads the new lean maturity-dashboard backend endpoint.
A matured, renewable row (no maturity instruction chosen at account-opening, or an explicit
Reinvest instruction still waiting on its product's grace period) gets a Renew action wired to
the account's own Payment dialog -- see the FD account-view commit for that side of it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
SYMPTOM
A cashier could credit an FD or RD account with cash from Transaction
Entry and the money moved in instantly, with no Manager approval -
unlike a Savings/Current deposit from the same screen, which correctly
creates a PENDING request under Approvals.
ROOT CAUSE
confirmSubmit()'s maker-checker branch for a cashier deposit only
matched row.acTyp in ('SD','CA','CB','GL'):
if (!this.isClerk && !this.reviewMode && isDeposit &&
(row.acTyp === 'SD' || row.acTyp === 'CA' || row.acTyp === 'CB' || row.acTyp === 'GL')) {
this.submitCashierDepositRequest(row, ...);
return;
}
'FD' and 'RD' are their own distinct account-type codes in this
component (see creditEntryAccountType(): 'FD' -> 'FIXED_DEPOSIT', 'RD'
-> 'RECURRING_DEPOSIT', separate from 'SD'/'CA'/'CB') and were simply
never in this list, so a deposit into either fell through every later
branch (all of which are withdrawal/disbursement-only) straight to the
generic, unguarded direct POST at the bottom of confirmSubmit().
Found by tracing why a real FD funding deposit never showed up under
Branch Ops -> Approvals: it had posted directly, no request record
ever existed for it, and it later showed up as an unexplained cash
"Excess" in the Branch Day Register close (the money was physically
counted by the cashier via denominationBreakdown in the same direct
POST, but the approved-requests-only "book" total never counted it -
see the paired backend commit for the matching approve()-side fix and
how that stale data artifact was cleaned up).
FIX
Added 'FD' and 'RD' to the account-type list in that gate, so a
cashier's FD/RD deposit now creates a PENDING
m_cashier_deposit_request via submitCashierDepositRequest() exactly
like SD/CA/CB/GL already did. buildDepositPayload() needed no changes
- it already resolves accountType via creditEntryAccountType() and
sets savingsAccountId to the FD/RD account's own id correctly; only
this one gate condition excluded them.
SCOPE
This one condition, in this one method. Every other account type's
existing deposit/withdrawal behavior on this screen is unchanged.
IF THIS BREAKS SOMETHING LATER
- A cashier FD/RD deposit posting instantly again (no PENDING request
created) -> check this gate's account-type list still includes
'FD'/'RD', and that isClerk/reviewMode aren't being set unexpectedly
for a cashier session.
- The backend rejecting or misrouting the resulting APPROVED request
-> see the paired fix in CashierDepositRequestApiResource
(cbsnexora-backend), resolveDepositAccountCategory() /
executeFixedDepositDeposit() / executeRecurringDepositDeposit().
- A "Vault + Cashiers" vs "book" Excess reappearing in Branch Day
Register close for a specific FD/RD deposit -> that combination
(physically counted denomination with no approved request) should be
impossible with this fix in place; if it recurs, this fix (or its
backend half) has regressed.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
SYMPTOM
FD Single account create screen, Rate Calculator: entering a tenure
under 30 days (e.g. 27) and clicking "Find Rate" produced a Bad
Request - "The parameter `tenureInMonths` must be greater than 0."
ROOT CAUSE
calculateRate() (fixed-deposit-account-interest-rate-chart-step.
component.ts) always converted the Days-unit tenure to months before
calling the backend calculator:
tenureInMonths = Math.floor(enteredDays / 30)
For any tenure under 30 days this floors to 0, which the backend
correctly rejects (paired backend commit: "FD Single Rate Calculator
crashed for tenures under 30 days").
FIX
- fixed-deposits.service.ts: calculateFixedDepositInterest() -
tenureInMonths is now optional, added optional tenureInDays.
- fixed-deposit-account-interest-rate-chart-step.component.ts -
calculateRate(): for a Days-unit tenure >= 30 days, unchanged
(tenureInMonths = floor(days/30)); for < 30 days, sends tenureInDays
instead and leaves tenureInMonths undefined. Also fixed the
API-failure fallback's periodic-compounding math, which divided by
tenureInMonths directly and would have produced NaN once
tenureInMonths could legitimately be undefined - it now falls back
to (enteredDays / 30) when tenureInMonths is absent.
SCOPE
Only the Rate Calculator preview inside the FD Single/Double/Special
account create screen. Does not touch how depositPeriod /
depositPeriodFrequencyId get sent on actual account submission.
IF THIS BREAKS SOMETHING LATER
- The same 400 reappearing for a short FD Single tenure -> confirm the
Find Rate network call carries tenureInDays and NOT a zero
tenureInMonths; check calculateRate()'s branch choosing between the
two.
- A wrong maturity preview number specifically when the backend API
call fails and the frontend falls back to its own formula -> check
the `effectiveMonths = tenureInMonths ?? enteredDays / 30` fallback
line in calculateRate().
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Apply Collection and Apply Additional Shares settle the same Share Collection
receipts for the same member, so they are now deliberately the same screen.
Apply Collection takes exactly two receipts and no more: one for the share value,
one for the entry fee, in two separate slots. They are different things -- the
share receipt is money moving into share capital, while the fee receipt only
proves the fee was already collected and is never posted a second time -- and
picking both out of one ticked list made that distinction invisible.
Apply Additional Shares moves from its own route to a dialog. It was a full page
a clerk had to leave the account for and come back from, to fill in a short form
with the member standing at the counter. Its old route, resolver case and action-
host branch are removed rather than left behind as dead paths.
Both screens now draw their receipts from a single pool, whether a receipt
already names the member or is a voucher paid straight into a GL account; an
unattributed one is attached at the moment it is picked, so what used to be an
Attach in one table and a tick in another is one deliberate click. The by-voucher
search and the GL-entry detail both sit behind buttons, as exceptions rather than
permanent furniture.
Dialog chrome and the receipt shape are shared (share-dialog.shared.scss,
share-receipt-option.ts) so the two cannot drift apart again.
Also fixes content being clipped at the dialog edges: the wrapper cancelled a
24px surface padding that the panel class had already zeroed, pushing every edge
outside the surface where overflow:hidden cut it off, and the height cap sat on
the scrolling body rather than the wrapper, letting the footer stack past the
bottom of the viewport.
Adds the product-wise share summary report (authorised, issued, available and
unpaid shares, distinctive range and account count per product).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The GL Account / Voucher No lookup is for the exception -- a receipt the
unattributed list and the member's own list do not already carry -- so it now
sits behind a "Search a Voucher Not Listed Below" button in both Apply
Collection and Apply Additional Shares, opening the same lookup in a popup
(matching the existing receipt-detail popup) instead of occupying screen space
whether or not anyone needs it. A successful find closes the popup and the
result appears ticked in the list behind it, same as before.
- Add the full Share Reports surface (final balance, account statement,
issued/status/nominal/share-wise/guarantor/member-interest reports, enquiry,
payment certificate, share detail, dividend statement, folio statement,
distinctive numbers, area-wise, mailing labels/letters, share transfer) as
standalone routed components, wired into the Share menu
- Wire the unattributed Share Collection receipt list into Apply Collection
and Apply Additional Shares, with an Attach action independent of
account/client
- Sync the GL Account and Voucher No fields to whichever receipt is ticked or
found, and surface the receipt's real Dr/Cr GL entries in its detail popup
- Block Apply Additional Shares until the account's original application is
settled
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds an Entry Type field to Transaction Entry's GL-crediting rows (Receipt / Collection),
fetched from the backend's GLEntryType code, so the counter can flag what a GL credit is
actually for (General / Share Collection / DD Issue) instead of leaving every GL account
picker throughout Share Advance Collection guessing from the whole chart of accounts.
Apply Share / Additional Share screens:
- GL Account picker narrowed to accounts that actually have an eligible receipt, and only
auto-selected when exactly one candidate exists -- no more defaulting to whichever account
sorts first (Cash at Vault).
- Voucher tables show Description and Collected By, and a Detail view exposes the receipt's
real Dr/Cr GL legs instead of the GL Account dropdown's current unrelated selection.
- Additional Share funds from a single voucher (radio-style selection); ticking a receipt
syncs the GL Account picker to its own actual account.
- Checker's Additional Share Request review dialog gets the same Description + real GL entry
detail, expandable per voucher, so approval is never a guess about what will post.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Share Products:
- "Share Reference (Cash Vault or Suspense)" removed from the accounting step (create, edit,
preview and the read-only view tab) -- every register now books a share transaction against the
account the money actually reached, so no product needs a placeholder asset mapping any more.
The field is now optional server-side, not required.
Cashier:
- Removed the Share Collection screen and its three service methods. It read
m_share_account.cashier_collected, a column that has never existed in this schema, and no other
screen ever called it -- it could not have produced a working entry.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Transaction Entry (clerk):
- Route a two-row Fund Transfer of Dr SHR / Cr GL to the share-withdrawal
request with settlementMode GL, so a clerk can settle a share withdrawal
into any GL account instead of the member's linked savings account.
- Offer GL as an account type for Demand Draft funding, and submit it as a
GL debit (no client or savings/current account is involved).
My Work:
- Add a voucher detail dialog so a clerk can open a raised voucher from the
request list and see its GL lines.
Closing Cash Report:
- Fix the total row so it reflects the corrected opening balance.
DD Leaflet Registry and DD Inventory:
- Redesign both pages onto the shared usr-* visual language: gradient header
badge, status filter chips with counts, card-wrapped sticky-header table,
and one primary action per row with the rest behind an overflow menu.
Filtering, pagination and every action condition are unchanged.
- Register faHandPaper, needed by the new Stop Payment menu item.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Root cause of blank/clipped print output across the app: the document root
(html/body) is globally locked to one viewport height with overflow hidden,
and Angular Material's drawer/tab-body containers each add their own
on-screen scroll clip on top of that. main.scss now frees the full chain for
print (document root, CDK drawer/sidenav containers, mat-tab-body, and the
account-view's mat-tab-nav-bar which was rendering as a stray grey scrollable
strip since it isn't covered by the mat-tab-group header rule already hidden).
Also fixed both certificate print dialogs (share-certificate-dialog,
deposit-certificate-dialog) reusing a `::ng-deep body > :not(.cdk-overlay-
container)` rule to hide the shell during their own print: under Angular's
style encapsulation this style is emitted fully unscoped into the global
stylesheet and is never removed once the component has loaded once in a
session, silently blanking every other page's print output for the rest of
the session. Dropped `::ng-deep` from that one selector so it goes back to
being properly scoped (and therefore inert, matching the other two dialogs
that never had this bug) — the app shell is already hidden for every print
via the global main.scss rules, so no dialog needs its own global override.
Conflicts resolved in:
- src/app/clients/clients-view/ckyc-tab/ckyc-tab.component.html
- src/app/clients/clients-view/ckyc-tab/ckyc-tab.component.ts
Kept dev's CKYC architecture (upload dialog, real per-artefact endpoints)
and layered feature/bugfix's fixes on top: upload file validation,
missing-file badge, silent preview download, and image/PDF view button.
Also includes the CKYC "Image of Client" upload-state fix and the
client-change state-leak fix in the same component.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Certificate PDFs, the preview dialog, and both share-certificate list views
(demo + live) now pull bank name/address/reg no/seal text from the
Institution Profile instead of a hardcoded "Nexora" identity.
- Certificate preview dialog print CSS was clipped to the dialog's on-screen
scroll viewport (maxHeight config); switched to position:fixed + unclipped
overlay ancestors so the full certificate prints, not just a border sliver.
- Global print stylesheet now also hides the app shell's real 2-row nav menu
(.main-header/.kpi-ticker, not routed through <mifosx-toolbar>) and frees
the CDK sidenav/tab-body scroll clipping, so printing any page no longer
captures the nav chrome or gets cut off to one screen's height.
Same number in both fields defeats the point of having a second contact
route, and re-running DIP on an identical number is pointless. Added a
cross-field validator on alternateMobileNo, re-checked whenever mobileNo
changes, with a matching error message and the Verify-with-DIP button
disabled while the clash exists.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The CKYC tab's document cards now open a dedicated dialog (with client-side
preview) instead of expanding inline, collecting document type, number, and
issue/expiry dates the same way client creation does. Fixes several bugs
found along the way:
- Uploading a document type that's valid for both identity and address
(Aadhaar, Passport, etc.) no longer 404s or 500s — the "no such endpoint"
and case-sensitive ClientIdentifierStatus.valueOf("Active") crashes are
both resolved.
- Edit Client's Identity-proof and Address-proof steps no longer show each
other's document when both are dual-purpose OVD types, and no longer show
stale/mismatched front-back scans after a document type change.
- Address-proof's own document preview never showed a document at all when
no m_client_kyc record existed yet.
Document number and issue/expiry dates are persisted on the identifier
(documentKey + a shared "Issue date: ..., Expiry date: ..." description
convention) and read back by both the CKYC tab and Edit Client so the same
details appear everywhere.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Transaction Entry's manual GL-entry screen was recording its denomination
breakdown against whichever GL account the teller selected, not the vault
account whose physical notes actually moved -- resolve and use the Cash
Vault GL's own code/name dynamically instead
- Closing Cash Report's GL Entries table showed only the one account its
denomination row knew about; now shows both the debit and credit account
of each voucher (backend now returns debitParty/creditParty), matching
what My Vouchers already shows for the same entries
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Add Balance Sheet report and disabled-features accounting config
- Point menu-access tenant header and env.js/environment.ts tenant identifier
at env config instead of hardcoded 'default'/'lincpay' literals
- Surface the real backend error (not a generic "no reference id") when an
OTP send fails in contact-otp-block
- Fix branch-day "₹null" display bug (null vs undefined) and add a guard
blocking a branch's first-ever day open before cash denomination migration
- Dynamically size the denomination count input and block re-opening an
already-open business day from Migrate Cash Denomination
- Lock the denomination-managed cash GL row in Migrate Opening Balances
(read-only, with a link back to Migrate Cash Denomination)
- Remove duplicate Cancel/Submit action bars on the Share Product and
Savings Account creation preview steps; align Previous into the same row
- Hide "Apply Collection" on a share account once its advance collection
is already settled (further purchases go through Apply Additional Shares)
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds the frontend half of the per-tenant menu-access ceiling
(TenantMenuAccessApiResource on the backend): a bank cannot show a top-nav
section the platform operator has capped, no matter what any role inside
that tenant grants itself — closing the gap where a role carrying
ALL_FUNCTIONS (as "Clerk" was found to, in two tenants this session)
bypassed every ordinary MENU_.../SIDEBAR_... permission check.
- tenant-menu-access.service.ts: loads the current tenant's list once,
into a plain Set (not an Observable the directive would have to
subscribe to, since mifosxHasPermission's setter runs synchronously).
A failed load is treated as "nothing disabled" so a network hiccup on
login never hides the whole nav.
- has-permission.directive.ts: checks the tenant's ceiling first, ahead of
the ALL_FUNCTIONS bypass — that ordering is the actual fix.
- shell.component.ts/html: the nav now waits on the list being loaded
before rendering at all, so a disabled menu is never shown and then
hidden a moment later.
- New standalone platform-admin/menu-access screen (#/platform-admin/
menu-access), reachable without logging in — its own X-Api-Key is the
real boundary, checked on the backend, not this route. Lets the
operator pick any tenant and toggle its menu list. Redesigned per
request: full-width layout, icon-matched toggle tiles (same icon per
item as the real nav), live enabled-count, connection status.
- Loan Origination and Investment now use their own MENU_LOAN_ORIGINATION
/ MENU_INVESTMENT codes (see backend 0542) instead of sharing
MENU_ADVANCES / MENU_RBI, so all 27 nav items are independently
controllable from this screen.
Also: src/assets/env.js — restored 'socity_bank' to
fineractPlatformTenantIds. The tenant now exists in the tenant-store
database; the comment explaining its earlier removal was stale.
Brings in the Product Approval feature (anshul.rathore) — a unified Approvals
screen for Loan/Savings/Current/Share/FD/RD/Charge product requests:
- Merges two existing pending-request sources into one list: staged product
edits (m_saving_product_temp, via /{producttype}/pending) and native
maker-checker entries (/makercheckers) for product CREATE/DELETE and
LOANPRODUCT/CHARGE of any action.
- Checker Inbox no longer lists product requests at all — they now live only
in Product Approval, so a checker isn't checking two queues for the same
thing. Clicking a non-product row now navigates straight to that entity's
own view page when one exists, instead of always opening a detail dialog.
- View Checker Inbox dialog gains a caller-supplied heading (used when opened
from Product Approval) and a notice steering staged product edits back to
Product Approval instead of being actioned in place.
- Route renamed pending-savings-products -> product-approval, with the old
path kept as a redirect for existing bookmarks/links.
8 files conflicted with dev's own recent Checker Inbox work (popup-based
detail view, e8097bc2/63134f17) and were resolved by hand, keeping both
sides' real functionality rather than picking one branch wholesale:
- product-edit-diff-dialog.component.{ts,html,scss}: kept dev's diff dialog
(resolves GL account ids to names, aliases fields like currencyCode against
the stored product, normalises the two date shapes the API uses) over
maker-checker's simpler raw-value version.
- pending-savings-products.component.{ts,html}: kept maker-checker's full
isPendingEdit()-based dispatch (dev's version was a strict subset of it).
- view-checker-inbox.component.{ts,html,scss}: kept dev's per-entry Delete
action and maker-checker's recursive Command-payload tree renderer and
custom heading side by side.
Also recovered two regressions the merge introduced silently (no conflict
markers, so `git merge` gave no warning):
- tasks.service.ts lost deleteMakerChecker() entirely — restored.
- Checker Inbox's bulk Delete action (button, deleteChecker()/
bulkDeleteChecker(), and its .cv-btn-delete style) was dropped across three
files — restored to match dev's pre-merge behaviour exactly.
And one duplicate the merge produced without a conflict marker: two
independent viewEntry() implementations landed in checker-inbox.component.ts
(TS2393, caught at build). Kept maker-checker's entity-view-page-routing
version — a superset of dev's dialog-only version — and dropped the duplicate,
along with a leftover diagnostic console.log.
anshul
niteshandClaude Sonnet 5
keshav