niteshandClaude Sonnet 5
87f3e591ce
Fineract Build & Cucumber tests (without E2E tests) / verify (main, build-core) (push) Canceled after 0s
Fineract Build & Cucumber tests (without E2E tests) / verify (main, cucumber) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - MySQL / test (test-core-3) (push) Canceled after 0s
Fineract Build & Cucumber tests (without E2E tests) / verify (progressive-loan, build-progressive-loan) (push) Canceled after 0s
Fineract E2E Tests / E2E Tests (Shard 8 of 10) (push) Canceled after 0s
Fineract E2E Tests / E2E Tests (Shard 9 of 10) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - MariaDB / test (test-core-1) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - MariaDB / test (test-core-2) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - MariaDB / test (test-core-3) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - MariaDB / test (test-core-4) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - MariaDB / test (test-core-5) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - MySQL / test (test-core-1) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - MySQL / test (test-core-2) (push) Canceled after 0s
Fineract Docker Builds / build (false, docker-compose-postgresql.yml, postgresql) (push) Canceled after 0s
Fineract Docker Builds / build (true, docker-compose.yml, mariadb) (push) Canceled after 0s
Fineract Documentation build / build (push) Canceled after 0s
Fineract E2E Tests / E2E Tests (Shard 1 of 10) (push) Canceled after 0s
Fineract E2E Tests / E2E Tests (Shard 10 of 10) (push) Canceled after 0s
Fineract E2E Tests / E2E Tests (Shard 2 of 10) (push) Canceled after 0s
Fineract E2E Tests / E2E Tests (Shard 3 of 10) (push) Canceled after 0s
Fineract E2E Tests / E2E Tests (Shard 4 of 10) (push) Canceled after 0s
Fineract E2E Tests / E2E Tests (Shard 5 of 10) (push) Canceled after 0s
Fineract E2E Tests / E2E Tests (Shard 6 of 10) (push) Canceled after 0s
Fineract E2E Tests / E2E Tests (Shard 7 of 10) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - MySQL / test (test-core-4) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - MySQL / test (test-core-5) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - PostgreSQL / test (test-core-1) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - PostgreSQL / test (test-core-2) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - PostgreSQL / test (test-core-3) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - PostgreSQL / test (test-core-4) (push) Canceled after 0s
Fineract Cargo & Unit- & Integration tests - PostgreSQL / test (test-core-5) (push) Canceled after 0s
Fineract Liquibase Only mode - PostgreSQL / test (push) Canceled after 0s
Fineract Messaging Smoke Tests / Smoke Test with ActiveMQ (push) Canceled after 0s
Fineract Messaging Smoke Tests / Smoke Test with Kafka (push) Canceled after 0s
m_current_account and m_savings_account each keep their own identity sequence, so the same numeric id can be a real row in both. Every place that links a GL journal entry back to its account for display -- so the Journal Entries screen shows an Account No instead of a blank "-" -- was tagging entity_type_enum=2 (PortfolioProductType.SAVING) unconditionally, even when the account was actually a current account. Whenever a current account's id collided with an unrelated savings account's id, the entry resolved to the wrong one entirely: a customer's savings deposit could display someone else's current account number, or vice versa. Fixed at the write side, in every place found doing this: - ClerkDisbursementRequestApiResource (Bank Transfer, Collection, Disbursement) -- GlEntry now carries an isCurrentAccount flag, decided once where the account was already resolved, instead of being re-guessed. - ChequeBookIssuanceChargeService, ClearingJournalService, SponsorDDIssueRequestWritePlatformServiceImpl -- same pattern, each already knew savings vs current at the point it linked the entry; that answer is now threaded through instead of discarded. Also fixed on the read side: - JournalEntryReadPlatformServiceImpl: entity_type_enum=6 now resolves unambiguously to the current account; entity_type_enum=2 still falls back to savings_transaction_id (a reliable signal only a genuine savings transaction sets) before guessing, for older rows written before this fix. - JournalEntryReferralServiceImpl (AML referral resolution): the same ambiguity could attribute a suspicious-activity alert to the wrong client entirely -- a same-numbered stranger's account -- when a current account's entity_id collided with a savings account's. Resolved with the same entity_type=6 / savings_transaction_id precedence as the read-side fix. Not touched: JournalEntryAggregationJobReader (year-end aggregation batch job) has the same ambiguity for legacy entity_type_enum=2 rows, but only ever joins m_savings_account -- it has no current-account handling at all, standard-Fineract in origin. Extending it is a real feature addition, not a targeted fix, and touches a scheduled financial batch job this session cannot rebuild or run to verify; flagged for separate, deliberate work instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>