9768 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
niteshandClaude Opus 5.5	f96705baa4	Merge branch 'feature/advanceLoanProduct' into merge/dds-advance-loan-into-dev-latest ... Adds the Advance Loan Product backend on top of the DDS merge of dev-latest: - Advance loan product ext entity, API and Liquibase (LoanProductAdvanceExtService; loan product API accepts and returns "advanceExtensions") - Fees-Penalty-Interest-Principal repayment transaction processor, enabled by fineract.loan.transactionprocessor. fees-penalties-interest-principal.enabled (default true) - Loan interest rate register backend Conflict resolved: - changelog-tenant.xml: kept both. The four advance loan changelogs (0571_create_loan_product_advance_ext, 0572_add_loan_product_advance_ ext_fields, 0580_create_loan_rate_register_tables, 0581_enable_loan_rate_register_maker_checker) go just before the DDS block, which its comment says stays last. Their numbers overlap dev-latest files but no file name is shared. Not taken from feature/advanceLoanProduct: - Commit b72657703 changed the default DB password in application.properties to a UAT database password. That merged without a conflict; the dev-latest password lines are kept so local setups keep working and the UAT password does not go into the repository. The new transaction processor property from the same file is kept. Nothing from dev-latest or DDS is removed: no file deleted; only LoanProductsApiResource (one supported parameter added), LoanProductConfiguration (one constructor argument added) and application.properties change existing lines. CommandWrapperBuilder, changed on both sides, has no duplicate methods. Verified with :fineract-provider:compileJava. Branch renamed from merge/dds-into-dev-latest, since it now carries both DDS and Advance Loan Product. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-12 15:29:13 +05:30
niteshandClaude Opus 5.5	9d6ef18929	Merge branch 'feature/dds' into merge/dds-into-dev-latest ... Brings the DDS (Daily Deposit Scheme) backend from feature/dds onto the current dev-latest: - Agent settlement (Agent Tran), Close Party account, reports (Supplementary-DDS, Master Data Export, Close Register), Party-Savings link, savings product category field - Collection entries held before posting, per-agent GL accounts, maturity auto close - Vouchers, maker-checker approvals, payout & close, Sundry GL, closure tab and fixes - POST_DDS_INTEREST job No content conflicts. No dev-latest file is removed; only three dev-latest lines are extended with a DDS condition: - CommandSourceService: DDS entities join ROLE in the maker-checker entity check (isDdsEntity). - PortfolioCommandSourceWritePlatformServiceImpl: a DDS entry can never be approved by the user who made it, even a checker super user. The rule for every other entity is unchanged. - SavingsProductDataValidator: productCategory accepted as a savings product parameter. Files changed on both branches and auto-merged: CommandWrapperBuilder, CommandSourceService, JobName, SavingsApiConstants, SavingsProductData, SavingsProduct, FixedDepositProductData, RecurringDepositProductData, DepositProductReadPlatformServiceImpl. Checked for duplicate methods, fields and enum names. Liquibase: 55 DDS changelogs (0470-0525) included as one block at the end of changelog-tenant.xml. Their numbers overlap dev-latest's files but no file name is shared, and Liquibase tracks changesets by file path, so nothing clashes. They keep their names so databases that already ran them do not run them again. No permission code, job name or configuration name is inserted by both branches. Verified with :fineract-provider:compileJava. The full compileJava fails only in fineract-client (generated CKYC, committee meeting and election APIs), which feature/dds does not touch. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-12 15:11:14 +05:30
niteshandClaude Opus 5.5	936e21dcf6	Merge branch 'feature/fd-interest-posting' into dev-latest ... Brings the FD interest posting work into dev-latest: - FD interest posting approval with pooled GL postings, posting period shown per line, maturity postings surfaced, double-posting guard - FD maturity approval report added and then reverted (maturity now runs directly through the scheduler, no approval step) - Pending user approval encodes the password and emails it - New-tenant user personalisation, with the 'system' username kept so scheduler jobs and COB can still find the system user Conflicts resolved: - SavingsAccountReadPlatformServiceImpl#retrieveAllSavingsDataForInterestPosting: kept both exclusions. Recurring deposits (deposit_type_enum 300) stay out of the generic interest posting job (dev-latest), and fixed deposits are also left out when FD interest posting approval is enabled (feature branch), so FD interest is not paid twice. Comments from both sides merged. - final-changelog-tenant.xml: kept dev-latest's 0592-0598 TDS and recurring deposit changelogs and added 0593_fd_interest_posting_approval.xml after them. The file keeps its name although its number clashes with 0593_tds_...: Liquibase tracks changesets by file path, so renaming it would re-run it on databases that already applied it. Changeset ids in the two files differ. Verified with :fineract-provider:compileJava. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-12 12:23:55 +05:30
niteshandClaude Opus 5.5	aceea89c5c	fix(tenants): keep the 'system' username when provisioning a new tenant ... Problem Commit 3d3ce92e9 personalised the three users seeded into a brand-new tenant database and renamed user id 2 from 'system' to '<tenant>_system' (for example 'default_system'). Fineract looks this user up by the fixed name AppUserConstants.SYSTEM_USER_NAME ('system') through AppUserRepositoryWrapper.fetchSystemUser(), so on every fresh tenant: - every scheduler job failed once a minute with "UserNotFoundException: User with name 'system' does not exist" (seen with the Send Asynchronous Events job); - COB initialisation, savings escheat, current account closure and the stuck-job listener would fail in the same way. Existing tenants were not affected because the provisioner only runs right after the very first migration of a new tenant. Fix - TenantInitialUserProvisioner now sets user id 2's username to AppUserConstants.SYSTEM_USER_NAME and only replaces its password. - Admin and interop users are still personalised as '<tenant>_admin' and '<tenant>_interop'. - Javadoc and the startup log line now say the system user keeps its name and why. Resulting users on a new tenant - <tenant>_admin (password: initial-user-password or built-in default) - system (same password, name unchanged) - <tenant>_interop (same password) Tenants already created with '<tenant>_system' need a one-off fix: UPDATE m_appuser SET username = 'system' WHERE id = 2; Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-12 11:55:18 +05:30
keshav	99ef5edfd8	Merge branch 'dev-latest' of https://git.lincpay.tech/CBSNexora/cbsnexora-backend into dev-latest	2026-10-12 10:25:19 +05:30
keshav	9df8e924a1	feat: recurring deposit product rules, lien, auto debit, missed installment penalty, and jobs	2026-10-12 10:25:12 +05:30
niteshandClaude Sonnet 5	1fd94615a9	revert(fixed-deposits): remove FD maturity approval report ... A fixed deposit's maturity is settled directly by the nightly updateMaturityDetails job again, unconditionally, for every deposit type and every closure instruction — the approval gate this introduced turned out to risk more than it protected and is being removed before it ever shipped enabled by default. Removes the fdmaturity package entire (report service, orchestrator, API resource, noon-generation job), its migration and global configuration, the day-close integration in BranchDayRegisterApiResource, and FixedDepositAccount#previewMaturityInterestPeriods, which existed only for this report's preview and has no other caller. The periodic FD interest posting approval report (0593) is untouched — a matured deposit's final interest, paid directly by the nightly job, already surfaces there under "Posted outside approval", same as it did before this report existed. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-09 12:50:11 +05:30
niteshandClaude Sonnet 5	3d3ce92e93	feat(tenants): personalise seeded user credentials for a brand-new tenant ... Adds TenantInitialUserProvisioner: right after the very first Liquibase migration of a tenant that was never on Flyway, renames the three seeded users (ids 1-3, otherwise shipping as mifos/system/interopUser with the public default password) to <tenantIdentifier>_admin/_system/ _interop, with a password from fineract.tenant.initial-user-password or a built-in default. An existing (Flyway-era) tenant already has its real users and is left untouched. Wired through TenantDatabaseUpgradeService and its two test configurations. Also fixes the two pooled interest-posting services' system-user lookup, which read username = 'system' — now wrong since that username is personalised per tenant — to find the seeded system user by its fixed id (2) instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-08 22:41:25 +05:30
niteshandClaude Sonnet 5	1a914a3de0	feat(fixed-deposits): maturity approval report, scoped to deposits with no closure instruction ... Adds the FD maturity approval workflow: a deposit with no closure instruction of its own (Maturity Instructions left "Not selected") waits — status, final interest and whatever renewal is later chosen from the FD Dashboard all run together in one real maturity run, only once a second user approves the report, as the branch closes its day. A deposit that already named Transfer to Savings or a Reinvest option settles itself the moment it matures, unchanged — a decision the customer already made in writing needs no second approval. The nightly job is narrowed to skip only the undecided ones; FixedDepositAccount#previewMaturityInterestPeriods reads the same maturity-interest calculation the real posting uses, without writing anything down, so the report's figure is never a guess. Posting an approved report calls the existing, unchanged DepositAccountWritePlatformService#updateMaturityDetails per deposit, each in its own transaction — one with a bad closure target does not hold up the others, and a retry only touches what did not post last time. Adds a reconciliation view (outside-approval) listing deposits that matured via their own closure instruction, same reasoning as the interest report's: found by what has no report line, not by naming the instruction, so a future direct path is caught here too. Day-close integration mirrors the interest report exactly: blocks on a pending maturity report, posts approved ones alongside approved interest reports, independently so one failing does not stop the other. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-08 19:06:40 +05:30
niteshandClaude Opus 5	6e7eb94776	fix(users): encode password and email it when approving a pending user creation ... finalizeCreateUser() (run when a checker approves a CREATE_USER request queued in m_user_pending_request) saved AppUser.fromJson()'s result straight to m_appuser via appUserRepository.saveAndFlush() with no encoding step for the password AppUser.fromJson() auto-generates when the maker ticks "send password to email" -- AppUser's constructor stores whatever string it is given verbatim, so that random password was landing in m_appuser.password as plain text. Only the maker-chosen-password case (request.getPasswordHash() != null) was ever hashed, because that happens earlier, at submitCreateUser() time. It also never called the email service at all, in either case. The live create-user flow (JpaUserDomainService.create()) captures the unencoded password, encodes it, saves, then emails the welcome message -- finalizeCreateUser() duplicates everything up to the save but stops there, so a user created through this maker-checker flow never received their credentials regardless of what sendPasswordToEmail said in the submitted payload. Fix: capture the auto-generated plaintext right after AppUser.fromJson(), encode it with this class's own PasswordEncoder bean (already used the same way for the maker-chosen-password branch, consistent within the file) before saving, and call PlatformEmailService.sendToUserAccount() afterwards when sendPasswordToEmail was true and no maker-chosen password overrides it. A maker-chosen password is unrecoverable by approval time (submitCreateUser() redacts it to "[PROTECTED]" immediately), so that case still cannot be emailed, and isn't -- there is nothing wrong to fix there. Found by manually submitting a CREATE_USER request locally and reading both AppUser.fromJson() and the approval path end to end; no existing approved user was re-created to verify in place, since doing so would need resetting a real password. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-10-08 19:03:17 +05:30
niteshandClaude Sonnet 5	6fbc3a85a8	feat(fixed-deposits): show the period each posting covers, surface maturity postings, guard against double-posting ... Adds interest_period_from to the report line so each posting shows the span it covers (e.g. "01 Oct - 31 Dec, Quarterly"), not just the date it ends on, and a postingPeriodLabel on the report itself. Adds a reconciliation endpoint (outside-approval) that lists fixed deposit interest posted without this report's approval — chiefly a deposit that matured before its own posting cycle completed, whose last period the maturity job settles directly. Read-only, so a branch can see every rupee of deposit interest it has paid, approved or not. Guards posting itself against the same situation: before crediting a line, checks whether its deposit already carries an interest posting for that exact date (raised by the maturity job in the window between this report being generated and being posted). If so, the line is linked to what actually paid it instead of being paid again, and its amount is reconciled off the report's approved total rather than failing the whole posting. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-08 00:06:14 +05:30
niteshandClaude Sonnet 5	949f45c4cd	feat(fixed-deposits): FD interest posting approval with pooled GL postings ... Adds a maker-checker approval report in front of fixed deposit interest posting, mirroring the existing savings interest posting report: a report is generated per branch and product (SINGLE/DOUBLE/SPECIAL), a second user approves it, and it posts when the branch closes its day. Day close is blocked until deposit interest due that day is approved. Ledger entries are pooled per the report's interestPostingDate rather than raised per deposit: Dr Interest Expense and the Payable/Paid legs are each raised once for the group's total, and only the final leg crediting each deposit's own GL is per account — the same pattern the savings interest posting report already uses, instead of repeating the full three-stage chain for every deposit. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-08 00:06:00 +05:30
sonali	39e3fcec59	feat: add loan interest backend functionality	2026-10-07 15:29:18 +05:30
nitesh	1922455996	Merge branch 'dev-latest' of https://git.lincpay.tech/CBSNexora/cbsnexora-backend into dev-latest	2026-10-07 10:18:27 +05:30
keshav	cca4ae583f	Merge branch 'dev-latest' of https://git.lincpay.tech/CBSNexora/cbsnexora-backend into dev-latest	2026-10-07 10:14:13 +05:30
keshav	99a7e04872	feat: updates for tds services, rbi reserve config, and cashier api resources	2026-10-07 10:14:04 +05:30
niteshandClaude Opus 5	ac7873a51e	feat(shares): add preview-validate endpoint, fix document attachment 500 ... ClerkShareWithdrawalRequestApiResource: extracted validate(Long)'s checklist logic into buildShareWithdrawalChecks(Map<?, ?>) and added a new POST /preview-validate endpoint that runs it against a draft submission (same fields submit() accepts, same Sundry-downgrade rule applied first) instead of an already-persisted request. Lets the clerk see the exact checklist a manager will see on approval before the request is even submitted, with zero risk of the two checklists drifting apart, since both now call the same method. The one check validate() runs that a draft cannot -- "Maker and Checker are different users" -- is reported as a fixed reminder instead of silently dropped, since the clerk previewing this is necessarily the maker and no checker has been chosen yet. DocumentReadPlatformServiceImpl.retrieveDocumentContent(): a document/signature whose m_document row survives but whose underlying file is missing from the content store (the usual cause is a database copied between environments without its file store) was throwing an uncaught ContentStoreException, surfacing as a raw 500 on every fetch. Now caught and converted to the same DocumentNotFoundException (404) ImageReadPlatformServiceImpl already uses for the identical situation on client photos, so the frontend's existing graceful-fallback handling for a missing attachment applies here too. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-10-06 22:40:12 +05:30
niteshandClaude Opus 5	643427bd1a	fix(shares): correct share transaction lookup and validate NONE settlements ... redemptionValueOf() read from "m_share_account_transaction" with a "share_account_id" column. The table is m_share_account_transactions and the column is account_id, so every share withdrawal approval failed with a BadSqlGrammarException on the Share Sundry balance guard, before any posting was attempted. The lookup now also filters on is_active, matching ShareAdvanceCollectionApiResource.shareValueOf(), so a reversed purchase cannot price a redemption. validate() branched on "GL" versus everything else, but approve() handles a third settlement mode: submit() downgrades a request to NONE when the clerk names the product's own Share Sundry GL as the destination, and that mode posts Dr Share Capital / Cr Share Sundry and stops. Validating it as a savings settlement reported a missing fund source mapping that no posting in this mode ever reads, so a correct request showed a failed check. NONE is now reported as not applicable for both the linked-savings and the fund-source checks. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-10-06 19:03:51 +05:30
niteshandClaude Sonnet 5	6c7c0f8445	build: freeze the default (non-release/maintenance branch) jar version ... git-versioning's rev{} fallback previously derived the SNAPSHOT version from the nearest reachable git tag (major.(minor+1).0-SNAPSHOT), so the built jar's name drifted as tags moved. Pins it to a fixed 1.15.0-SNAPSHOT instead so the jar name stays predictable across builds on dev-latest/feature branches. release/*.*.* and maintenance/*.* branches still version off their own tags, unchanged. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-06 12:42:12 +05:30
niteshandClaude Sonnet 5	88157ee9d6	Revert "Enforce same-user maker-checker restriction" ... Reverts commits 2afd4aaf8 and 11a0d502b (both by anshul, same title). Restores the CHECKER_SUPER_USER self-approval bypass in CommandSourceService and the six *EditWritePlatformServiceJpaRepositoryImpl classes, and restores the original isSameMakerCheckerEnabled()/isCheckerSuperUser()-gated same-user check in PortfolioCommandSourceWritePlatformServiceImpl. Removes the 0588_persist_manually_enabled_maker_checker_permissions.xml migration added alongside the restriction. The unconditional same-user block these commits introduced was blocking legitimate single-admin operation/testing (e.g. creating and then activating a client as the same CHECKER_SUPER_USER), with no way to resolve it from inside the app. 11a0d502b's only change (0012_seed_default_platform_api_client.xml comment wording) is a no-op here: that exact text was independently reworded again by 82336cbe9 after 11a0d502b landed, so there is nothing left of 11a0d502b's change to revert in that file. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-06 10:02:34 +05:30
niteshandClaude Sonnet 5	760fff8d3e	fix(permissions): persist manually-enabled Teller/Cashier maker-checker settings ... Same pattern as 0588_persist_manually_enabled_maker_checker_permissions: converts a manually-applied Configure Maker Checker Tasks change into a repeatable migration, this time for the Teller/Cashier module. Found by diffing can_maker_checker across every permission code common to fineract_lincpay and a reference environment -- ALLOCATECASHIER_TELLER, ALLOCATECASHTOCASHIER_TELLER, SETTLECASHFROMCASHIER_TELLER, and UPDATECASHIERALLOCATION_TELLER were true there but still seeded false here, confirming they were toggled on manually and never captured for any other environment (including UAT). The _CHECKER permissions already exist and are already granted to Clerk/Teller/Branch Manager, so approval works as soon as this migration runs -- no role-grant changes needed. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-05 16:29:26 +05:30
Sonali LikhitkarandClaude Sonnet 5.5	b726577031	Update default DB password in application.properties ... Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>	2026-10-05 16:15:03 +05:30
Sonali Likhitkar	d1e94fd6a3	Add Fees-Penalty-Interest-Principal repayment transaction processor	2026-10-05 16:13:35 +05:30
keshav	d7ff4e4a7b	Merge remote-tracking branch 'origin/dev-latest' into dev-latest	2026-10-05 12:43:38 +05:30
keshav	7068d65422	feat: teller uniqueness, cashier allocation office check and interest posting report updates	2026-10-05 12:42:44 +05:30
nitesh	fd827dec27	fix(accounting,branchday): 3-stage FD interest posting in scheduler, fix branch day close business date validation	2026-10-04 16:02:25 +05:30
nitesh	aa264097e7	fix(savings,accounting): fix premature interest calculation date bounds and load interest payable GL mapping on edit ... Details of changes: 1. Premature Closure 1-Day Shortfall Fix (FixedDepositAccount & RecurringDepositAccount): - In calculatePreMatureInterest, explicitly reset transaction end-of-day balances to preMatureDate before invoking calculateInterestPayable. - Ensure end-of-day balances are restored to current business local date in a finally block. - Resolves the issue where premature closure missed 1 day of interest (e.g., -17.80 clawback) due to transaction end-of-day balances defaulting to the previous day when premature date matched current business date. 2. Interest Transfer Exclusions (SavingsAccountInterestPostingServiceImpl): - Exclude interest-transfer withdrawal transactions from non-interest posting transactions and end-of-day cumulative balance updates for fixed deposits transferring interest to linked accounts. 3. Interest Payable GL Load on Edit (AccountingConstants & ProductToGLAccountMappingReadPlatformServiceImpl): - Added INTEREST_PAYABLE(17) enum constant to CashAccountsForSavings in AccountingConstants. - Mapped CashAccountsForSavings.INTEREST_PAYABLE to SavingProductAccountingDataParams.INTEREST_PAYABLE in ProductToGLAccountMappingReadPlatformServiceImpl. - Fixes the bug where Liability -> Interest Payable Account GL was not loading in the product edit form (e.g., /products/fixed-deposit-products/:id/edit) even after being saved.	2026-10-04 11:54:28 +05:30
nitesh	16c67f6701	feat: Fixed Deposit - premature close logic, deposit account closure type, transaction validation, domain service and read service updates	2026-10-04 09:12:17 +05:30
nitesh	e846892e9f	Merge branch 'feature/bugfix' into dev-latest ... Brings in the backend counterpart of "Enforce same-user maker-checker restriction". Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> # Conflicts: # fineract-provider/src/main/resources/db/changelog/tenant-store/parts/0012_seed_default_platform_api_client.xml # fineract-provider/src/main/resources/db/changelog/tenant/final-changelog-tenant.xml	2026-10-01 13:25:29 +05:30
keshav	56d98bac8d	feat(rbi-reserve,savings): add Form1/Form9 returns, interest posting report and branch-day enhancements	2026-10-01 13:07:58 +05:30
tarunmalviya	b0e3c0ac8b	DDS: vouchers, maker-checker approvals, payout & close, Sundry GL, closure tab, fixes	2026-10-01 12:47:48 +05:30
niteshandClaude Sonnet 5	0d6066e0b6	fix(useradmin): strip password placeholder from a pending-edit replay payload ... A pending user edit's stored payload keeps a "[PROTECTED]" placeholder for the password rather than the real value. The actual new password is applied separately via request.getPasswordHash(), so the placeholder must not reach AppUser.update() or it tries to re-encode the literal placeholder string. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-01 12:13:02 +05:30
niteshandClaude Sonnet 5	4499b8afad	fix(accounting): post GL entries for a negative (clawback) interest transaction ... A premature FD closure that reprices interest downward (e.g. a pre-closure penalty) posts the difference as a negative interest-posting transaction -- a clawback of interest already recognised in earlier periods. Both the cash- and accrual-based accounting processors only posted journal entries when the transaction amount was greater than zero, so a clawback updated the FD subledger but silently posted nothing to the General Ledger, leaving the two out of sync. Treats a negative amount as a mirror-image reversal: positive magnitude, debit/credit legs swapped -- the same mechanism already used for isReversal. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-01 12:12:51 +05:30
niteshandClaude Sonnet 5	11a206f42a	feat(deposits): RBI premature closure compliance, simplified to always use the contracted rate ... Adds a Closure Reason to premature FD closure (Normal, Premature Extension, Conversion to Another TD, Deceased Settlement, Nominee/Legal-Heir), persisted as an RBI audit trail on m_deposit_account_term_and_preclosure. RBI-mandated reasons auto-waive the pre-closure penalty regardless of the maker's own checkbox; the maker can also waive it explicitly for any other reason. Interest rate for a premature closure is always the deposit's own contracted rate -- the same one its regular scheduled postings use throughout its life -- rather than a slab re-lookup against the actual period held. An earlier "actual-period vs contracted" toggle was built, tested, then deliberately removed per explicit request: simpler, and avoids disagreeing with interest the account was already accruing all along. Also fixes a real bug found while testing this: a renewed FD term's premature- closure interest was including the previous term's closing transaction a second time (it's dated the same day the new term starts), understating the first day's balance by the whole prior term's payout. Scoped the interest calculation to transactions strictly after the current term's start date. Known open issue: a renewed/auto-renewed account can still show a materially wrong (sometimes negative) premature-closure interest figure in some cases (seen on account 10, a QUARTERLY-posting auto-renewed FD) -- root cause not yet confirmed; needs further investigation with debug instrumentation before this is considered fully correct for every renewal shape. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-10-01 12:12:40 +05:30
anshul	11a0d502be	Enforce same-user maker-checker restriction	2026-10-01 12:03:32 +05:30
anshul	2afd4aaf83	Enforce same-user maker-checker restriction	2026-09-30 17:07:16 +05:30
anshul	e5dd6af366	Merge dev-latest into feature/bugfix	2026-09-30 16:47:41 +05:30
niteshandClaude Sonnet 5	ce8bb7e5ca	fix(products): named GL account changes (e.g. Savings Interest Payable/Paid) were silently lost on a pending edit ... Root cause: ProductPendingEditFieldMapper.populateCoreFields() captured otherGlMappings with stringValueOfParameterNamed(), which only handles a JSON string primitive. The maker's edit actually submits otherGlMappings as a nested {assets,liabilities,expenses,income} object -- the same shape SavingsProduct#update() already reads correctly via jsonFragment() -- so the pending-edit row was staged with this field blank every time, regardless of what the maker changed. Two consequences, both now fixed: - The checker's diff dialog showed "No changes to review" even when a GL account mapping (e.g. Savings/Current/FD/RD Interest Payable or Paid) was genuinely changed, since the submitted value never made it into proposedChanges. - Approving the edit replayed a payload with no otherGlMappings at all, so the GL account change was silently dropped rather than applied -- the edit showed as approved, but the product's accounting mapping never actually moved. Fixed the write side (jsonFragment instead of stringValueOfParameterNamed) and the read-side replay (writeCoreFieldsToJson now re-adds the stored value as a parsed JSON element via the new putJsonFragment, not a quoted string, which would have double-encoded it on replay). Shared by Savings, Current, FD and RD products, since they all go through this one mapper. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-30 12:39:58 +05:30
niteshandClaude Sonnet 5	82336cbe98	fix: remove illegal -- from migration 0012's XML comment ... Same mistake as an earlier migration this session: a literal "--" inside an XML comment is illegal per the XML spec and crashes the entire backend startup (Liquibase's XML parser rejects the whole changelog, not just this file). Reworded the prose to avoid it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-30 12:00:59 +05:30
Sonali Likhitkar	22c4403a14	feat(loan-product): add advance loan product ext entity, API and liquibase	2026-09-29 17:56:50 +05:30
niteshandClaude Sonnet 5	9436eab129	feat(security): seed a fixed default platform API key via migration instead of a random one at runtime ... Replaces the previous DefaultApiClientBootstrapper (ApplicationRunner minting a random key on first startup) with a plain Liquibase seed on the tenant-store database: one fixed, well-known api_key_hash row, inserted once via migration 0012, same on every deployment and every tenant -- exactly like this fork already seeds default codes/permissions, rather than generating a secret at runtime. The trade-off is explicit in the migration's own comment: a fixed key checked into source is a bootstrap convenience, not a secret, and any deployment beyond local/dev must rotate it (insert a new hash, deactivate this row) before going live -- rotation is a direct m_api_client write, same as the seed itself, since POST /v1/apiclients stays disabled. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-29 17:01:07 +05:30
niteshandClaude Sonnet 5	1408bddf58	feat(security): auto-mint the first platform-operator API key on deploy, disable minting one over HTTP ... A fresh deployment's m_api_client table starts empty, and reaching #/platform-admin/menu-access requires a valid X-Api-Key -- with no key, every tenant 401s identically (this is by design, not tenant-specific). Add DefaultApiClientBootstrapper: an ApplicationRunner that mints exactly one random key on first startup (guarded by "table still empty", so later restarts are a no-op) and logs the raw value once to the server's own application log -- never to the database, never over HTTP. Disable ApiClientAdminApiResource's POST /v1/apiclients entirely: it only required ALL_FUNCTIONS, a per-tenant role grant, so any bank's own super user (or a misconfigured role, as "Clerk" was found to carry it in two tenants this session) could mint themselves a platform-wide operator key and bypass the exact ceiling TenantMenuAccessApiResource exists to enforce. New keys past the first are now a direct m_api_client insert only. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-29 15:36:18 +05:30
anshul	e02ab51ee1	Merge branch 'dev-latest' into feature/bugfix	2026-09-29 10:21:21 +05:30
nitesh	3a37a5f90f	Merge branch 'feature/bugfix' into dev-latest ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> # Conflicts: # fineract-provider/src/main/resources/db/changelog/tenant/final-changelog-tenant.xml	2026-09-28 18:36:12 +05:30
niteshandClaude Sonnet 5	e7417d16a6	chore: renumber migration 0585 to 0587 ahead of feature/bugfix merge ... feature/bugfix independently used 0585/0586 for unrelated migrations (loan COB catch-up, system module checker permissions), colliding with this session's own 0585 file. Renumbered to the first free slot after theirs so both sets of changesets coexist without ambiguity; content and semantics are unchanged, only the file name and changeset ids moved. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-28 18:35:11 +05:30
niteshandClaude Sonnet 5	24d3bf83bb	fix: correct Current-product OD columns, PortfolioProductType mapping, and duplicate Bank Transfer voucher ... - Add migration 0585 to add the OD-scheme columns to the correctly-named pending-edit shadow table (m_saving_product_temp, singular), fixing migration 2033's typo that made it a permanent no-op and broke editing any Current product with OD fields set. - Fix PortfolioProductType.fromInt() to switch on each constant's declared value instead of declaration position, which silently mis-mapped ids 3-5 and NPE'd on id 6 (CURRENT), crashing Journal Entries for Current-account GL rows. - Stop generating a second Bank Transfer voucher at approve time; reuse the one already created at raise/submit time instead, eliminating duplicate vouchers for the same transfer under two different users' names. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-28 17:53:25 +05:30
anshul	af052dcb4f	Merge branch 'dev-latest' into feature/bugfix	2026-09-28 17:22:25 +05:30
keshav	b12268e740	feat: add RBI Form A and Form 9 SLR filing APIs, jobs, and migrations	2026-09-28 13:35:32 +05:30
anshul	6ee3bbe67c	feat: add command handlers, permissions, and API resources for surveys and loan COB catch-up	2026-09-28 12:55:21 +05:30
anshul	d8f6c25875	Merge branch 'dev-latest' into feature/bugfix ... especially if it merges an updated upstream into a topic branch.	2026-09-28 12:39:03 +05:30