Every mobile-number lookup was calling out to a local mock HTTP service
on port 8090 that had to be started separately, so the check failed
with a connection error whenever that process wasn't running.
Ports the mock's full verdict table (suspected, disconnected,
suspected+disconnected, clean) into MobileLookupServiceImpl itself, so
the demo/test numbers resolve in-process with no HTTP call. Adds
fineract.mobile-lookup.enabled (default off) to skip the real DIP/MNRL
call entirely for local work; every number then resolves CLEAN and is
stamped LOOKUP_DISABLED_BY_CONFIG in the log so it's never mistaken
for a genuine pass. Must be turned back on before UAT/production.
/v1/currentaccounts/{id}/documents had no handler at all -- the
account's own /v1/currentaccounts resource matches the request path
first and has no documents method, so it never fell through to the
generic /v1/{entityType}/{entityId}/documents resource that every
other entity type relies on. Current accounts got a 404 on every
Documents-tab request.
Delegates straight to the existing DocumentApiResource so current
accounts get identical behaviour to clients, loans, etc.
Charges collected when a maker-checker Nominee/Digital-Feature edit is
approved deducted the account balance and appeared in the passbook,
but never posted a journal entry -- collectCharges() saved the charge
transaction directly and skipped the accounting bridge entirely, so
the GL never balanced against the subledger.
Also fixes an unrelated NPE this exposed: collectCharges() used
saveAll() instead of saveAllAndFlush(), so the new charge transaction
had no id yet when the journal-entry code tried to read it.
Activation for Savings, RD, FD and Current accounts no longer books an
opening deposit or enforces a minimum opening balance -- accounts go
active at zero balance and a clerk deposits funds afterward as a
separate transaction, matching how these branches actually operate.
Fixed Deposit and Recurring Deposit have their own override of
activateWithBalance() that a prior fix to the shared SavingsAccount
base class missed, so they kept auto-depositing after Savings was
already fixed. Removing that auto-deposit exposed two follow-on bugs
in the FD/RD activation flow, now also fixed:
- the opening deposit's journal entries were posted twice (once by the
deposit helper, once by the activation command's own posting call)
- FD/RD maturity amount was computed from the account's real (now
empty) transaction history at activation and never recalculated once
a deposit actually landed, so it showed no projected interest until
the account was reloaded from a lucky code path
Adds a lightweight loan-origination-pipeline module (application, stage history,
approvals, FI checks and documents) with server-side validation per stage
transition, so every field, upload and decision on the Loan Origination screen
survives a page refresh instead of living only in the browser.
Also fixes two content-store bugs found while wiring document uploads through
the generic Fineract document store: the CSV mime/extension whitelist rejected
bank-statement uploads outright, and the post-upload mime consistency check
rejected any CSV whose byte-content sniffs as text/plain (which is all of them,
since CSV has no distinguishing magic bytes).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Implement DIP/MNRL lookup logs table, filtering, and detail review under reports.
- Integrate DIP verification gating on client creation, allowing officers to record PROCEEDED/REJECTED decisions with reasons.
- Upgrade Sanctions verification dialog to support comparing Name, DOB, and Nationality particulars.
- Add Sanctions disposition recording (FALSE_POSITIVE / CONFIRMED_MATCH) awaiting Principal Officer approval.
- Add sanctions-alert-review-dialog for reviewers to assess and escalate/clear flagged names.
- Enforce strict screening reset logic on client name changes, preventing bypass of existing blocks.
- Update routes and shell menu navigation to include DIP/MNRL Lookups and Sanctions Logs.
Cash claims now mirror the existing clerk-withdrawal token flow: clerk
submits with a token, manager approval posts the GL entry, and a cashier
redeems the token at Transaction Entry to record physical hand-over --
no direct manager-to-member cash handover, and no double-disbursement.
Also fixes GL accounting for the loan/savings legs: instead of reversing
the native command's own debit with a second manual entry pair (leaving
the fund-source account confusingly appearing twice), that debit leg is
now rewritten in place to Dividend Payable. Floors cash claims to whole
rupees since notes/coins can't represent paise, with backward-compatible
tolerance for claims submitted before the fix.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Reworks the share dividend lifecycle end to end:
- Dividend amount now auto-computed from real GL profit x officer-entered percentage
instead of manual entry; adds a Dividend Paid report over the existing Dividend
Payable ledger.
- Declaration posts a real GL entry (Dr Reserve for Dividend / Cr Dividend Payable);
approval no longer credits any savings account up front -- every member's
entitlement stays a pure "Dividend Payable" liability until claimed, resolved
synchronously at approval time (no background job or per-member failure mode).
- New maker-checker Dividend Claim Request workflow: a clerk records how a member
wants their unclaimed dividend split (overdue loan / savings credit / cash), a
manager approves, which executes native repayment/deposit commands and replenishes
whichever GL account they actually debited (not a hardcoded assumption) from the
Dividend Payable liability.
- Unclaimed dividends carry a 3-year window (m_share_dividend_lock) after which a
daily job forfeits them straight to profit; a Dividend Dashboard consolidates
summary stats, every declaration's status, full lock history, and proactive
loan-application for members with overdue EMIs.
- Fixes a native negative-share-days bug in ShareProductDividendAssembler and adds
overlap-period validation so a product can't have two declarations covering the
same days.
- Removes the now-unreachable failed/pending-payout tracking that the old
per-member job-based model needed.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Closing a share account that already has zero approved shares no
longer synthesizes a redeem transaction, so it stops posting a
meaningless ₹0.00/₹0.00 GL journal-entry pair. Save/note-capture on
close now happen unconditionally instead of being gated on a
transaction existing.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Replaces the auto-submit-closure-request behavior with an immediate
account close, in the same @Transactional approval action, when a
redemption brings a share account's holding to zero — no separate
"Share Closure Request" maker-checker step is needed since the
redemption amount itself already went through this same review.
Removes ClerkShareClosureRequestApiResource entirely (the migration
for m_clerk_share_closure_request is left in place as a harmless,
now-unused table, to avoid a Liquibase checksum churn).
Also fixes a genuine Postgres-incompatibility bug this uncovered in
validateNoActiveLoanOrGuaranteeBeforeClosure(): `is_active = 1`
doesn't type-check against a boolean column on Postgres ("operator
does not exist: boolean = integer"), which was silently aborting the
whole approval transaction (harmlessly, since it's @Transactional —
verified no partial state was ever left behind). Fixed to `is_active
= true`, added the missing `type_enum = 1` (customer-type guarantors
only, matching the existing Guarantor Check elsewhere in this
workflow), and widened both this and the active-loan check to the
same loan_status_id set (300, 303, 304, 700) used there too.
Follow-up to the previous merge commit — the internal Liquibase
changeSet ids in the 9 renumbered files (0447-0455) still referenced
their old 0438-0446 numbers; the rename staged the files before the id
update was applied. Ids now match filenames as intended.
Resolved two conflicts:
- changelog-tenant.xml: both branches independently added Liquibase
parts numbered 0438-0446 (dev: Share Withdrawal/Closure governance +
KYC exception fields; demo: AML rule tiers/branch seeding/email
tracking/family-member children table). Renumbered demo's incoming
set to 0447-0455 (files renamed + internal changeSet ids updated to
match) so both feature sets keep their own migrations intact.
- 0434_seed_aml_transaction_rules.xml: same seed data on both sides,
differing only in the disambiguating SQL predicate. Kept dev's
`AND aml_check_status IS NOT NULL` (deterministically targets the
intended m_client_risk_rule row, per the file's own comment) over
demo's `LIMIT 1` (arbitrary, could pick the wrong row).
Also dropped two JVM crash-dump log files that got staged by mistake.
New ClerkShareClosureRequestApiResource mirrors the withdrawal resource:
clerk submits a closure request only once a share account holds zero
shares; a /validate endpoint re-checks shares-held, account status, any
active loan/guarantee, and client KYC/AML compliance; approve() executes
the real native "close" command.
ClerkShareWithdrawalRequestApiResource.approve() now also auto-submits a
PENDING closure request (via the same table) whenever a redemption brings
the account's share holding to zero, reusing the withdrawal's own maker
identity — a manager still has to separately Validate and Approve it, so
the closure request is created automatically but never executed without
review.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The /validate endpoint now re-checks live state that matters for a real
UCB share redemption: Client KYC verified, Risk Category not High, no open
AML alerts, and — since this bank supports loan-against-shares via
m_share_account.linked_loan_id — a Loan Check (no active loan secured by
these shares), Tenure Check (linked loan's term completed), and Guarantor
Check (client not guaranteeing someone else's active loan). Dropped the
redundant "status is PENDING" check and replaced raw status_enum codes
with human-readable labels throughout. getById() also now returns a
client compliance summary so the review screen can show it without
running the popup validation.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
New ClerkShareWithdrawalRequestApiResource backs a clerk-submits/manager-
approves flow for share redemption: on submit, validates and persists the
clerk-chosen settlement Payment Type (must be non-cash) plus a full audit
snapshot of the settlement row; on approve, executes the real "redeemshares"
command and, in the same transaction, credits the redemption value to the
share account's linked savings account using that stored payment type (with
a hardcoded-lookup fallback for pre-existing rows). Adds a /validate endpoint
that re-checks live account/GL state (not just the submit-time snapshot) so
a manager can verify before approving. Also exposes linked-savings-account
data on ShareAccount reads so the frontend can display/validate it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.
0434_seed_aml_transaction_rules.xml resolved source_client_risk_rule_id via
`SELECT id FROM m_client_risk_rule WHERE order_position = N`, assuming
order_position was unique. It isn't: 0430_seed_aml_compliance_rules.xml seeds
its own 221 rows with order_position 1-235, independently of the older
0428_add_client_risk_rules.xml rows, and several values collide (e.g. both
insert a row at order_position 10 and 30). Every affected subquery returned
more than one row, aborting the whole tenant's Liquibase run and app startup.
aml_check_status is populated only on 0430's rows (0428's predate that
column and are NULL there), so pairing it with order_position uniquely
targets the intended row without touching either seed changeset.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The 0345 changelog hardcoded the "OTHER LIABILITY" parent row's numeric id
(22), which only matched the default tenant's auto-increment history and
broke the FK insert (and the whole Liquibase run / app startup) on tenants
seeded differently, e.g. saga. Now resolves parent_id via a SELECT on
gl_code='9' and marks the changeSet runOnChange so it safely re-validates
on tenants that already ran the old version.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The 0345 changelog hardcoded the "OTHER LIABILITY" parent row's numeric id
(22), which only matched the default tenant's auto-increment history and
broke the FK insert (and the whole Liquibase run / app startup) on tenants
seeded differently, e.g. saga. Now resolves parent_id via a SELECT on
gl_code='9' and marks the changeSet runOnChange so it safely re-validates
on tenants that already ran the old version.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Backs the Client Approval tab's Today/Yesterday quick filters server-side.
offset/limit/displayName/orderBy/sortOrder/status already existed on this
endpoint; added fromDate/toDate (yyyy-MM-dd, inclusive) alongside them,
filtering on c.submittedon_date, following the same ::date-cast convention
already used by ClientPendingEditReadPlatformServiceImpl for the
equivalent pending-edits filter. Updated the one other caller
(SelfClientsApiResource) to pass null/null.
Screening only ever told a caller whether a name matched and when the
check ran — not which dated snapshot of the UN Security Council list it
ran against. Added SanctionsEntryRepository.findListLastLoadedOn()
(MAX(createdDate) over active entries) and threaded it through
SanctionsScreeningResult as listDataAsOf, so the frontend can show "List
Data As Of: <date>" alongside "Screened On".
FileContentStoreService.upload() opened a FileOutputStream (write) and an
InputStream (post-upload MIME check) without closing either. Windows keeps
those handles open for the JVM's lifetime, so the next upsert-style
delete-then-recreate of the same file (e.g. client signature/photo
re-upload) failed with FileSystemException: "being used by another
process". Wrapped both in try-with-resources.
Also adds every distinct non-individual/constitution KYC document name
(HUF, Private/Public Ltd, LLP, Partnership, Trust, Society, Proprietorship,
Association, Govt/PSU, Cooperative) as a KYCIdProofType code value.
resolveDocumentTypeId() on the frontend matches the picked document name
against this list before creating a client_identifier; since these entity
document names had no corresponding code value, every non-individual
client's KYC document upload silently failed to persist.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Client activation now requires a different user than the one who created the client
(client.getCreatedBy() vs current user) — no bypass, including CHECKER_SUPER_USER, since a
bypass would recreate the exact "role bypasses the hold" loophole this closes. Client creation
itself is unaffected (the wizard needs a real client id immediately for photo/KYC/address/family
follow-up uploads), only activation is gated.
- New maker-checker queue for Client edits, modelled on this codebase's existing
m_share_account_pending_edit / chequebook patterns rather than Fineract's native
command-approval engine (which any ALL_FUNCTIONS role bypasses unconditionally):
- m_client_pending_edit (migrations 0429-0431): stores the maker's raw edit payload plus a
point-in-time "before" snapshot (original_json, extracted from the frontend's _originalValues
key) so the checker's diff stays accurate even after the edit is approved/rejected, when the
live client no longer reflects the pre-edit state.
- ClientEditWritePlatformService: submitEditForApproval() stages the edit (refusing a second
submission while one's already pending, via a nullable-but-unique pending_lock_key);
approveEdit() replays the payload through the existing updateClient() so all of Client's
validation/change-detection runs unchanged, just deferred; rejectEdit() discards it. The maker
can never approve/reject their own submission.
- ClientEditApiResource: /clients/{id}/edit (submit), /clients/edit/pending (paginated +
status/clientName/date-range filterable list, mirrors /chequebook/pending-requests),
/clients/{id}/edit/approve, /clients/{id}/edit/reject. New permissions (migration 0430):
SUBMITEDIT_CLIENT, APPROVEEDIT_CLIENT, REJECTEDIT_CLIENT, APPROVEEDIT_CLIENT_CHECKER (the
last one surfaces pending edits in the generic Checker Inbox too).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- ClientData.templateOnTop()/templateWithSavingAccountOptions() never copied pwdCategoryOptions
from the template — the Disability Type dropdown was always empty on the edit-mode GET
/clients/{id}?template=true call, even though create-time template() had it.
- Raise the minor-detection threshold in ClientKycApiResource from age <10 to <18 (legal
definition), mirroring the frontend's own rule so the required-documents list served here
stays consistent.
- ClientKycCommand.validateForInitiate() unconditionally required at least one of
PAN/Aadhaar/GSTIN, with no awareness of the Birth Certificate/School ID document-type picker
minors actually use — blocking "Save & Next" on the KYC tab for every minor client. Added a
skipIdentityDocumentCheck flag, set from client.getIsMinor() at both call sites
(initiateKyc/initiateKycInline).
- Added Birth Certificate and School ID Card as KYCIdProofType code values — they were already
offered as document-type options for minors but never existed in the code-value list that
saveKycDocProof() resolves against, so selecting either silently failed to save any
identifier/document.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Add CARETAKER as a new RELATIONSHIP code value (previously missing — a client with no
father had no valid way to satisfy the rule below).
- Add ClientFamilyMembersWritePlatformService.validateFamilyRequirementsForActivation(),
called from activateClient(): requires an active "Mother" family member, plus either
"Father" or "Caretaker", for individual clients (non-individual entities are exempt).
- Two distinct exceptions (ClientFamilyMemberMotherRequiredException /
ClientFamilyMemberFatherOrCaretakerRequiredException) so the two failure reasons surface
as separate errors instead of one merged message, mirroring the frontend's separate banners.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Add m_client.signature_id (single-slot pointer, mirrors image_id) plus
ClientSignatureIdAdapter/EntitySignatureIdAdapter so re-uploading a signature updates the
existing m_document row in place instead of leaving duplicate rows behind that readers picked
inconsistently.
- Fix CkycBatchBuilderServiceImpl address-proof classification to read the client identifier's
actual m_code (KYCAddressProofType vs KYCIdProofType) instead of a hardcoded string set that
disagreed with the CKYC tab and silently dropped Aadhaar-as-address-proof identifiers.
- Organize the CKYC ZIP into per-artefact-type folders (PHOTO/SIGNATURE/ID_PROOF/ADDRESS_PROOF).
- Fix CkycBatchBuilderServiceImpl.createBatch() using the daily batch sequence number as the ZIP
document's parent_entity_id instead of the real m_ckyc_batch.id, which 404'd on download
whenever the two diverged (i.e. almost always).
- Add monthlyTurnover and annualIncome fields alongside the existing annualTurnover/monthlyIncome.
- Add isSeniorCitizen, isPwd, and pwdCategory (proper m_code_value-backed PwdCategory code, not a
free-text column) to m_client, following the same pattern as occupation/religion/marital status.
- Add Diploma as its own Education Level (with diploma-specific DegreeQualification values) and
Graduate as a level distinct from Undergraduate.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Mobile number and email address changes now require OTP verification on
both the old and new destination (staff-entered) before the update is
accepted, at both client creation and edit time — closing a gap where an
unverified wrong number/email could never be corrected later. Every
mobile/email/address change also emails the customer at their pre-change
address so an unauthorized change is never silent.
- New ClientContactOtpService (+Impl) mirrors the existing login OTP
services, reusing OtpLog with a CLIENT_CONTACT_CHANGE purpose.
- New sibling API resources for edit (/clients/{id}/contact-verification/otp)
and create (/clients/contact-verification/otp, no clientId yet).
- ClientWritePlatformServiceJpaRepositoryImpl / AddressWritePlatformServiceImpl
gate the actual field change on verified OTPs and fire
ClientChangeNotificationService afterwards; the notification recipient is
always snapshotted before any mutation so a same-request mobile+email
change can't accidentally alert the new (unverified-by-its-real-owner)
address instead of the old one.
- ClientDataValidator validates OTP id format only (ignoreIfNull) —
enforcement lives solely in the write-service's diff-gated calls, since
edit-client always PUTs the full client object regardless of what changed.
- 0420 migration seeds 8 CLIENTKYC action permissions
(GenerateAadhaarOtp/VerifyAadhaar/VerifyPan/VerifyCin/VerifyDin/
VerifyGstin/UploadCkyc/CompleteRekyc) that were referenced by existing
command handlers but never seeded, causing a 404 for every user including
Super User.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Admin now picks a mandatory OTP delivery method (Email/Mobile) when creating a
user. The channel is enrolled immediately as a verified m_user_mfa_factor row,
so the existing 2FA system (MfaFactorBackedTwoFactorServiceImpl + /twofactor)
challenges the user for OTP on their very first login - reusing the
already-built login-OTP infrastructure instead of a parallel flow.
Also adds a versioned, admin-manageable user-agreement (disclaimer) API
(/v1/useragreements) with per-user acceptance tracking, checked right after
every login, plus a Liquibase cleanup migration and a shared OTP-destination
masking utility extracted from the two existing login-OTP services.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The real root cause behind the leaf-serial collision bug: stock-lot
overlap checking was scoped to "within the same series only"
(ChequeStockLotRepository.countOverlappingInSeries), on the incorrect
assumption that two different cheque designs never share a numeric
range. A real bank allocates leaf serials from one bank-wide numbering
authority, so this is exactly what let two series end up with
overlapping ranges that, once both were issued to the same account,
produced an unresolvable serial collision (NpciInwardPushService's
drawer-account-number disambiguation can't help when every colliding
leaf belongs to the same account).
Widened the check to countOverlappingAnySeries — both the maker-submit
and checker-approval paths in ChequeBookWritePlatformServiceImpl now
reject a stock receipt whose range overlaps ANY existing lot, regardless
of series.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds a manual signature-verification step to the inward CTS decision flow:
a new VERIFY_SIGNATURE command records the clerk's confirmation, and
InwardClearingItem.pass() now refuses to pass a cheque until signatureOk
is true — enforced server-side, not just a disabled UI button.
Fixes a real bug where ChequeLeaf.leafSerialNo collides across different
cheque books/series (by design — serials are only unique per stock lot),
which could resolve an inward item to the wrong account. NpciInwardPushService
now disambiguates using the drawer account number NPCI already sends
alongside the cheque number.
Also closes a completeness gap found by auditing the outward-CBS -> NPCI ->
inward-CBS pipeline: five fields NPCI sends on every instrument (drawer
account number, deposit account number, instrument type/description, drawee
bank name, per-check IQA breakdown) were read and discarded instead of
persisted — now saved via new columns and exposed on the read API.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Inward/outward CTS clearing (capture, validate, settle, dishonour), positive pay,
settlement/reconciliation, and NACH clearing modules
- Real, separate NPCI clearing-house integration: hybrid RSA+AES envelope crypto,
bank self-registration, outward batch submission, and an inward push webhook
- Outward clearing is now session-batched: a 2-hourly scheduled job (plus the
existing manual "Send Pending Batch" fallback) bundles CAPTURED cheques instead
of sending them one at a time
- Batch-summary read APIs and date/text filters across inward batches, outward
presentments, and outward batches
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Removed the "CHEQUE_BOOK" facility charge from account-activation
auto-apply (both savings and current) — the per-leaf issuance charge is
now the only cheque-book charge, applied at request/approval time only.
- Cheque book request now reserves the charge amount via a direct
on-hold-funds field update instead of Fineract's native hold-amount
command, so no "Amount on hold"/"Release Amount" transaction row is ever
created — nothing shows in the passbook/transactions list, and the
reservation is released the same way (silently) on approval (then
charged) or rejection (returned), for both savings and current accounts.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- CurrentAccountTransactionsApiResource.retrieveOne() was calling the savings
read-service to fetch a single transaction, which always queries
m_savings_account_transaction and can never find a current-account row —
crashed with EmptyResultDataAccessException. Added a dedicated
CurrentAccountReadPlatformService.retrieveOneTransaction() backed by
m_current_account_transaction instead.
- CurrentAccountReadPlatformServiceImpl.buildTransactionType() (and the
search-transactions endpoint) had no cases for hold (8) / release (9)
transaction types, so they displayed as "Deposit"/"Other" instead of
"Amount on hold"/"Release Amount".
- ChequeBookIssuanceChargeService.deductFromCurrent() never set
runningBalanceDerived on the charge-deduction transaction, leaving the
Balance column blank for that row in the transactions list.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Requesting a cheque book now computes a per-leaf charge (reusing the existing
"Cheque Book Charge" facility mapping) and blocks the request at submit time if
the account can't absorb it without breaching its minimum required balance.
The charge amount is reserved via Fineract's native hold-amount mechanism when
the request is submitted, released and actually deducted (with GL posting) on
checker approval, or released back to the customer on rejection — so funds are
never left dangling on hold regardless of outcome.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds a maker-checker-gated "return" command on cheque books that flags
presented-and-dishonoured leaves as terminal RETURNED (distinct from
STOP_PAYMENT/drawer-initiated and LOST/custody-failure), following the
same reason/actor/timestamp pattern already used for lost/cancelled/used
leaves on m_cheque_leaf.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
introducer_required, share_linking_enabled, terminate_true were missing
from m_savings_account in fineract_saga. Applied directly to DB and
added 0368 catch-up migration with preConditions for idempotency.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Combines election module + UAT catch-up migrations (0338-0367) with
minor-update changes: soft delete for tellers (0338), share linking
for current account (0339), terminate flag for savings/current (0340).
Resolved changelog conflict by appending minor-update entries after 0367.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Add CommitteeMeetingAgenda entity + repository for relational agenda storage
- Liquibase migration 0353: create m_election_committee_meeting_agenda table,
drop old agenda TEXT column from m_election_committee_meeting
- Update CommitteeMeeting: replace String agenda with List<CommitteeMeetingAgenda>
(EAGER, no cascade — writes handled explicitly via repository)
- Update CommitteeMeetingRepository: explicit JPQL with SELECT DISTINCT + LEFT JOIN
FETCH to load agendaItems and prevent NonUniqueResultException on Optional returns
- Fix email sending stale agenda: inject EntityManager, call refresh() after
agendaRepository.flush() so EclipseLink reloads the collection from DB
- Redesign buildMeetingInviteHtml: table-based email layout, icon+label+value rows,
amber agenda section with numbered badges, compact two-column footer
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- ElectionConfig: add isCandidateModificationLocked() — blocks remove/update/symbol after voting starts
- ElectionWritePlatformServiceImpl: full audit logging on all 16 operations; failures logged in new transaction (REQUIRES_NEW) so they survive main tx rollback
- DirectorAppointmentData: add memberId field for client photo lookup
- DirectorAppointmentServiceImpl: batch-fetch candidate memberId via ElectionCandidateRepository; pass to response
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Add durationYears to ElectionConfig with Liquibase migration (0348)
- Block new election creation when previous election duration is still active (PostgreSQL-compatible native query)
- Auto-override director tenureEndDate from election durationEndDate on appoint and update
- Add ElectionSchedulerConfiguration to enable @Scheduled support
- Fix JPQL EclipseLink enum compatibility in expireByTenureDate query
- Add full audit logging to DirectorAppointmentServiceImpl (appoint, update, remove, auto-expire)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- DirectorAppointment entity + Liquibase migration (0347)
- CRUD API: POST/GET/PUT/DELETE /v1/election/directors with @Valid Bean Validation
- GET /v1/election/directors/pending — WON candidates not yet appointed
- Duplicate prevention: existsByElectionIdAndCandidateId check on appoint
- Business validation: tenure end must be after start; tenure start cannot be before appointment date
- @Scheduled daily midnight job to auto-expire tenure-ended directors via bulk JPQL UPDATE
- Full audit logging for all director actions (success + failure) via ElectionAuditService
- PendingDirectorData DTO; DirectorAppointmentStatus enum (ACTIVE/RESIGNED/REMOVED/TENURE_ENDED)
- ElectionAuditAction: added APPOINT_DIRECTOR, UPDATE_DIRECTOR_APPOINTMENT, REMOVE_DIRECTOR_APPOINTMENT + FAILED variants
- ElectionResultRepository: findByResult(String) for pending director lookup
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- ElectionAnalyticsServiceImpl: fix SQL_FAMILY to count candidate's own family members who are active shareholders (candidate-specific, not system-wide)
- ElectionAnalyticsServiceImpl: SQL_SUB_CASTE now groups by m_client.lastname instead of sub_caste_cv_id
- ElectionAnalyticsServiceImpl: SQL_CANDIDATE_INFO fetches candidate client_id, lastname, religion for match highlighting
- ElectionAnalyticsServiceImpl: add getOverallShareholderAnalysis() — returns all demographic breakdowns with no candidate matching
- ElectionAnalyticsService: add getOverallShareholderAnalysis() interface method
- ElectionCandidateApiResource: add GET /{electionId}/shareholders/analysis endpoint
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- New ElectionAnalyticsServiceImpl with 14 SQL breakdown queries:
gender, age, area, social category (caste), sub-caste, religion,
occupation, share-holding, tenure, loan, education, marital status,
monthly income, savings account depth
- Cross-dimension match: caste + area simultaneously (core voter base)
- Zero-count row injection for caste/gender/sub-caste when candidate's
category has no shareholder matches in GROUP BY result
- Liquibase 0343: sub_caste_cv_id column on m_client with 33 pre-seeded
sub-caste values across General / OBC / SC / ST categories
- Liquibase 0342: election post eligibility columns
- CandidateVoterAnalysisData DTO with education, marital, income,
savings, activeSavingsHolders, crossMatchCount fields
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Delete all fineract-provider/logs/*.log from version control
- Add fineract-provider/logs/ to .gitignore so runtime logs are
never tracked again
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- ElectionCandidateData: replace String symbol with Boolean hasSymbol + add memberId
- ElectionCandidateApiResource: symbol upload/download via ContentStoreService
(mimeType|storagePath format, backward-compatible with legacy base64 records)
- ElectionVotingApiResource: add GET /vote-summary endpoint (totalVotes, totalVoters,
per-candidate breakdown) using ElectionVoteRepository queries
- ElectionVoteRepository: add countByElectionConfigId and voteSummaryByCandidate queries
- ElectionReadPlatformServiceImpl: map hasSymbol and memberId in candidate list response
- ElectionWritePlatformServiceImpl: set photoUrl from memberId on approveCandidate,
delete old symbol file from ContentStore on removeCandidate
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- PagedResponse<T>: generic paginated wrapper with statusCounts and summary fields
- ElectionConfigRepository: pageable query + countGroupByStatus
- ElectionNominationRepository: pageable queries + count-by-status helpers
- ElectionCandidateRepository: pageable queries by election and post
- ElectionReadPlatformService: all list methods return PagedResponse with page/size params
- ElectionReadPlatformServiceImpl: add missing Pageable import; paginated impls with summary data
- API resources: @QueryParam page/size with @DefaultValue on all 3 list endpoints
- ElectionCeoPrecheck: add familyLoanCheckResult + familyLoanCheckRemarks (7th auto-check)
- ElectionCeoPreCheckServiceImpl: fix directorLoan check (overdue only); add family loan check covering manual members (unverifiable→FAIL) and linked CBS clients (overdue→FAIL)
- Liquibase 0338/0339: extended CEO pre-check columns + family loan check columns
- changelog-tenant.xml: include both new changesets
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Add borrower name, savings account, guaranteed/released/remaining amounts, loan timeline, and overdue info to GuarantorAccountSummaryData
- Fix duplicate rows in GuarantorLoanAccountSummaryDataMapper by joining savings account via guarantor funding details instead of client ID
- Fix NPE in GuarantorDomainServiceImpl when loan product guarantee details are null
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The 5 missing permissions were added to the already-executed changeset
causing checksum mismatch on restart. Move them to a new changeset
0337_seed_election_permissions_v2 with a preCondition guard.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Add 5 permissions that the write service enforces but were absent from
the DB seed: UPDATE_ELECTION, ELIGIBILITY_CHECK_ELECTION,
CEO_PRECHECK_ELECTION, APPROVE_ELECTION_NOMINATION,
APPROVE_ELECTION_CANDIDATE — without these, role assignments for those
operations would fail at runtime.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
ShareAccountWritePlatformServiceJpaRepositoryImpl:
- Remove m_share_cashier_collection validation from activateShareAccount() —
cashier now enters GL directly via transaction entry workstation
- Mark all share account charges as paid on activation instead of posting
duplicate GL (cashier already posted DR Cash -> CR Charges GL directly)
- Remove unused imports: java.sql.Date, EmptyResultDataAccessException, Collectors
- Update createShareAccount() comment to reflect new cashier GL flow
ClerkDisbursementRequestApiResource:
- Add null guard for clerk_id before cast in approve() — returns 500 with
clear message if DB record is missing the field
- Add null/blank guard for credit_entries in approve() — returns 400 with
clear message instead of NPE on gson.fromJson
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Replace Fineract cash deposit API with direct INSERT for both savings and current accounts
→ Zero CashVault entries created anywhere in DB for disbursements
- Savings: directCreditSavingsAccount now sets running_balance_derived and updates
total_deposits_derived alongside account_balance_derived (parity with current account)
- Current: directCreditCurrentAccount — direct INSERT into m_current_account_transaction
with running_balance_derived, total_deposits_derived update, and remarks audit field
- getCurrentControlGlId: looks up SAVINGS_CONTROL GL for current account products
via acc_product_mapping (product_type=2, financial_account_type=2)
- directReverseCurrentCredit: compensation restores both account_balance_derived
and total_deposits_derived on rollback
- GL: combined DR sourceGL / CR SavingsControl entry posted for both savings and
current account credits; linkGlEntriesToSavingsAccounts sets entity_type_enum=2
so ACCOUNT NO column shows in journal entries view
- Hide reversed=true GL entries from all GL views in JournalEntryReadPlatformServiceImpl
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Use parseTxnIdToLong() for voucherService.linkSavingsTransaction() to
handle hex GL txnId (e.g. "a2070e542bab") without NumberFormatException
- Add GL deposit maker-checker: submit stores gl_account_id, contra_gl_id,
office_id, currency_code; approve routes to executeGlJournalEntry()
- Save denomination at submit time (cash physically received); update
txn_id to real Fineract ID on approve, delete on reject
- Add Liquibase migration 0331 to add GL columns to m_cashier_deposit_request
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
CashierDepositRequestApiResource:
- approve(): use isCurrentAccountById() to detect current accounts, route to
executeCurrentAccountDeposit() instead of executeSavingsDeposit()
- Add executeCurrentAccountDeposit() using CommandWrapperBuilder.currentAccountDeposit()
- Add isCurrentAccountById() helper querying m_current_account table
- Add POST /{id}/reprocess endpoint to fix already-approved CA records that
were wrongly posted to savings account
ClerkWithdrawalRequestApiResource:
- approve(): use isCurrentAccountById() to detect current accounts, route to
executeCurrentAccountWithdrawal() instead of executeSavingsWithdrawal()
- Add executeCurrentAccountWithdrawal() using CommandWrapperBuilder.currentAccountWithdrawal()
- Add isCurrentAccountById() helper querying m_current_account table
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- VoucherService: central voucher register with globally unique voucher numbers
- CashierDepositRequestApiResource: full submit/approve/reject/list flow
- Cashier submits deposit request; balance credited only on manager approval
- Self-approval blocked (maker cannot be checker)
- Role guard: only manager/head-cashier/ALL_FUNCTIONS can approve/reject
- Race condition guard: WHERE status='PENDING' on approve/reject UPDATE
- Clean JSON error responses (no 500 stack traces) via apiError() helper
- Denomination total validation at submit and approve
- ClerkWithdrawalRequestApiResource: refactored to use m_voucher
- Voucher created at submit, linked to savings txn at approve
- Same role guard and self-approval block as deposit flow
- Disburse: denomination validation, null denoms for non-cash payments
- Migrations 0327-0330:
- 0327: add voucher_no to m_clerk_withdrawal_request
- 0328: add voucher_no to m_savings_account_transaction
- 0329: create m_voucher central table (globally unique voucher_no)
- 0330: create m_cashier_deposit_request table
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Add offset/limit query params with defaults (limit=20, offset=0)
- Return totalFilteredRecords + pageItems response structure
- Compute totalDr/totalCr from all records (not just current page)
- Fix ordering: ORDER BY MAX(created_at) for correct chronological sort
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Add CashierGlDenominationApiResource: new POST /v1/cashier/gl-denomination endpoint
to record denomination breakdown for GL journal entries in m_savings_txn_denomination
- Fix GL account real-time balance in GLAccountReadPlatformServiceImpl using live SUM query
- Add Liquibase migrations 0318/0319/0320: make savings_account_id and txn_id nullable,
add payment_type column to m_savings_txn_denomination
- Add validCheckSum to 0317b changeset to resolve checksum mismatch on existing installs
- Enhance GL entries closing report SQL with date, time, teller, payment type, txn source
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Fix searchParam SQL syntax: parameterized LIKE with %value% instead of literal %?%
- Fix organizationRunningBalance: correlated subquery for latest journal entry (ORDER BY id DESC LIMIT 1)
- Migration 0317: grant READ_GLACCOUNT, READ_LOAN, READ_SHAREACCOUNT to CASHIER role
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
CurrentAccountTransactionsApiResource:
- Fixed: search endpoint now queries m_current_account_transaction
instead of m_savings_account_transaction (wrong table)
- Added remarks column to search query (column exists in CA table)
- Charge Deduction (type=7) mapped in transactionType value
- Removed sat.remarks that caused 500 (column doesn't exist in savings table)
CurrentAccountTransactionWritePlatformServiceImpl:
- Added min required balance validation in withdrawal()
- Throws GeneralPlatformDomainRuleException when balance after withdrawal
would fall below minRequiredBalance (if enforceMinRequiredBalance=true)
StandingInstructionReadPlatformServiceImpl:
- Fixed SQL WHERE clause: fromAccountType + fromAccount condition
now correctly adds WHERE when fromAccountId is set
Liquibase 0315:
- Fix standing instruction permission code (trim trailing space on id=449)
- Grant READ permissions to CASHIER role for transaction entry screen
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Add CashierRoleHelper service: detects CASHIER role via DB permission
check, resolves cashier ID from staff/user linkage
- Role-based filtering on GET list endpoints (cashtransfer, cashsettlement,
cashintercashier, cashexchange, cashreports): CASHIER sees only own data,
ADMIN/HEAD sees all
- Pagination (offset/limit) added to all cashier list APIs returning
standard Fineract Page format {totalFilteredRecords, pageItems}
- ShareCollectionApiResource: collect cash before account activation,
post GL entries (Dr Cash Vault / Cr Share Sundry / Cr Income from Fees),
mark charges paid to prevent duplicate GL on activation,
GET status endpoint for collection check
- Migration 0315: grant READ_CLIENTKYC, READ_CLIENTNOMINEE, READ_ADDRESS,
READ_FAMILYMEMBERS, READ_SAVINGSACCOUNT to CASHIER role
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- New POST /cashier/sharecollection endpoint: collects cash for share purchase,
posts Dr Cash Vault / Cr Share Sundry / Cr Income GL entries, marks charges
as paid and sets cashier_collected flag on the account
- GET /cashier/sharecollection/:id endpoint for collection status check
- Block share account activation if cashier has not collected cash first
(validates m_share_cashier_collection record within last 30 days)
- Skip duplicate charge GL on activation when charge already collected upfront
- Suppress automatic GL posting at account submission time to prevent
double entries; GL is now posted only via cashier collection endpoint
- Fix JdbcTemplate injection in ShareAccountWritePlatformServiceJpaRepositoryImpl
via ShareAccountsConfiguration
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
SavingsAccount.modifyApplication() previously blocked modification unless
the account was in SUBMITTED_AND_PENDING_APPROVAL state. Extended to also
allow REJECTED state so bank users can amend and re-submit rejected applications.
When a rejected account is modified, status resets to
SUBMITTED_AND_PENDING_APPROVAL (rejectedOnDate and rejectedBy cleared)
so the account re-enters the approval workflow.
Applies to Savings, FD, and RD accounts (all extend SavingsAccount).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
ALLOCATE (vault→cashier) and SETTLE (cashier→vault) no longer post
DR CASH_AT_TELLER / CR CASH_AT_MAINVAULT journal entries.
Rationale: Cash transfer between vault and teller drawer is an internal
physical movement — the denomination/amount is already tracked operationally
via m_cash_transfer and m_cash_settlement tables. A single Cash in Hand GL
(CASH_AT_MAINVAULT) covers all bank cash. GL entries now only occur on
actual customer deposit/withdrawal transactions (SAVINGS_REFERENCE ↔
SAVINGS_CONTROL), keeping the GL clean and RBI-compliant.
Removed unused imports and field injections:
JournalEntryRepository, FinancialActivityAccountRepositoryWrapper,
FinancialActivity, FinancialActivityAccount, GLAccount,
JournalEntry, JournalEntryType
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- DenominationBreakdownWriter: add ORDER BY mc.id DESC LIMIT 1 to all cashier
lookup queries so multiple cashier records per staff do not crash queryForObject
- CashReportApiResource: same LIMIT 1 fix for cashier-day-status and position endpoints
- 0311: fix m_client and m_savings_account NOT NULL columns (created_by, last_modified_by,
created_on_utc, last_modified_on_utc, cif_number, is_lien_allowed, etc.)
- 0312: create CASHIER role if missing + grant all 34 cashier permissions (incl FD/RD)
- 0313: add missing m_cash_exchange columns (cashier_id, is_reversed, reversed_by,
reversed_at, reverse_reason, customer_id_proof)
- 0314: unique constraint on m_cashiers.staff_id to prevent duplicate allocations
- application.properties: restore local postgres password after merge
- ExecuteOverdueAndCurrentStandingInstructionsTest: fix constructor call (5 args)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- validateCashierHasMorningTransfer(): blocks all txns when no today's cash transfer in m_cash_transfer
- validatePreviousDayClosed(): blocks when previous business day unsettled
- Both validations called on deposit AND withdrawal in Savings, Current, FD, RD services
- cashier-day-status endpoint now returns morningTransferReceived field
- getCashierTotalCash SQL fixed: dm.denomination_value -> dm.denomination
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
feat(fundtransfer+imps+mfa): fund transfer module, IMPS switch client, MFA log API
- Fund transfer: NEFT/RTGS/IMPS/internal strategies, limit resolution, bulk
transfer, verification tokens, suspense GL, recall/approval flow, jobs
- IMPS CBS switch client with crypto (JWT/envelope) and transaction domain
- MFA log read API (audit of MFA events)
- Liquibase migrations 0300-0311 for fund transfer / IMPS tables, permissions,
roles, and suspense account
- JobName, SecurityConfig, dependencies.gradle wiring
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@
- Savings/Current/FD/RD withdrawal services: call validateWithdrawalStock() before
validateBreakdown() to block withdrawal when cashier lacks the requested denomination
- CashExchangeApiResource: validate cashier denomination stock before giving to customer;
fix saveAndFlush (EclipseLink does not flush on save() — getId() returned null causing
exchange_id NOT NULL violation in m_cash_exchange_detail)
- CashReportApiResource excess(): include cash exchanges >= threshold in result,
add type field (SAVINGS_TXN/EXCHANGE) and idProof for RBI/AML compliance;
combined list sorted by amount DESC
- CashReportApiResource closing(): add denomination-wise exchange rows (already present)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- GET /cashreports/cashier-morning: returns denomination-wise cash received by cashier from vault
for a given date (only vault→cashier transfers, non-reversed)
- CashSettlementApiResource: include fromCashierId in list and detail responses
- CashTransferApiResource: include toCashierId in list and detail responses for traceability
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- DenominationBreakdownWriter helper: validates breakdown total == amount and
persists per-denomination rows; wired into current, FD and RD deposit flows
(savings already had inline save) so all 4 deposit types now record the
cash denomination breakdown.
- CIF on denomination rows now sourced from the client (getCifNumber) instead
of the account external id.
- Allow denominationBreakdown param in the FD/RD transaction validator.
- Cash Exchange backend: m_cash_exchange + m_cash_exchange_detail tables,
entities, repositories and JAX-RS API with received==given validation;
registered the 0013 migration in changelog-tenant.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- m_denomination_master CRUD API with duplicate (denomination+kind)
validation, soft delete + restore, and a full audit trail
(m_denomination_master_audit logs CREATE/UPDATE/ACTIVATE/DEACTIVATE/
DELETE/RESTORE with snapshot, changes, user and timestamp)
- m_savings_txn_denomination: persist per-transaction cash denomination
breakdown on savings deposit; allow denominationBreakdown request param
- Liquibase 0012_denomination_master registered in tenant changelog
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- AccountTransfersWritePlatformServiceImpl:
* Direct GL posting for current↔savings/current transfers:
DR debit-side account GL (with correct account entity_id)
CR credit-side account GL (with correct account entity_id)
* Prefix current account txn_id with CA (not C) so
JournalEntryReadPlatformServiceImpl joins m_current_account
and shows correct current account number on GL entries
* Suppress redundant savings deposit/withdrawal GL entries
(skipAccountingPostings=true) when current account handles
the full double-entry directly
* Separate performCurrentWithdrawalForLoan for Current→Loan
transfers (loan domain service handles the other GL leg)
* Reuse existing AccountTransferDetails for SI recurring runs
so transactions appear in list-account-transactions history
- SavingsAccountDomainService / SavingsAccountDomainServiceJpa:
* New handleDeposit overload with skipAccountingPostings flag
* handleWithdrawal respects SavingsTransactionBooleanValues
.isSkipAccountingPostings() to suppress redundant GL entries
- SavingsTransactionBooleanValues:
* Added skipAccountingPostings field + overloaded constructor
- AccountingProcessorHelper:
* New createDirectTransferJournalEntriesForSavings() method
creates DR and CR entries with separate productId/entityId
so each GL line shows the correct account number
- JournalEntryReadPlatformServiceImpl:
* Join both m_savings_account and m_current_account always
* COALESCE(ca.account_no, sa.account_no) to resolve correct
account number regardless of transaction_id prefix
- ExecuteStandingInstructionsTasklet:
* Load existing AccountTransferDetails via repository so
subsequent SI runs link to the same transfer detail record
- ExecuteStandingInstructionsConfig / AccountConfiguration:
* Wire AccountTransferDetailRepository and
AccountingProcessorHelper into the relevant beans
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- StandingInstructionData: rename conflicting Lombok getters (getInstructionType,
getRecurrenceType, getRecurrenceFrequency, getFromAccountType, getToAccountType,
getTransferType) to domain enum methods so Jackson serializes EnumOptionData fields
as {id, code, value} objects instead of plain strings
- AccountTransfersWritePlatformServiceImpl: add current account transfer support for
all 4 missing cases (Current->Savings, Savings->Current, Current->Current,
Current->Loan) with performCurrentWithdrawal/performCurrentDeposit helpers
- AccountConfiguration: wire CurrentAccountRepository and CurrentAccountTransactionRepository
into AccountTransfersWritePlatformService bean
- StandingInstructionApiResource: fix getValue() type mismatch after getter rename
- ExecuteStandingInstructionsTasklet: update to use renamed enum accessor methods
- PortfolioAccountType: add CURRENT(3) type support
- DB migration: 0301_add_current_account_to_transfer_details.xml adds
from_current_account_id and to_current_account_id columns to transfer details table
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- ClientFamilyMembersWritePlatformServiceImpl#updateFamilyMember: guard
maritalStatusId/genderId/professionId with != null instead of != 0 so a
payload that omits these keys doesn't NPE when the boxed Long is unboxed.
- application.properties: fix the broken property name
`fineract.security.cors.allowed-metho pas` -> `allowed-methods`. The typo
left CORS allowed-methods empty, which made Spring reject every browser
POST with "Invalid CORS request" 403 once the SPA sent an Origin header.
- application.properties: change the Hikari default password from 313863
to root so the local devRun matches the tenant-DB default at line 49.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- ClientFamilyMembersWritePlatformServiceImpl#updateFamilyMember: guard
maritalStatusId/genderId/professionId with != null instead of != 0 so a
payload that omits these keys doesn't NPE when the boxed Long is unboxed.
- application.properties: fix the broken property name
`fineract.security.cors.allowed-metho pas` -> `allowed-methods`. The typo
left CORS allowed-methods empty, which made Spring reject every browser
POST with "Invalid CORS request" 403 once the SPA sent an Origin header.
- application.properties: change the Hikari default password from 313863
to root so the local devRun matches the tenant-DB default at line 49.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Apply senior citizen rate override in FixedDepositAccount and RecurringDepositAccount
getEffectiveInterestRateAsFraction() so maturity is calculated at correct rate (e.g. 7.5%)
instead of chart slab rate on every event: submit, activate, posting, pre-closure, maturity
- Override getEffectiveInterestRateAsFractionAccrual() in both FD/RD to keep accrual
consistent with maturity calculation — independent of DB nominalAnnualInterestRate value
- Add isSeniorCitizen and seniorCitizenInterestRate fields to SavingsAccount entity with
JPA mapping and accessor methods; updateNominalAnnualInterestRate() helper added
- Extend DepositsApiConstants whitelist and SavingsAccountAssembler.applyCbsFields()
to read and persist senior citizen fields from API request as final override step
- Add DepositAccountAssembler early-stage rate override for senior citizen accounts
- Liquibase migration 2015: add is_senior_citizen and senior_citizen_interest_rate columns
to m_savings_account table
- Liquibase migration 0300: rename fd_base_interest_rate tables to CBS naming convention
- Update CBS copyright header in FdBaseInterestRateEffective and FdBaseInterestRateSlabHistory
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
PAN verify for non-individual clients was sending name="" + dob=null to LincPay because
the code path always read firstname/middlename/lastname (NULL on entities) and
client.dateOfBirth (also NULL on entities). LincPay then returned plain-text "Invalid
DOB format. Required format is dd/MM/yyyy", which Gson can't parse (MalformedJsonException
at line 1 col 10), surfacing as a useless 503. Now ClientKycWritePlatformServiceJpa-
RepositoryImpl.verifyPan branches on LegalForm:
- PERSON → name = firstname + middlename + lastname, dob = client.dateOfBirth
- ENTITY → name = client.fullname, dob = clientNonPerson.dateOfRegistration
Injected ClientNonPersonRepositoryWrapper for the entity branch.
ClientNonPerson got two missing getters (getConstitution, getDateOfRegistration) needed
by the above plus the family/nominee rules below.
Defensive JSON parse in LincPayKycVerificationServiceImpl: parseJson now returns null
when the body doesn't even start with '{' or '[' (i.e. vendor sent plain text or HTML),
logs the literal body at WARN, and every verify method (PAN, GSTIN, Aadhaar OTP gen,
Aadhaar OTP verify, CIN, DIN) checks for null and returns
"<X> verification failed — vendor returned non-JSON: <first 200 chars>"
So future vendor outages surface the actual response text instead of a MalformedJson-
Exception with no context.
Non-individual client rules:
- ClientFamilyMembersWritePlatformService: addFamilyMember / addClientFamilyMember /
updateFamilyMember now refuse with PlatformApiDataValidationException when the client
is an entity. Family members are an individual-only concept. Delete is intentionally
unguarded so legacy rows can be cleaned up.
- ClientNomineeWritePlatformService: addNominee / updateNominee refuse for non-individual
clients UNLESS the constitution normalises to PROPRIETORSHIP (matches both
"PROPRIETOR SHIP" and "PROPRIETORSHIP"). Proprietorships are operationally individuals
with a separate trade name, so they keep nominee support; companies / LLPs / trusts /
societies / HUFs / partnerships don't carry a nomination concept. Delete unguarded.
Verified the LincPay endpoints directly:
/validate-pan AQRPV8345E + "Aditya Vyas" + 19/12/1988 → valid (individual)
/validate-pan AAMCG5406B + "GIZMOGLADE..." + 01/12/2025 → valid (company)
/validate-pan AAMCG5406B + "" + "" → "Invalid DOB format" plain text (the failing path)
/validate-gstn 23AADCL9984A1ZH → 200 with full company data
/validate-gstn 21AAMCG5406BIZ6 → 400 "Invalid GSTIN pattern" (bad checksum, not our bug)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The second schema() builder used by the clients-list query had the JOIN
left join m_client gc on gc.id = c.guardian_client_id
and the SELECT
c.guardian_client_id as guardianClientId
but was missing
gc.display_name as guardianClientDisplayName
which the RowMapper still reads (rs.getString("guardianClientDisplayName")).
Result: PSQLException "The column name guardianClientDisplayName was not found
in this ResultSet" → BadSqlGrammarException → 500 on any client-list pull.
The matching first builder (~line 327) had both columns correctly. Added the
missing SELECT line to keep the pair consistent.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- SearchParameters: added fromDate, toDate, asOnDate (LocalDate) fields with hasX() helpers
- SavingsAccountsApiResource: added status, fromDate, toDate, asOnDate query params
- SavingsAccountReadPlatformServiceImpl: resolveStatusEnum(), date filters on activatedon_date, default ORDER BY id DESC
- CurrentAccountsApiResource + service: same filters on ca.status_enum and ca.activatedon_date
- DepositAccountReadPlatformService (interface): new retrieveAllPaged overload with date/status params
- DepositAccountReadPlatformServiceImpl: resolveStatusEnum(), date filters, default ORDER BY id DESC for FD/RD
- FixedDepositAccountsApiResource + RecurringDepositAccountsApiResource: pass new params to service
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- New CurrentAccountTransactionWritePlatformService interface with deposit,
withdrawal, holdAmount, releaseAmount, undoTransaction, reverseTransaction,
and adjustTransaction operations
- New CurrentAccountTransactionWritePlatformServiceImpl using m_current_account
tables directly (not m_savings_account), with GL journal entry posting
- Add holdAmount, releaseAmount, reversal factory methods to CurrentAccountTransaction
- Wire all 7 current account transaction command handlers to new write service
- Fix CurrentAccountTransactionsApiResource template SQL column: currency_multiplesof
- Fix account number search in SearchParameters
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Use FD/RD transaction ID prefixes for Fixed/Recurring Deposit GL entries
via ThreadLocal context set in Cash/AccrualBasedAccountingProcessorForSavings
- Add depositAccountType to SavingsDTO and pass from SavingsAccount bridge data
- Add savingsAccountNo field to JournalEntryData; populate via LEFT JOIN on
m_savings_account (SB/FD/RD) and m_current_account (CA prefix) in read query
- Fix JournalEntryMapper MapStruct: ignore savingsAccountNo (SQL-populated)
- Fix JournalEntryRunningBalanceUpdateServiceImpl constructor call (27 params)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Pre-save validator (ClientWritePlatformServiceJpaRepositoryImpl.validateClientUniqueness)
rejects duplicate mobile / email / PAN / Aadhaar (masked) / GSTIN before saveAndFlush
and before the LincPay KYC API call. Avoids burning vendor credits on identity-duplicate
records and gives the UI a clean field-level 403 instead of waiting for the DB constraint.
Splits the new repository finders into "create" and "excluding-self" variants so a
nullable Long parameter never reaches PostgreSQL's parser (same bigint <> varchar trap
that broke the family-member POST earlier).
Also seeds the full set of 28 Indian States + 8 UTs as STATE code_values (migration
0297). Previously only MAHARASHTRA / MADHYA_PRADESH / DELHI existed and the names were
UPPER_SNAKE_CASE; the postal PIN-lookup service returns "Madhya Pradesh" so any state
other than Maharashtra/Delhi silently failed to resolve to m_address.state_province_id.
Renames the 3 existing rows in place (preserves their ids/FKs) and inserts the missing
33 with idempotent preConditions.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The relationship-uniqueness query used (:excludeId IS NULL OR fm.id <> :excludeId).
On create, excludeId is null and PostgreSQL parses the parameter as varchar before
the IS NULL branch can short-circuit, so adding a family member returned 403 with
"operator does not exist: bigint <> character varying". Split into two queries so
neither has a nullable Long parameter.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Brings TOTP / Google Authenticator MFA factor (device mapping at
/v1/mfa/totp/setup + /verify, login via existing twofactor pipeline),
DSC-2FA login UI fix, Individual-only filter on guardian/nominee/family
link pickers, Title Case normalization on client names, and migration
0296 unique nominee per account type.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
# Conflicts:
# .claude/settings.local.json
# fineract-provider/logs/fineract.log
Backend:
- New dependency dev.samstevens.totp:totp:1.7.1 (bundles ZXing for QR PNG).
- TotpService: secret/QR/otpauth-URL/verify primitives. SHA1, 6 digits, 30s —
the standard combo every consumer authenticator app accepts unconfigured.
Issuer label is configurable via FINERACT_MFA_TOTP_ISSUER, defaults to
"CBSnexora".
- Two-step device mapping driven by TotpEnrollmentService:
* POST /v1/mfa/totp/setup — generate secret, upsert m_user_mfa_factor row
as factor_type=TOTP/verified=false, return {secret, qrDataUri, otpAuthUrl,
issuer, factorId}. Refuses to overwrite an already-verified-and-active
factor so an accidental click can't unbind the user's working device.
* POST /v1/mfa/totp/verify — body {code}; verify against the stored secret
and flip verified=true on success.
- Login wiring in MfaFactorBackedTwoFactorServiceImpl:
* getDeliveryMethodsForUser surfaces verified TOTP factors as
{name:"totp", target:"Google Authenticator"} so the picker offers it
alongside SMS/EMAIL.
* createNewOTPToken("totp") creates a no-op OTPRequest (no LincPay/SMTP
round-trip) carrying the factor id in the token field so validate can
look up the secret.
* createAccessTokenFromOTP branches on channel — TOTP path verifies code
vs factor.secret with totp library (sliding 1-step window) and mints
a TFAccessToken with the same lifetime + extended-token logic as OTP.
* Defence-in-depth: re-checks at validate time that the factor still
belongs to the user, is verified, and not disabled.
- TwoFactorConstants.TOTP_DELIVERY_METHOD_NAME = "totp".
- SecurityConfig: /api/*/mfa/totp/** is fullyAuthenticated() (exempt from
the TFA gate so users can enrol before they can satisfy 2FA).
UI changes pending (see chat): add a "Google Authenticator" tile on the
MFA Factors settings page that calls /setup → shows QR + secret → calls
/verify; extend two-factor-authentication.component.ts iconFor() and copy
for the new "totp" delivery method. Existing requestOTP / validateOTP
pipeline handles the login flow transparently.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- DSC-as-2FA login: UI's claimAndValidate() now calls a new
AuthenticationService.applyTwoFactorToken(token, liveSeconds) instead of
validateOTP(). The /v1/login/dsc/{rn}/claim response is already a minted
TFAccessToken — POSTing it to /twofactor/validate fails because that path
expects an in-memory OTPRequest. applyTwoFactorToken runs only the
post-success bookkeeping (interceptor.setTwoFactorAccessToken, setCredentials,
Authentication Success alert that drives router.navigate(['/']), and
sessionStorage persist of {token, validFrom, validTo}). Fixes the
OTPTokenInvalidException users hit after a successful DSC verify+claim.
- Individual-only filter for link-client pickers: ClientTextSearch gains a
legalFormType field; SearchingClientRepository accepts an Integer legalForm
value and adds cb.equal(r.get("legalForm"), ...) to the spec.
ClientSearchService.parseLegalForm tolerates INDIVIDUAL/PERSON/1 and
NON_INDIVIDUAL/ENTITY/2; unknown = no filter so a typo doesn't blank results.
UI: clients.service.ts searchByText gains a 7th optional arg; six link
pickers (guardian, nominee, family-member across create flow and post-create
tabs) now pass 'INDIVIDUAL'. General client list and signatory picker are
intentionally unchanged.
- Title-case client names on persistence: ClientWritePlatformServiceJpa
RepositoryImpl now runs first/middle/last/full name fields through
toTitleCase() on both create and update paths. "aditya kumar vyas",
"ADITYA KUMAR VYAS", "Aditya Kumar Vyas" all persist as "Aditya Kumar Vyas".
Whitespace-split title case; preserves hyphens/apostrophes inside words
without re-capitalising after them so clerks verifying against ID documents
see predictable output.
- Migration 0296: unique constraint to prevent duplicate nominee per account
type (the underlying repository + service changes also persisted in this
commit complete the enforcement path).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- m_user_mfa_factor is now the single 2FA gate. DSC enroll callback writes a
factor row (factor_type=DSC), revoke flips disabled_on when the last cert
goes. AuthenticationApiResource and TwoFactorAuthenticationFilter drop the
direct m_bank_user_dsc check so disabling from the UI actually stops the
challenge at login.
- SecurityConfig exempts /api/*/dsc/** and /api/*/mfa/factors from the
TWOFACTOR_AUTHENTICATED gate. Without this a user with a verified factor
can't manage their own factors after they break the device.
- MfaFactorType gains a DSC enum value; SelfUserMfaFactorServiceImpl error
message lists it.
- dsc-helper: CBSnexora-branded header (logo, title, subtitle, accent palette),
8-column cert table (Holder Name, Alias, Organisation, DSC Type, Serial,
Issuer, Valid From, Expires), LdapName-based DN parsing, sign+verify proof-
of-possession that picks SHA256withRSA / SHA256withECDSA from the key's own
algorithm (works on RSA, RSA Signing-only, EC), pattern-matched JNLP age
check, dscType JNLP-arg override with KeyUsage fallback.
- generate-test-dsc.ps1 produces a realistic self-signed DSC with strong key
protection so dev testing sees real CN/O values and a PIN prompt.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Backend:
- m_bank_user_dsc + m_dsc_challenge tables (Liquibase 0292/0293/0294)
- DSC enrollment flow: start → JNLP → JWS helper → callback → upsert
- DSC login factor: challenge → sign → verify → claim minted TFA token
- 2FA gate now also accepts an active DSC mapping (AuthenticationApiResource
+ TwoFactorAuthenticationFilter), defensively wrapped so a missing DSC table
doesn't 500 the auth path
- TenantAwareBasicAuthenticationFilter exempts /api/v*/dsc/helper.jar and
strips Authorization header for that path so JWS's raw GET works without
the user seeing a browser Basic-auth prompt
- DSC helper JAR served at /api/v*/dsc/helper.jar from a configurable
filesystem path (default ~/.cbsnexora/dsc-helper.jar)
Java helper JAR (dsc-helper/):
- Standalone Gradle subproject, Java 8 target, fat jar with Gson shaded in
- Cross-platform token picker (Windows Cert Store / ePass2003 / eToken /
ProxKey / Other) — matches the JNLP arg contract emitted by the backend
- Sets Fineract-Platform-TenantId on its callback POST from the JNLP args
- JNLP age check now reads cbsnexora-dsc.jnlp (current name) AND
SignTender.jnlp (legacy) — picks the youngest, never blocks if none exist
Inline KYC upsert in updateClient (mirror of the create-flow path):
- ClientKycWritePlatformService.upsertKycInline() — creates or merges KYC
fields, bumps status to IN_PROGRESS on real changes; resets PAN verification
on PAN edit of a verified record
- ClientWritePlatformServiceJpaRepositoryImpl.updateClient() handles the
kyc:{} sub-object on PUT /clients/{id}, matching createClient
User uniqueness:
- m_appuser.email + m_appuser.mobile_no UNIQUE (Liquibase 0295)
- Pre-flight assertEmailAndMobileUnique() in create/update with self-exclusion
- handleDataIntegrityIssues maps the two new constraints to clean
field-scoped error messages (race-condition safety net)
Email OTP subject line now: "Your OTP for Login - <AppName> (dd-MM-yy-HH:mm)"
where AppName comes from fineract.email.from-name (default "CBSnexora").
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Login 2FA via @Primary MfaFactorBackedTwoFactorServiceImpl (replaces legacy)
- LincPay SMS OTP and SMTP email OTP with auto-promote to m_user_mfa_factor
- Reusable EmailSenderService + EmailTemplateService (CBSnexora branding)
- Admin OTP audit viewer (GET /v1/otp-logs) with paging, search, masking
- Self-service MFA factor API at /v1/mfa/factors
- READ_OTP_LOG permission + OTP Log Auditor role + bankadmin direct grant
- JsonAuthenticationEntryPoint suppresses Basic-auth popup for SPA paths
- TwoFactorAuthenticationFilter grants TWOFACTOR_AUTHENTICATED when no challenge
- Soft-delete + audit columns + deletion audit + version on client tables
- CIF number generator (TTYYYYNNNNNN format)
- DocumentNotFoundExceptionMapper to silence noisy WARN logs on missing images
- Liquibase migrations 0278-0291 (MFA, OTP log, audit/soft-delete, role wiring)
Note: application.properties intentionally not committed — contains local DB
and Gmail App Password fallbacks. Set SPRING_MAIL_PASSWORD,
FINERACT_DEFAULT_TENANTDB_PWD, FINERACT_HIKARI_PASSWORD as env vars in prod.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- GET /ckyc/reports/summary — KPI cards (total, gender split, missing PAN/Aadhaar, dup mobile)
- GET /ckyc/reports/state-distribution — donut chart by state
- GET /ckyc/reports/branch-distribution — top-N branches bar chart
- GET /ckyc/reports/upload-trend — daily upload line chart
- GET /ckyc/customers — paginated, filterable customer list
- GET /ckyc/customers/search — search by name/mobile/pan/cif (capped 50)
- GET /ckyc/customers/{cif} — customer detail with addresses
- GET /ckyc/customers/export — CSV/TXT (pipe-delimited CERSAI format)
- POST /ckyc/files — parse inbound CKYC .txt file
- GET /ckyc/files — list historical uploads
- POST /ckyc/files/generate — generate outbound submission file
- GET /ckyc/branches, /states, /codes/id-types — master data
- Migration 0259: performance indexes on m_client_kyc and m_client
- Postman collection with all endpoints
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Migration 0256: EducationLevel & DegreeQualification codes with m_client FK columns
- Migration 0257: Religion & SocialCategory codes with m_client FK columns
- Migration 0258: agriculture_income & non_agriculture_income decimal columns on m_client
- Full API support: create, update, template options, and GET response for all new fields
- Postman collection for testing all new dropdowns
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Added accountTypeOptions and customerSegmentOptions fields to SavingsAccountData and RecurringDepositAccountData
- Added CodeValueReadPlatformService to SavingsAccountTemplateReadPlatformServiceImpl, CurrentAccountTemplateReadPlatformServiceImpl, and DepositAccountReadPlatformServiceImpl to fetch options from code values
- Added options to SAVINGS_ACCOUNT_RESPONSE_DATA_PARAMETERS and RD response parameters
- Updated SavingsConfiguration bean factory methods to pass new CodeValueReadPlatformService dependency
- Added validCheckSum for modified Liquibase changeset 0272
- Fixed AccountNumberGeneratorTest constructor to include GLAccountRepository and SavingsProductRepository
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Allow KYC updates on VERIFIED records with mandatory remarks for audit trail;
reset PAN verification when PAN number changes, moving status to IN_PROGRESS
- Fix client address duplicates: deactivate old addresses of same type on
create/update, persist isActive flag (missing save), filter reads by is_active
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Added mandatory unique CIF number (auto-generated as CIF+padded ID)
- Added Occupation Category dropdown (6 categories: Salaried, Business, Professional, Agriculture, Student, Others)
- Added Occupation dropdown (54 occupations mapped to categories)
- Both stored in m_code/m_code_value tables (same pattern as Gender)
- Visible in client create/update API and personal data view
- Includes Liquibase migrations 0227 & 0228
- Added Postman collection for User Management APIs
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Includes all prior work not yet committed on this branch:
- KYC module (LincPay eKYC: PAN, Aadhaar OTP, GSTIN verification)
- Sanctions screening (UN Security Council consolidated list)
- RBI Feed integration with scheduled jobs
- OpenProject API integration
- Mobile lookup service
- Charge module enhancements (current account support)
- Client family member nominee fields
- Avro schema updates
- Liquibase migrations 0216-0224
- Postman collections for OpenProject, RBI Feeds, Sanctions
- SQL seed scripts
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Use current_schema instead of hardcoded 'public' in getTableIndexes()
and isTablePresent() methods to support multi-tenant PostgreSQL
deployments where datatables reside in tenant-specific schemas.
This fixes:
- GET /datatables returning 404 for new datatables
- Datatable save operations failing with 'Datatable not found'
Root cause: Index metadata queries were looking in 'public' schema
while table columns query correctly used current_schema, causing
inconsistent behavior in GenericDataServiceImpl.
Changes:
- PostgreSQLQueryService.getTableIndexes(): Use current_schema
- PostgreSQLQueryService.isTablePresent(): Use current_schema
Testing:
- All unit tests pass (93/93 in fineract-core)
- Manual PostgreSQL verification confirms fix works correctly
- Fixed missing throw exception for validation errors in Teller Module
- added unit tests to confirm changes to TellerCommandFromApiJsonDeserializer
ReportedBy: subramanyasn
- Add CycloneDX plugin for SBOM generation (version 3.1.0)
- Configure as optional task (not part of default build)
- Generate SBOM in CycloneDX format with license information
- Usage: ./gradlew :fineract-provider:cyclonedxDirectBom
Output: build/reports/cyclonedx-direct/bom.{json,xml}
- Simplified conversion using Number.intValue() to handle Short and Integer types.
- Removed redundant null checks as per feedback.
- Added unit tests for type-safety verification.
* FINERACT-2421: Add unit tests for ExternalIdFactory
* FINERACT-2421: Fix ambiguous method reference in ExternalIdFactoryTest
Cast null to String to resolve ambiguous method call between
produce(String) and produce(List<String>) overloads.
Fixed startDate from dynamic current year to hardcoded 2025 in
testPostInterestNotZero() to maintain consistent 2025 timeline.
Resolves HTTP 400 error caused by date mismatches.
Fixed misspelled 'allowPartialPeriodInterestCalcualtion' to
'allowPartialPeriodInterestCalculation' in REST API and code.
35 files updated as specified in JIRA.
The extractBooleanNamed method can return null when the JSON value is null
or missing. Using primitive boolean causes automatic unboxing which throws
NullPointerException.
Changes:
- CalendarCommandFromApiJsonDeserializer: Use Boolean wrapper instead of
primitive boolean for 'repeating' field extraction
- CalendarCommandFromApiJsonDeserializer: Use Boolean.TRUE.equals() for
null-safe boolean comparison
- CalendarCommand: Update field type and constructor parameter from
boolean to Boolean to support null values
This addresses the FIXME comments on lines 156 and 298 in the original file.
* Go analog for step 15, automation was broken.
* Fix two admonitions: I meant to use `NOTE`. `INFO` is not a valid admonition in asciidoc, so it just shows up as text.
* release/1.14.0:
update manual release instructions
port steps 10 & 11 to the ATR
docs: adapt artifact checks to new ATR tool
improve svn release staging/release instructions
exclude jquery-1.7.min.js from source release
ignore .swp files when building src release
add license to .mailmap
add RAT excludes for ATR
add license to scripts/*.sh
fix both NOTICE files for ATR
doc: remove errant config
improve start release notes wording in step 3
Not gonna lie, I'm getting tired of maintaining this second source of truth. Hopefully my laziness, impatience, and hubris will tip the scales far enough to delete it.
We're already reaping rewards for using ATR (checks+voting+email support), and I want us to do both the old way AND the new way for now. I'll consider the old release process in "soft deprecation" as the ATR matures.
All good. I tested these just now.
ATR so far does artifact checks & voting/email management.
Working with artifacts on the svn server is still our responsibility, for now.
This is to workaround an issue, UI misunderstanding, or PEBKAC with the ATR (ASF Trusted Releases) tool wherein I am unable to exclude the license header check for this file. jQuery (and its dependencies) can be used entirely under the MIT, see <https://jquery.com/license/>.
Once https://github.com/apache/tooling-trusted-releases/issues/312 ... is resolved we should be able to revert this workaround.
While this workaround is in place, consumers of apiLive.htm must:
1. put a copy of jquery-1.7.min.js next to apiLive.htm
2. change apiLive.htm to refer to jquery-1.7.min.js on a CDN
If someone needing apiLive.htm prefers the first option, they can grab a copy at https://code.jquery.com/jquery-1.7.min.js .
If they prefer the second option, they can pick a minified or unminified link listed at https://blog.jquery.com/2011/11/03/jquery-1-7-released/ and modify line 6 of apiLive.htm to refer to that instead, for example:
- <script type="text/javascript" src="jquery-1.7.min.js"></script>
+ <script type="text/javascript" src="https://code.jquery.com/jquery-1.7.min.js"></script>
There are other ways to deal with the license header check as well. For example: We could use 2nd option above (always), or finally/actually port away from apiLive.htm (it is in legacy-docs, after all).
similar to 45404bafba
All asciidoctor config must be in `fineract-doc/src/docs/en/config.adoc`.
In this case `:sectnums:` re-starts ToC section numbering partway through the ToC.
I started editing this just to fix the link to the "Pull Requests" doc (it moved from README.md to CONTRIBUTING.md), but then I saw a few other places in need of service.
* use Markdown links for readability
* add link to pull request size limit wiki page re: code dumps
* remove link to PR 1284, it doesn't add anything here and takes the reader out of context
* add link to mailing list
* add link to testing docs
- Add localized validation messages for overlap and gap errors in interest rate chart slabs
- Use DataValidatorBuilder with resource/parameter context for clean error codes
- Add unit tests for validation error codes and arguments
- Add German translations for validation messages
* release step 6: emphasize "re-run the command above"
* release step 9: link to Database Setup in e2e or integration section (currently links to e2e since `cucumber.adoc` precedes `integration.adoc` in `fineract-doc/src/docs/en/chapters/testing/index.adoc`)
* release step 10: improve rc verify instructions in voting email, based on https://lists.apache.org/thread/jk2qzjxc89hd1c8xzvhtmlbbj1m8ktbl - thread: "release process improvement (was: 🗳️ 1.13.0 for release)"
* release step 15: use current mission statement from top-level readme in release announcement email
* release/1.13.0:
don't include actual email addresses
save 1.13.0 vote result
shorten/simplify gpg key sending commands
update link to rc verification instructions
fix typos in step 9 re: running the binary
improve step 9 artifact verification gpg tips
fix tarball explosion in release step 9 🧯
cucumber.adoc: fix list continuations
further improve release steps 6 and 9
release step 6: fix sanity check example
improve staging doc and commands in release step 8
doc: remove errant config but keep :sectlinks:
clean during artifact build release step 6
FINERACT-2326: Do not remove external id if transaction got not replayed
FINERACT-2326: Fix `Trial Balance Summary with asset owner` report
FINERACT-2326: Loan point in time API now properly handles future dates
improve release branch email template
improve release process kickoff email template
"Bash(grep -n \"INSERT INTO \\\\`m_role\\\\`\\\\|INSERT INTO m_role\\\\|INSERT INTO \\\\`m_permission\\\\`\\\\|INSERT INTO m_permission\" /c/Users/adity/Music/CBS/fineract/fineract-provider/src/main/resources/sql/migrations/sample_data/load_sample_data.sql)",
"Bash(psql -U postgres -d fineract_default -c \"UPDATE databasechangelog SET md5sum = NULL WHERE id = ''0231-1'' AND filename = ''db/changelog/tenant/parts/0231_add_menu_permissions.xml'';\" -c \"UPDATE m_permission SET grouping = ''menu'' WHERE code LIKE ''MENU_%'' AND entity_name = ''MENU'';\")",
"Bash(PGPASSWORD=root psql -U postgres -d fineract_default -c \"UPDATE databasechangelog SET md5sum = NULL WHERE id = ''0231-1'' AND filename = ''db/changelog/tenant/parts/0231_add_menu_permissions.xml'';\" -c \"UPDATE m_permission SET grouping = ''menu'' WHERE code LIKE ''MENU_%'' AND entity_name = ''MENU'';\")",
"Bash(PGPASSWORD=root psql -U postgres -d fineract_default -c \"UPDATE databasechangelog SET md5sum = NULL WHERE id = ''0231-1'' AND filename = ''db/changelog/tenant/parts/0231_add_menu_permissions.xml'';\" -c \"UPDATE m_permission SET grouping = ''heading_menu'' WHERE code LIKE ''MENU_%'' AND entity_name = ''MENU'';\")",
"Bash(PGPASSWORD=root psql -h localhost -p 5432 -U postgres -d fineract_default -c \"SELECT cv.id, cv.code_value FROM m_code_value cv JOIN m_code c ON cv.code_id=c.id WHERE c.code_name='Constitution' ORDER BY cv.id;\")",
Describe the changes made and why they were made. (Ignore if these details are present on the associated Apache Fineract JIRA ticket.)
Ignore if these details are present on the associated [Apache Fineract JIRA ticket](https://github.com/apache/fineract/pull/1284).
## Checklist
## Checklist
Please make sure these boxes are checked before submitting your pull request - thanks!
Please make sure these boxes are checked before submitting your pull request - thanks!
- [ ] Write the commit message as per https://github.com/apache/fineract/#pull-requests
- [ ] Write the commit message as per [our guidelines](https://github.com/apache/fineract/blob/develop/CONTRIBUTING.md#pull-requests)
- [ ] Acknowledge that we will not review PRs that are not passing the build _("green")_ - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.
- [ ] Acknowledge that we will not review PRs that are not passing the build _("green")_ - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.
- [ ] Create/update unit or integration tests for verifying the changes made.
- [ ] Create/update [unit or integration tests](https://fineract.apache.org/docs/current/#_testing) for verifying the changes made.
- [ ] Follow coding conventions at https://cwiki.apache.org/confluence/display/FINERACT/Coding+Conventions.
- [ ] Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm with details of any API changes
- [ ] Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm with details of any API changes
- [ ]Submission is not a "code dump". (Large changes can be made "in repository" via a branch. Ask on the developer mailing list for guidance, if required.)
- [ ][This PR must not be a "code dump"](https://cwiki.apache.org/confluence/display/FINERACT/Pull+Request+Size+Limit). Large changes can be made in a branch, with assistance. Ask for help on the [developer mailing list](https://fineract.apache.org/#contribute).
FYI our guidelines for code reviews are at https://cwiki.apache.org/confluence/display/FINERACT/Code+Review+Guide.
Your assigned reviewer(s) will follow our [guidelines for code reviews](https://cwiki.apache.org/confluence/display/FINERACT/Code+Review+Guide).
"name":"CBS — CIN & DIN Verification (LincPay eKYC)",
"description":"Postman collection for CIN (Company Identification Number) and DIN (Director Identification Number) verification via the CBS Fineract KYC module.\n\nFlow:\n1. Create/update a KYC record with cinNumber and/or dinNumber\n2. Trigger verify-cin or verify-din command\n3. The backend calls LincPay eKYC API (validate-company / validate-director)\n4. On success, cinVerified/dinVerified flags are set on the KYC record",
"raw":"{\n \"kycType\": 2,\n \"riskCategory\": 2,\n \"panNumber\": \"ABCDE1234F\",\n \"gstinNumber\": \"27ABCDE1234F1Z5\",\n \"cinNumber\": \"{{cin_number}}\",\n \"dinNumber\": \"{{din_number}}\",\n \"remarks\": \"Non-individual KYC with CIN and DIN\"\n}"
},
"url":{
"raw":"{{base_url}}/clients/{{client_id}}/kyc",
"host":["{{base_url}}"],
"path":["clients","{{client_id}}","kyc"]
},
"description":"Initiate a KYC record for a non-individual client with CIN and DIN numbers.\n\n- kycType: 2 = NON_INDIVIDUAL\n- riskCategory: 1=LOW, 2=MEDIUM, 3=HIGH\n- cinNumber: 21-character Corporate Identification Number\n- dinNumber: 8-digit Director Identification Number"
"description":"Trigger CIN verification via LincPay MCA API.\n\n**Backend flow:**\n1. Reads cinNumber from the KYC record\n2. Calls LincPay: POST https://ekyc.lincpay.in/EKYC/ekyc/validate-company\n Body: { \"apiKey\": \"...\", \"cin\": \"U12345MH2020PTC123456\", \"secretKey\": \"...\" }\n3. On success: marks cinVerified=true, cinVerifiedOn=today\n4. On failure: returns error with vendor message\n\n**Prerequisites:**\n- KYC record must exist with a cinNumber set\n- KYC must not be in REJECTED status"
"body":"{\n \"developerMessage\": \"CIN number is not set on this KYC record. Update the KYC record first.\",\n \"httpStatusCode\": \"503\",\n \"defaultUserMessage\": \"CIN number is not set on this KYC record. Update the KYC record first.\",\n \"userMessageGlobalisationCode\": \"error.msg.client.kyc.cin.not.found\"\n}"
"description":"Direct call to LincPay validate-company API for testing.\nReplace apiKey and secretKey with actual credentials."
},
"response":[]
}
],
"description":"CIN (Corporate Identification Number) verification flow. CIN is a 21-character alphanumeric code allotted by MCA to companies registered under the Companies Act."
},
{
"name":"3. DIN Verification (Director)",
"item":[
{
"name":"Verify DIN — Trigger LincPay validate-director",
"event":[
{
"listen":"test",
"script":{
"exec":[
"pm.test('Status code is 200', function () {",
" pm.response.to.have.status(200);",
"});",
"",
"pm.test('DIN verified successfully', function () {",
"description":"Trigger DIN verification via LincPay MCA API.\n\n**Backend flow:**\n1. Reads dinNumber from the KYC record\n2. Calls LincPay: POST https://ekyc.lincpay.in/EKYC/ekyc/validate-director\n Body: { \"apiKey\": \"...\", \"din\": \"12345678\", \"secretKey\": \"...\" }\n3. On success: marks dinVerified=true, dinVerifiedOn=today\n4. On failure: returns error with vendor message\n\n**Prerequisites:**\n- KYC record must exist with a dinNumber set\n- KYC must not be in REJECTED status"
"body":"{\n \"developerMessage\": \"DIN number is not set on this KYC record. Update the KYC record first.\",\n \"httpStatusCode\": \"503\",\n \"defaultUserMessage\": \"DIN number is not set on this KYC record. Update the KYC record first.\",\n \"userMessageGlobalisationCode\": \"error.msg.client.kyc.din.not.found\"\n}"
First of all, **Thank You** for contributing to Apache Fineract, we're grateful for your interest in our project.
First of all, **Thank You** for contributing to Apache Fineract! We are grateful for your interest in this project.
Please do [join our developer mailing list](https://fineract.apache.org/#contribute), as it's where discussions about this project take place - say _Hi_ there!
Please join the [developer mailing list](https://fineract.apache.org/#contribute), if you have not already done so, as this is where discussions about this project take place - say _Hi_ there! Please also have a quick look at the [Code of Conduct](CODE_OF_CONDUCT.md).
Our [JIRA Dashboard](https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12335824) is another good way to see what's going on (do create a Login).
The [JIRA Dashboard](https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12335824) shows what's going on. Create a login - it can take a day or two. If you face difficulties, ask on the mailing list.
Here are a few additional useful pointers:
You don't need to be a committer to provide pull requests, but [Becoming a Committer](https://cwiki.apache.org/confluence/display/FINERACT/Becoming+a+Committer) explains the process of becoming one - just in case...
Note also [our Code of Conduct](CODE_OF_CONDUCT.md).
## Developer How To's
### How to run tests
#### Unit tests
Here's how to run the set of relatively fast and independent Fineract tests:
```bash
./gradlew test -x :twofactor-tests:test -x :oauth2-tests:test -x :integration-tests:test
```
This runs nearly 1,000 tests and completes in a few minutes on decent hardware.
They shouldn't need any special servers/services running.
#### Integration tests
Running tests with external dependencies is a multi-step process with many moving parts.
Sometimes there are arbitrary failures and the prerequisite setup can be daunting.
A full local integration test run (on a developer workstation) covering every possible test using every external service and every supported relational database engine could take an entire day - and that's assuming everything is properly configured and runs as expected.
Right now we depend on GitHub to know if "the build" is passing (it's actually multiple builds).
The authoritative source of truth for what commands/services/tests to run, how, and when are the files in `.github/workflows/`.
Output from runs based on those configuration files appears at <https://github.com/apache/fineract/actions>.
Incorrect default Java-related executables may cause test failures.
To fix this on Debian and Ubuntu systems, run the following:
This would correct, for example, a [class file version error](https://en.wikipedia.org/wiki/Java_class_file#General_layout).
You might see something like this if a Java 11 executable (class file format version 56) was the system default, but the integration tests were using Java 21 (class file format version 65):
> UnsupportedClassVersionError: com.example.package/ClassName has been compiled by a more recent version of the Java Runtime (class file version 65.0), this version of the Java Runtime only recognizes class file versions up to 55.0
The GitHub builds are run in [short-lived virtual machines](https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners), so locally reproducing the same may require additional effort, such as these extra clean-up procedures:
```bash
# Might fix `error: cannot find symbol` or other intermittent failures.
# `doc` here is a placeholder for any task(s) you are trying to run.
# 💚 This is generally very safe to run between builds.
./gradlew --refresh-dependencies doc
# Destroy anything untracked by git.
# ⚠️ This may delete something important, e.g. a finely-tuned IDE configuration.
git clean --force -dx
# Destroy various caches and configs.
# ⚠️ This may delete gibibytes of cached data, making the next build very slow.
rm -rf ~/.gradle ~/.m2 /tmp/cargo*
# Destroy any Java containers left running.
# 💚 This is generally very safe to run between builds.
(This is with the `--info` gradle argument with eyeballs added for emphasis.)
The `--rerun-tasks` gradle argument may help, or you can try destroying `~/.gradle` and other clean-up procedures as indicated above, then re-running tests.
This is useful for repeated test runs (say, for timing) when gradle would otherwise assume a task is "up-to-date" and not re-run it.
See the next section for testing in Eclipse and [here](https://fineract-academy.com) for testing in IntelliJ.
## Recommended IDEs
Apache Fineract can be developed using multiple IDEs. The most commonly used and supported IDEs are:
- **Eclipse IDE** – Fully supported and commonly used within the community.
- **IntelliJ IDEA (Community or Ultimate)** – Recommended for most developers due to excellent Gradle support and debugging experience.
The sections below provide setup guidance for each IDE.
### How to run and debug in Eclipse IDE
It is possible to run Fineract in Eclipse IDE and also to debug Fineract using Eclipse's debugging facilities.
To do this, you need to create the Eclipse project files and import the project into an Eclipse workspace:
1. Create Eclipse project files into the Fineract project by running `./gradlew cleanEclipse eclipse`
2. Import the fineract-provider project into your Eclipse workspace (File->Import->General->Existing Projects into Workspace, choose root directory fineract/fineract-provider)
3. Do a clean build of the project in Eclipse (Project->Clean...)
3. Run / debug Fineract by right clicking on org.apache.fineract.ServerApplication class and choosing Run As / Debug As -> Java Application. All normal Eclipse debugging features (breakpoints, watchpoints etc) should work as expected.
If you change the project settings (dependencies etc) in Gradle, you should redo step 1 and refresh the project in Eclipse.
You can also use Eclipse JUnit support to run tests in Eclipse (Run As->JUnit Test)
Finally, modifying source code in Eclipse automatically triggers hot code replace to a running instance, allowing you to immediately test your changes
## How to run and debug in IntelliJ IDEA
IntelliJ IDEA provides strong Gradle integration and is recommended for most new contributors.
### Prerequisites
- IntelliJ IDEA (Community Edition is sufficient)
- Java 21 (as required by Fineract)
- Gradle (wrapper included in the repository)
### Steps
1. Open IntelliJ IDEA and select **Open**
2. Choose the root `fineract` directory
3. When prompted, import the project as a **Gradle project**
4. Use the Gradle wrapper (`gradlew`) when asked
5. Ensure the correct JDK is selected (**Java 21**)
6. After import completes, run:
-`org.apache.fineract.ServerApplication` as a **Java Application**
### Notes
- IntelliJ may take several minutes to index the project on first open
- If you encounter build issues, try running `./gradlew clean build` from the terminal
How to download Gradle wrapper
---
The file gradle/wrapper/gradle-wrapper.jar binary is checked into this projects Git source repository,
but won't exist in your copy of the Fineract codebase if you downloaded a released source archive from apache.org.
In that case, you need to download it using the commands below:
1. Extract the archive file to your local directory.
2. Run `./gradlew rat`. A report will be generated under build/reports/rat/rat-report.txt
### How to build documentation
Run the following command:
```bash
./gradlew doc
```
Some dependencies are required (e.g. Ghostscript, Graphviz), see [.github/workflows/build-documentation.yml](https://github.com/apache/fineract/tree/develop/.github/workflows/build-documentation.yml) for hints.
IDEs such as IntelliJ are useful for editing the AsciiDoc source files while providing a live rendered preview.
HTML rendered from the AsciiDoc source files is also available online at [https://fineract.apache.org/docs/current/](https://fineract.apache.org/docs/current/).
## How We Code
### Checkstyle and Spotless
This project enforces its code conventions using [checkstyle.xml](config/checkstyle/checkstyle.xml) through Checkstyle and [fineractdev-formatter.xml](config/fineractdev-formatter.xml) through Spotless. They are configured to run automatically during the normal Gradle build, and fail if there are any violations detected. You can run the following command to automatically fix spotless violations:
```bash
./gradlew spotlessApply
```
Since some checks are present in both Checkstyle and Spotless, the same command can help you fix some of the Checkstyle violations too.
You can also check solely for Spotless violations, but normally don't have to, because regular builds already include this:
```bash
./gradlew spotlessCheck
```
We recommend that you configure your favourite Java IDE to match those conventions. For Eclipse, you can go to
Window > Java > Code Style and import the aforementioned [config/fineractdev-formatter.xml](config/fineractdev-formatter.xml) under formatter section and [config/fineractdev-cleanup.xml](config/fineractdev-cleanup.xml) under cleanup section.
You could also use Checkstyle directly in your IDE, but you don't have to: it may just be more convenient for you. For Eclipse, use https://checkstyle.org/eclipse-cs/ and load our checkstyle.xml into it. For IntelliJ you can use [CheckStyle-IDEA](https://plugins.jetbrains.com/plugin/1065-checkstyle-idea).
### Code Coverage
Changed or added code should ideally have test coverage.
The project uses Jacoco to measure unit tests code coverage. To generate a report run the following command:
```bash
./gradlew clean build jacocoTestReport
```
Generated reports can be found in the build/code-coverage directory.
### Lombok
The project uses [Lombok](https://projectlombok.org/) to reduce boilerplate code. Configuration is in [lombok.config](lombok.config).
* Use `@Getter` / `@Setter` / `@NoArgsConstructor` on JPA entities. Never use `@Data` on entities (causes JPA lazy loading issues).
* Use `@RequiredArgsConstructor` on service classes for constructor-based dependency injection.
* Use `@Slf4j` for logging instead of manually declaring loggers.
* Use `@Data` for simple DTOs (includes getters, setters, toString, equals, hashCode).
* Use `@Builder` with `@Builder.Default` for configuration classes and complex object construction.
* Never use `@SneakyThrows` - handle exceptions explicitly.
### Error Handling
* When catching exceptions, either rethrow them, or log them. Either way, include the root cause by using `catch (SomeException e)` and then either `throw AnotherException("..details..", e)` or `LOG.error("...context...", e)`.
* Completely empty catch blocks are VERY suspicious. Are you sure that you want to just "swallow" an exception? Really, 100% totally absolutely sure?? ;-) Such "normal exceptions which just happen sometimes but are actually not really errors" are almost always a bad idea, can be a performance issue, and typically are an indication of another problem - e.g. the use of a wrong API which throws an Exception for an expected condition, when really you would want to use another API that instead returns something empty or optional.
* In tests, you'll typically never catch exceptions, but just propagate them, with `@Test void testXYZ() throws SomeException, AnotherException`..., so that the test fails if the exception happens. Unless you actually really want to test for the occurrence of a problem - in that case, use [JUnit's Assert.assertThrows()](https://github.com/junit-team/junit4/wiki/Exception-testing) (but not `@Test(expected = SomeException.class)`).
* Never catch `NullPointerException` & Co.
### Logging
* We use [SLF4J](http://www.slf4j.org) as our logging API.
* Never, ever, use `System.out` and `System.err` or `printStackTrace()` anywhere, but always `LOG.info()` or `LOG.error()` instead.
* Use placeholder (`LOG.error("Could not... details: {}", something, exception)`) and never String concatenation (`LOG.error("Could not... details: " + something, exception)`)
* Which Log Level is appropriate?
*`LOG.error()` should be used to inform an "operator" running Fineract who supervises error logs of an unexpected condition. This includes technical problems with an external "environment" (e.g. can't reach a database), and situations which are likely bugs which need to be fixed in the code. They do NOT include e.g. validation errors for incoming API requests - that is signaled through the API response - and does (should) not be logged as an error. (Note that there is no _FATAL_ level in SLF4J; a "FATAL" event should just be logged as an _ERROR_.)
*`LOG.warn()` should be using sparingly. Make up your mind if it's an error (above) - or not!
*`LOG.info()` can be used notably for one-time actions taken during start-up. It should typically NOT be used to print out "regular" application usage information. The default logging configuration always outputs the application INFO logs, and in production under load, there's really no point to constantly spew out lots of information from frequently traversed paths in the code about what's going on. (Metrics are a better way.) `LOG.info()`*can* be used freely in tests though.
*`LOG.debug()` can be used anywhere in the code to log things that may be useful during investigations of specific problems. They are not shown in the default logging configuration, but can be enabled for troubleshooting. Developers should typically "turn down" most `LOG.info()` which they used while writing a new feature to "follow along what happens during local testing" to `LOG.debug()` for production before we merge their PRs.
*`LOG.trace()` is not used in Fineract.
## Change Process
### Dependency Upgrades
This project uses a number of 3rd-party libraries. We have set up [Renovate's bot](https://github.com/renovatebot/github-action) to automatically raise Pull Requests for our review when new dependencies are available.
Our `ClasspathHellDuplicatesCheckRuleTest` detects classes that appear in more than 1 JAR. If a version bump in [build.gradle](https://github.com/apache/fineract/blob/develop/build.gradle) causes changes in transitives dependencies, then you may have to add related `exclude` to our [dependencies.gradle](https://github.com/apache/fineract/search?q=dependencies.gradle). Running `./gradlew dependencies` helps to understand what is required.
### Pull Requests
We request that your commit message includes a FINERACT JIRA issue and a one-liner that describes the changes.
Start with an upper case imperative verb (not past form), and a short but concise clear description. (E.g. "FINERACT-821: Add enforced HideUtilityClassConstructor checkstyle").
If your PR is failing to pass our CI build due to a test failure, then:
1. Understand if the failure is due to your PR or an unrelated unstable test.
1. If you suspect it is because of a "flaky" test, and not due to a change in your PR, then please do not simply wait for an active maintainer to come and help you, but instead be a proactive contributor to the project - see next steps. Do understand that we may not review PRs that are not green - it is the contributor's (that's you!) responsibility to get a proposed PR to pass the build, not primarily the maintainers.
1. Search for the name of the failed test on https://issues.apache.org/jira/, e.g. for `AccountingScenarioIntegrationTest` you would find [FINERACT-899](https://issues.apache.org/jira/browse/FINERACT-899).
1. If you happen to read in such bug reports that tests were just recently fixed, or ignored, then rebase your PR to pick up that change.
1. If you find previous comments "proving" that the same test has arbitrarily failed in at least 3 past PRs, then please do yourself raise a small separate new PR proposing to add an `@Disabled // TODO FINERACT-123` to the respective unstable test (e.g. [#774](https://github.com/apache/fineract/pull/774)) with the commit message mentioning said JIRA, as always. (Please do NOT just `@Disabled` any existing tests mixed in as part of your larger PR.)
1. If there is no existing JIRA for the test, then first please evaluate whether the failure couldn't be a (perhaps strange) impact of the change you are proposing after all. If it's not, then please raise a new JIRA to document the suspected Flaky Test, and link it to [FINERACT-850](https://issues.apache.org/jira/browse/FINERACT-850). This will allow the next person coming along hitting the same test failure to easily find it, and eventually propose to ignore the unstable test.
1. Then (only) Close and Reopen your PR, which will cause a new build, to see if it passes.
1. Of course, we very much appreciate you then jumping onto any such bugs and helping us figure out how to fix all ignored tests!
documents that we cannot accept huge "code dump" Pull Requests, with some related suggestions.
Guideline for new Feature commits involving Refactoring: If you are submitting a PR for a new feature,
and it involves refactoring, try to differentiate "new feature code" from "refactored" by placing
them in different commits. This helps to review your code faster.
We have an automated bot which marks pull requests as "stale" after a while, and ultimately automatically closes them.
### Merge Strategy
This project's committers typically prefer to bring your pull requests in through _Rebase and Merge_ instead of _Create a Merge Commit_. (If you are unfamiliar with GitHub's UI regarding this, note the somewhat hidden little triangle drop-down at the bottom of the PR, visible only to committers, not contributors.) This avoids the "merge commits" which we consider to be somewhat "polluting" the project's commit log history view. We understand this doesn't give an easy automatic reference to the original PR (which GitHub automatically adds to the merge commit message it generates), but we consider this an only very minor inconvenience; it's typically relatively easy to find the original PR even just from the commit message, and JIRA.
We expect most proposed PRs to typically consist of a single commit. Committers may use _Squash and merge_ to combine your commits at merge time, and if they do so, will rewrite your commit message as they see fit.
Neither of these two are hard absolute rules, but mere conventions. Multiple commits in single PRs make sense in certain cases (e.g. branch backports).
### Signing Your Commits
We encourage contributors to sign commits with GPG keys. Signed commits show a "Verified" badge on GitHub.
For GPG setup instructions, see the [Fineract GPG Guide](https://fineract.apache.org/docs/current/#_gpg_2).
"description":"Creates or updates Startup India (DPIIT) entity classification. Captures DPIIT recognition number, tax exemptions under Section 80IAC, SIDBI fund eligibility, and PSL limits."
"description":"Creates or updates Non-Priority Sector (NPS) entity classification. Captures industry details, NIC code, risk categorization, AML risk classification, PEP status, and adverse media flags."
Your UI has been updated to send a comprehensive new payload with additional fields for the `/savingsproducts` POST endpoint. This document outlines **all changes required** in the backend to support these new fields.
---
## 🔍 New Fields in Your Payload
### **Simple Fields (Direct Columns in m_savings_product table)**
| Field | Type | Example | Description |
|-------|------|---------|-------------|
| accountType | String | "Small Saving Account" | Type of savings account |
"description":"Postman collection for Fineract OpenProject integration API endpoints.\n\nBase URL: {{baseUrl}}/fineract-provider/api/v1/openproject\n\nAuthentication: Basic Auth (Fineract user credentials)",
"description":"Returns a summary of all work packages grouped by status, type, and priority."
}
},
{
"name":"Create Work Package - Feature",
"request":{
"method":"POST",
"header":[
{
"key":"fineract-platform-tenantid",
"value":"{{tenantId}}"
},
{
"key":"Content-Type",
"value":"application/json"
}
],
"body":{
"mode":"raw",
"raw":"{\n \"subject\": \"Integrate OpenProject with CBS Dashboard\",\n \"description\": \"Add OpenProject work package tracking to the CBS admin dashboard so project managers can view task progress directly from the banking system.\",\n \"type\": \"Feature\"\n}"
"description":"Creates a new Feature work package in OpenProject.\n\nValid types: Task, Milestone, Summary task, Feature, Epic, User story, Bug, Incident, Support Ticket, Problem, Change Request, Enhancement"
}
},
{
"name":"Create Work Package - Task",
"request":{
"method":"POST",
"header":[
{
"key":"fineract-platform-tenantid",
"value":"{{tenantId}}"
},
{
"key":"Content-Type",
"value":"application/json"
}
],
"body":{
"mode":"raw",
"raw":"{\n \"subject\": \"Setup CI/CD pipeline for CBS deployment\",\n \"description\": \"Configure automated build and deployment pipeline for the Core Banking System.\",\n \"type\": \"Task\"\n}"
"description":"Creates a new Task work package in OpenProject."
}
},
{
"name":"Create Work Package - Bug",
"request":{
"method":"POST",
"header":[
{
"key":"fineract-platform-tenantid",
"value":"{{tenantId}}"
},
{
"key":"Content-Type",
"value":"application/json"
}
],
"body":{
"mode":"raw",
"raw":"{\n \"subject\": \"Fix loan repayment calculation rounding error\",\n \"description\": \"Loan repayment amounts show minor rounding differences when calculated with different interest methods.\",\n \"type\": \"Bug\"\n}"
"description":"Fetches latest RSS feeds from rbi.org.in (5 categories: PRESS_RELEASE, NOTIFICATION, SPEECH, TENDER, PUBLICATION) and stores new items in the database. Run this FIRST to populate data."
},
"response":[]
},
{
"name":"2. Get All Feeds",
"request":{
"method":"GET",
"header":[
{
"key":"Fineract-Platform-TenantId",
"value":"{{tenantId}}",
"type":"text"
},
{
"key":"Content-Type",
"value":"application/json",
"type":"text"
}
],
"url":{
"raw":"{{baseUrl}}/rbi-feeds",
"host":["{{baseUrl}}"],
"path":["rbi-feeds"]
},
"description":"Retrieve all RBI feed items sorted by publication date (newest first)."
},
"response":[]
},
{
"name":"3. Get Feeds by Category - PRESS_RELEASE",
<!-- TODO Reactivate when there is a working CI-CD instance: [](https://validator.swagger.io/validator/debug?url=https://sandbox.mifos.community/fineract-provider/swagger-ui/fineract.yaml) -->
<!-- TODO Reactivate when there is a working CI-CD instance: [](https://validator.swagger.io/validator/debug?url=https://sandbox.mifos.community/fineract-provider/swagger-ui/fineract.yaml) -->
[](https://www.digitalpublicgoods.net/r/apache-fineract "Apache Fineract is a verified Digital Public Good under the Digital Public Goods Alliance.")
</b>
Apache Fineract is an open-source core banking platform providing a
flexible, extensible foundation for a wide range of financial services. By
making robust banking technology openly available, it lowers barriers for
institutions and innovators to reach underserved and unbanked populations.
Fineract is a mature platform with open APIs that provides a reliable, robust, and affordable core banking solution for financial institutions offering services to the world’s 3 billion underbanked and unbanked.
Have a look at the [documentation](https://fineract.apache.org/docs/current), the [wiki](https://cwiki.apache.org/confluence/display/FINERACT) or at the [FAQ](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=91554327), if this README does not answer what you are looking for.
[Have a look at the FAQ on our Wiki at apache.org](https://cwiki.apache.org/confluence/display/FINERACT/FAQ) if this README does not answer what you are looking for. [Visit our JIRA Dashboard](https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12335824) to find issues to work on, see what others are working on, or open new issues.
COMMUNITY
COMMUNITY
=========
=========
If you are interested in contributing to this project, but perhaps don't quite know how and where to get started, please [join our developer mailing list](http://fineract.apache.org/#contribute), listen into our conversations, chime into threads, and just send us a "Hello!" introduction email; we're a friendly bunch, and look forward to hearing from you.
If you are interested in contributing to this project, but perhaps don't quite know how and where to get started, please [join our developer mailing list](http://fineract.apache.org/#contribute), listen into our conversations, chime into threads, or just send us a "Hello!" introduction email; we're a friendly bunch, and look forward to hearing from you. A more informal alternative is the [Fineract Slack channel](https://app.slack.com/client/T0F5GHE8Y/C028634A61L) (thank you, Mifos, for supporting the Slack channel!).
For the developer wiki, see [Contributor's Zone](https://cwiki.apache.org/confluence/display/FINERACT/Contributor%27s+Zone). Maybe [these how-to articles](https://cwiki.apache.org/confluence/display/FINERACT/How-to+articles) help you to get started.
In any case visit [our JIRA Dashboard](https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12335824) to find issues to work on, see what others are doing, or open new issues.
In the moment you get started writing code, please consult our [CONTRIBUTING](CONTRIBUTING.md) guidelines, where you will find more information on subjects like coding style, testing and pull requests.
REQUIREMENTS
REQUIREMENTS
============
============
* min. 16GB RAM and 8 core CPU
*`MariaDB >= 11.5.2` or `PostgreSQL >= 17.0`
*`Java >= 21` (Azul Zulu JVM is tested by our CI on GitHub Actions)
*`Java >= 21` (Azul Zulu JVM is tested by our CI on GitHub Actions)
* MariaDB `11.5.2`
You can run the required version of the database server in a container, instead of having to install it, like this:
Tomcat (min. v10) is only required, if you wish to deploy the Fineract WAR to a separate external servlet container. You do not need to install Tomcat to run Fineract. We recommend the use of the self-contained JAR, which transparently embeds a servlet container using Spring Boot.
docker run --name mariadb-11.5 -p 3306:3306 -e MARIADB_ROOT_PASSWORD=mysql -d mariadb:11.5.2
and stop and destroy it like this:
SECURITY
============
For a list of known vulnerabilities, see [Apache Fineract Security Reports](https://fineract.apache.org/security.html).
docker rm -f mariadb-11.5
If you believe you have found a new vulnerability, [let us know privately](https://fineract.apache.org/#contribute).
<br>Beware that this database container database keeps its state inside the container and not on the host filesystem. It is lost when you destroy (rm) this container. This is typically fine for development. See [Caveats: Where to Store Data on the database container documentation](https://hub.docker.com/_/mariadb) re. how to make it persistent instead of ephemeral.<br>
For details about security during development and deployment, see the documentation [here](https://fineract.apache.org/docs/current/#_security).
Tomcat v10 is only required if you wish to deploy the Fineract WAR to a separate external servlet container. Note that you do not require to install Tomcat to develop Fineract, or to run it in production if you use the self-contained JAR, which transparently embeds a servlet container using Spring Boot. (Until FINERACT-730, Tomcat 7/8 were also supported, but now Tomcat 10 is required.)
<br>IMPORTANT: If you use MySQL or MariaDB
INSTRUCTIONS
============
============
Recently (after release `1.7.0`), we introduced improved date time handling in Fineract. Date time is from now on stored in UTC and we are enforcing UTC timezone even on the JDBC driver, e. g. for MySQL:
The following how-to's assume you have Java installed, you cloned the repository (or downloaded and extracted a [specific version](https://github.com/apache/fineract/releases)) and you have a [database server](#database-and-tables) (MariaDB or PostgreSQL) running.
__DO__: If you do use MySQL as your Fineract database then the following configuration is highly recommended:
This creates two databases and builds and runs Fineract, which will be listening for API requests on port 8443 (by default) now.
* Run the application in UTC (the default command line in our Docker image has the necessary parameters already set)
* Run the MySQL database server in UTC (if you use managed services like AWS RDS then this should be the default anyway, but it would be good to double-check)
__DON'T__: In case the Fineract instance and the MySQL server are __not__ running in UTC then the following could happen:
* MySQL is saving date time values differently from PostgreSQL
* Example scenario: if the Fineract instance runs in timezone: GMT+2, and the local date time is 2022-08-11 17:15 ...
* ... then __PostgreSQL saves__ the LocalDateTime as is: __2022-08-11 17:15__
* ... and __MySQL saves__ the LocalDateTime in UTC: __2022-08-11 15:15__
* ... but when we __read__ the date time from PostgreSQL __or__ from MySQL, then both systems give us the same values: __2022-08-11 17:15 GMT+2__
If a previously used Fineract instance didn't run in UTC (backward compatibility), then all prior dates will be read wrongly by MySQL/MariaDB. This can cause issues when you run the database migration scripts.
__RECOMMENDATION__: you need to shift all dates in your database by the timezone offset that your Fineract instance used.
<br>INSTRUCTIONS: How to run for local development
============
Run the following commands:
1.`./gradlew createDB -PdbName=fineract_tenants`
1.`./gradlew createDB -PdbName=fineract_default`
1.`./gradlew devRun`
Fineract is now running, and will be listening for API requests on port 8443 by default.
1. Clone the repository or download and extract the archive file to your local directory.
Running Fineract to try it out is relatively easy. If you intend to use it in a production environment, be aware that a proper deployment can be complex, costly, and time-consuming. Considerations include: Security, privacy, compliance, performance, service availability, backups, and more. The Fineract project does not provide a comprehensive guide for deploying Fineract in production. You might need skills in enterprise Java applications and more. Alternatively, you could pay a vendor for Fineract deployment and maintenance. You will find tips and tricks for deploying and securing Fineract in our official documentation and in the community-maintained wiki.
2. Run `./gradlew clean bootJar` to build a modern cloud native fully self contained JAR file which will be created at `fineract-provider/build/libs` directory.
3. As we are not allowed to include a JDBC driver in the built JAR, download a JDBC driver of your choice. For example: `wget https://dlm.mariadb.com/4174416/Connectors/java/connector-java-3.5.2/mariadb-java-client-3.5.2.jar`
4. Start the jar and pass the directory where you have downloaded the JDBC driver as loader.path, for example: `java -Dloader.path=. -jar fineract-provider/build/libs/fineract-provider.jar` (does not require external Tomcat)
The tenants database connection details are configured [via environment variables (as with Docker container)](#instructions-to-run-using-docker-and-docker-compose), e.g. like this:
export FINERACT_HIKARI_PASSWORD=verysecret
...
java -jar fineract-provider.jar
<br>SECURITY
How to build the JAR file
============
---
If you believe you have found a security vulnerability, [let us know privately](https://fineract.apache.org/#contribute).
Build a modern, cloud native, fully self contained JAR file:
```bash
./gradlew clean bootJar
```
The JAR will be created in the `fineract-provider/build/libs` directory.
As we are not allowed to include a JDBC driver in the built JAR, download a JDBC driver of your choice. For example:
For details about security during development and deployment, see <https://fineract.apache.org/docs/current/#_security>.
The tenants database connection details are configured [via environment variables (as with Docker container)](#instructions-to-run-using-docker-or-podman), e.g. like this:
```bash
exportFINERACT_HIKARI_PASSWORD=verysecret
...
java -jar fineract-provider.jar
```
How to build the WAR file
<br>INSTRUCTIONS: How to build a WAR file
---
============
Build a traditional WAR file:
1. Clone the repository or download and extract the archive file to your local directory.
```bash
2. Run `./gradlew :fineract-war:clean :fineract-war:war` to build a traditional WAR file which will be created at `fineract-war/build/libs` directory.
./gradlew :fineract-war:clean :fineract-war:war
3. Deploy this WAR to your Tomcat v10 Servlet Container.
```
The WAR will be created in the `fineract-war/build/libs` directory. Afterwards deploy the WAR to your Tomcat Servlet Container.
We recommend using the JAR instead of the WAR file deployment, because it's much easier.
We recommend using the JAR instead of the WAR file deployment, because it's much easier.
Note that with the 1.4 release the tenants database pool configuration changed from Tomcat DBCP in XML to an embedded Hikari, configured by environment variables, see above.
How to run using Docker or Podman
INSTRUCTIONS: How to run tests
---
============
Unit tests
----------
Here's how to run the set of relatviely fast and indepedent Fineract tests:
```bash
./gradlew test -x :twofactor-tests:test -x :oauth2-tests:test -x :integration-tests:test
```
This runs nearly 1,000 tests and completes in a few minutes on decent hardware.
They shouldn't need any special servers/services running.
Integration tests
-----------------
Running tests with external dependencies yourself is a multi-step process with many moving parts.
Sometimes there are arbitrary failures and the prerequisite setup can be daunting.
A full local integration test run (on a developer workstation) covering every possible test using every external service and every supported relational database engine could take an entire day, and that's assuming everything is properly configured and runs as expected.
Right now we depend on GitHub to know if "the build" is passing (it's actually multiple builds).
The authoritative source of truth for what commands/services/tests to run, how, and when are the files in `.github/workflows/`.
Output from runs based on those configuration files appears at <https://github.com/apache/fineract/actions>.
Incorrect default Java-related executables may cause test failures.
To fix this on Debian and Ubuntu systems, run the following:
This would correct, for example, a [class file verson error](https://en.wikipedia.org/wiki/Java_class_file#General_layout).
You might see something like this if a Java 11 executable (class file format version 56) was the system default, but the integration tests were using Java 21 (class file format version 65):
```
UnsupportedClassVersionError: com.example.package/ClassName has been compiled by a more recent version of the Java Runtime (class file version 65.0), this version of the Java Runtime only recognizes class file versions up to 55.0
```
The GitHub builds are run in [short-lived virtual machines](https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners), so locally reproducing the same may require additional effort, such as these extra clean-up procedures:
```bash
# Might fix `error: cannot find symbol` or other intermittent failures.
# `doc` here is a placeholder for any task(s) you are trying to run.
# 💚 This is generally very safe to run between builds.
./gradlew --refresh-dependencies doc
# Destroy anything untracked by git.
# ⚠️ This may delete something important, e.g. a finely-tuned IDE configuration.
git clean --force -dx
# Destroy various caches and configs.
# ⚠️ This may delete gibibytes of cached data, making the next build very slow.
rm -rf ~/.gradle ~/.m2 /tmp/cargo*
# Destroy any Java containers left running.
# 💚 This is generally very safe to run between builds.
Integration test runs such as `./gradlew --no-daemon --console=plain test -x :twofactor-tests:test -x :oauth2-test:test :fineract-e2e-tests-runner:test -PdbType=postgresql` in `.github/workflows/build-postgresql.yml` often take an hour or longer to complete.
If you notice the `:integration-tests:test` task taking significantly less time, say, one minute, gradle may be skipping it.
Look for something like this in the test output:
```
> Task :integration-tests:test UP-TO-DATE 👀
Custom actions are attached to task ':integration-tests:test'.
Build cache key for task ':integration-tests:test' is 6aeeec3f58bf9703d4c100fbaa657f5c
Skipping task ':integration-tests:test' as it is up-to-date.
Resolve mutations for :integration-tests:cargoStopLocal (Thread[Execution worker Thread 11,5,main]) started.
(This is with the `--info` gradle argument with eyeballs added for emphasis)
The `--rerun-tasks` gradle argument may help, or you can try destroying `~/.gradle` and other clean-up procedures as indicated above then re-running tests.
This is useful for repeated test runs (say, for timing) when gradle would otherwise assume a task is "up-to-date" and not re-run it.
Testing within IDEs
-----------------
See the next section for testing in Eclipse.
See <https://fineract-academy.com> for testing in IntelliJ.
INSTRUCTIONS: How to run and debug in Eclipse IDE
============
It is possible to run Fineract in Eclipse IDE and also to debug Fineract using Eclipse's debugging facilities.
To do this, you need to create the Eclipse project files and import the project into an Eclipse workspace:
1. Create Eclipse project files into the Fineract project by running `./gradlew cleanEclipse eclipse`
2. Import the fineract-provider project into your Eclipse workspace (File->Import->General->Existing Projects into Workspace, choose root directory fineract/fineract-provider)
3. Do a clean build of the project in Eclipse (Project->Clean...)
3. Run / debug Fineract by right clicking on org.apache.fineract.ServerApplication class and choosing Run As / Debug As -> Java Application. All normal Eclipse debugging features (breakpoints, watchpoints etc) should work as expected.
If you change the project settings (dependencies etc) in Gradle, you should redo step 1 and refresh the project in Eclipse.
You can also use Eclipse Junit support to run tests in Eclipse (Run As->Junit Test)
Finally, modifying source code in Eclipse automatically triggers hot code replace to a running instance, allowing you to immediately test your changes
INSTRUCTIONS: How to run using Docker and docker-compose
1. install the Loki log driver with `docker plugin install grafana/loki-docker-driver:latest --alias loki --grant-all-permissions`
1.`docker compose -f docker-compose-development.yml up -d`
1. fineract (back-end) is running at https://localhost:8443/fineract-provider/
1. wait for https://localhost:8443/fineract-provider/actuator/health to return `{"status":"UP"}`
1. you must go to https://localhost:8443 and remember to accept the self-signed SSL certificate of the API once in your browser, otherwise you get a message that is rather misleading from the UI.
1. community-app (UI) is running at http://localhost:9090/?baseApiUrl=https://localhost:8443/fineract-provider&tenantIdentifier=default
1. login using default _username_`mifos` and _password_`password`
https://hub.docker.com/r/apache/fineract has a pre-built container image of this project, built continuously.
You must specify the MySQL tenants database JDBC URL by passing it to the `fineract` container via environment
You must specify the MySQL tenants database JDBC URL by passing it to the `fineract` container via environment
variables; please consult the [`docker-compose.yml`](docker-compose.yml) for exact details how to specify those.
variables; please consult the [`docker-compose.yml`](docker-compose.yml) for exact details how to specify those.
_(Note that in previous versions, the `mysqlserver` environment variable used at `docker build` time instead of at
`docker run` time did something similar; this has changed in [FINERACT-773](https://issues.apache.org/jira/browse/FINERACT-773)),
and the `mysqlserver` environment variable is now no longer supported.)_
The logfiles and the Java Flight Recorder output are available in `PROJECT_ROOT/build/fineract/logs`. If you use IntelliJ then you can double-click on the `.jfr` file and open it with the IDE. You can also download Azul Mission Control from here https://www.azul.com/products/components/azul-mission-control/ to analyze the Java Flight Recorder file.
The logfiles and the Java Flight Recorder output are available in `PROJECT_ROOT/build/fineract/logs`. If you use IntelliJ then you can double-click on the `.jfr` file and open it with the IDE. You can also download [Azul Mission Control](https://www.azul.com/products/components/azul-mission-control/) to analyze the Java Flight Recorder file.
NOTE: If you have issues with the file permissions and Docker Compose then you might need to change the variable values for `FINERACT_USER` and `FINERACT_GROUP` in `PROJECT_ROOT/config/docker/env/fineract-common.env`. You can find out what values you need to put there with the following commands:
NOTE: If you have issues with the file permissions and Docker Compose then you might need to change the variable values for `FINERACT_USER` and `FINERACT_GROUP` in `PROJECT_ROOT/config/docker/env/fineract-common.env`. You can find out what values you need to put there with the following commands:
```
id -u ${USER}
id -u ${GROUP}
```
Please make sure that you are not checking in your changed values. The defaults should normally work for most people.
Some dependencies are required (e.g. Ghostscript, Graphviz), see `.github/workflows/build-documentation.yml` for hints.
Please make sure that you are not checking in your changed values. The defaults should work for most people.
Additionally, IDEs such as IntelliJ are useful for editing the AsciiDoc source files while providing a live rendered preview.
HTML rendered from the AsciiDoc source files is also available online at <https://fineract.apache.org/docs/current/>.
A release version is derived from source control. The version will include `-SNAPSHOT` unless the current branch looks like a release or release maintenance branch. See `gitVersioning` settings in `build.gradle` for details.
Connection pool configuration
=============================
Please check `application.properties` to see which connection pool settings can be tweaked. The associated environment variables are prefixed with `FINERACT_HIKARI_*`. You can find more information about specific connection pool settings (Hikari) at https://github.com/brettwooldridge/HikariCP#configuration-knobs-baby
NOTE: we'll keep backwards compatibility until one of the next releases to ensure that things are working as expected. Environment variables prefixed `fineract_tenants_*` can still be used to configure the database connection, but we strongly encourage using `FINERACT_HIKARI_*` with more options.
<br>SSL CONFIGURATION
=================
See [the HTTPS related doc](https://fineract.apache.org/docs/current/#_https).
<br>TOMCAT CONFIGURATION
How to run on Kubernetes
====================
---
Please refer to the `application.properties` and the official Spring Boot documentation (https://docs.spring.io/spring-boot/docs/current/reference/html/application-properties.html) on how to do performance tuning for Tomcat. Note: you can set now the acceptable form POST size (default is 2MB) via environment variable `FINERACT_SERVER_TOMCAT_MAX_HTTP_FORM_POST_SIZE`.
### General Clusters
<br>INSTRUCTIONS: How to run on Kubernetes
=================================
<br>General Clusters
----------------
You can also run Fineract using containers on a Kubernetes cluster.
You can also run Fineract using containers on a Kubernetes cluster.
Make sure you set up and connect to your Kubernetes cluster.
Make sure you set up and connect to your Kubernetes cluster.
@@ -321,72 +181,81 @@ You can follow [this](https://cwiki.apache.org/confluence/display/FINERACT/Insta
Now e.g. from your Google Cloud shell, run the following commands:
Now e.g. from your Google Cloud shell, run the following commands:
1.`git clone https://github.com/apache/fineract.git ; cd fineract/kubernetes`
```bash
1.`./kubectl-startup.sh`
git clone https://github.com/apache/fineract.git
cd fineract/kubernetes
./kubectl-startup.sh
```
To shutdown and reset your Cluster, run:
To shutdown and reset your Cluster, run:
```bash
./kubectl-shutdown.sh
```
./kubectl-shutdown.sh
### Using Minikube
Using Minikube
--------------
Alternatively, you can run fineract on a local kubernetes cluster using [minikube](https://minikube.sigs.k8s.io/docs/).
Alternatively, you can run fineract on a local kubernetes cluster using [minikube](https://minikube.sigs.k8s.io/docs/).
As Prerequisites, you must have `minikube` and `kubectl` installed on your machine; see
As prerequisite you must have `minikube` and `kubectl` installed on your machine; see
Now to run a new Fineract instance on Minikube you can simply:
To run a new Fineract instance on Minikube you can simply:
1.`git clone https://github.com/apache/fineract.git ; cd fineract/kubernetes`
```bash
1.`minikube start`
git clone https://github.com/apache/fineract.git
1.`./kubectl-startup.sh`
cd fineract/kubernetes
1.`minikube service fineract-server --url --https`
minikube start
1. Fineract is now running at the printed URL (note HTTP), which you can check e.g. using:
./kubectl-startup.sh
```
http --verify=no --timeout 240 --check-status get $(minikube service fineract-server --url --https)/fineract-provider/actuator/health
Wait for all pods to be ready:
```bash
kubectl get pods -w
```
Once all pods are running, access the Mifos web application:
```bash
minikube service mifos-community
```
This opens the Mifos X web application in your browser. The nginx reverse proxy in the mifos-community pod forwards API requests to the fineract-server backend.
**Default credentials:**
- Username: `mifos`
- Password: `password`
You can also access the Fineract API directly:
```bash
minikube service fineract-server --url --https
```
Fineract is now running at the printed URL, which you can check e.g. using:
```bash
http --verify=no --timeout 240 --check-status get $(minikube service fineract-server --url --https)/fineract-provider/actuator/health
```
To check the status of your containers on your local minikube Kubernetes cluster, run:
To check the status of your containers on your local minikube Kubernetes cluster, run:
```bash
minikube dashboard
minikube dashboard
```
You can check Fineract logs using:
You can check Fineract logs using:
```bash
kubectl logs deployment/fineract-server
```
kubectl logs deployment/fineract-server
You can check Mifos web app logs using:
```bash
kubectl logs deployment/mifos-community
```
To shutdown and reset your cluster, run:
To shutdown and reset your cluster, run:
```bash
./kubectl-shutdown.sh
./kubectl-shutdown.sh
```
To shutdown and reset your cluster, run:
minikube ssh
sudo rm -rf /mnt/data/
We have [some open issues in JIRA with Kubernetes related enhancement ideas](https://jira.apache.org/jira/browse/FINERACT-783?jql=labels%20%3D%20kubernetes%20AND%20project%20%3D%20%22Apache%20Fineract%22%20) which you are welcome to contribute to.
INSTRUCTIONS: How to download Gradle wrapper
How to enable External Message Broker (ActiveMQ or Apache Kafka)
============
---
The file gradle/wrapper/gradle-wrapper.jar binary is checked into this projects Git source repository,
but won't exist in your copy of the Fineract codebase if you downloaded a released source archive from apache.org.
In that case, you need to download it using the commands below:
INSTRUCTIONS: How to run Apache RAT (Release Audit Tool)
============
1. Extract the archive file to your local directory.
2. Run `./gradlew rat`. A report will be generated under build/reports/rat/rat-report.txt
INSTRUCTIONS: How to enable External Message Broker (ActiveMQ or Apache Kafka)
============
There are two use-cases where external message broker is needed:
There are two use-cases where external message broker is needed:
- External Business Events / Reliable Event Framework
- External Business Events / Reliable Event Framework
@@ -394,10 +263,11 @@ There are two use-cases where external message broker is needed:
External Events are business events, e.g.: `ClientCreated`, which might be important for third party systems. Apache Fineract supports ActiveMQ (or other JMS compliant brokers) and Apache Kafka endpoints for sending out Business Events. By default, they are not emitted.
External Events are business events, e.g.: `ClientCreated`, which might be important for third party systems. Apache Fineract supports ActiveMQ (or other JMS compliant brokers) and Apache Kafka endpoints for sending out Business Events. By default, they are not emitted.
In case of a large deployment with millions of accounts, the Close of Business Day Spring Batch job may run several hours. In order to speed up this task, remote partitioning of the job is supported. The Manager node partitions (breaks up) the COB job into smaller pieces (sub tasks) which then can be executed on multiple Worker nodes in parallel. The worker nodes are notified either by ActiveMQ or Kafka regarding their new sub tasks.
In case of a large deployment with millions of accounts, the Close of Business Day Spring Batch job may run several hours. In order to speed up this task, remote partitioning of the job is supported. The Manager node partitions breaks up the COB job into smaller pieces (sub tasks), which then can be executed on multiple Worker nodes in parallel. The worker nodes are notified either by ActiveMQ or Kafka regarding their new sub tasks.
### Active MQ
JMS based messaging is disabled by default. In `docker-compose-postgresql-activemq.yml` an example is shown where ActiveMQ is enabled. In that configuration one Spring Batch Manager instance and two Spring Batch Worker instances are created.
### ActiveMQ
JMS based messaging is disabled by default. In `docker-compose-postgresql-activemq.yml` an example is shown, where ActiveMQ is enabled. In that configuration one Spring Batch Manager instance and two Spring Batch Worker instances are created.
Spring based events should be disabled and jms based event handling should be enabled. Furthermore, proper broker JMS URL should be configured.
Spring based events should be disabled and jms based event handling should be enabled. Furthermore, proper broker JMS URL should be configured.
```
```
@@ -410,186 +280,92 @@ For additional ActiveMQ related configuration please take a look to the `applica
### Kafka
### Kafka
Kafka support also disabled by default. In `docker-compose-postgresql-kafka.yml` an example is shown where self-hosted Kafka is enabled for both External Events and Spring Batch Remote Job execution.
Kafka support is also disabled by default. In `docker-compose-postgresql-kafka.yml` an example is shown, where self-hosted Kafka is enabled for both External Events and Spring Batch Remote Job execution.
During the development Fineract was tested with PLAINTEXT Kafka brokers without authentication and with AWS MSK using IAM authentication. The extra [jar file](https://github.com/aws/aws-msk-iam-auth/releases) required for IAM authentication is already added to the classpath.
During the development Fineract was tested with PLAINTEXT Kafka brokers without authentication and with AWS MSK using IAM authentication. The extra [JAR file](https://github.com/aws/aws-msk-iam-auth/releases) required for IAM authentication is already added to the classpath.
An example MSK setup can be found in `docker-compose-postgresql-kafka-msk.yml`.
An example MSK setup can be found in `docker-compose-postgresql-kafka-msk.yml`.
The full list of supported Kafka related properties are documented here: https://fineract.apache.org/docs/current/
The full list of supported Kafka related properties is documented in the [Fineract Platform documentation](https://fineract.apache.org/docs/current/).
Checkstyle and Spotless
DATABASE AND TABLES
===================
You can run the required version of the database server in a container, instead of having to install it, like this:
docker run --name mariadb-11.5 -p 3306:3306 -e MARIADB_ROOT_PASSWORD=mysql -d mariadb:11.5.2
and stop and destroy it like this:
docker rm -f mariadb-11.5
Beware that this container database keeps its state inside the container and not on the host filesystem. It is lost when you destroy (rm) this container. This is typically fine for development. See [Caveats: Where to Store Data on the database container documentation](https://hub.docker.com/_/mariadb) regarding how to make it persistent instead of ephemeral.
MySQL/MariaDB and UTC timezone
---
With release `1.8.0` we introduced improved date time handling in Fineract. Date time is stored in UTC, and UTC timezone enforced even on the JDBC driver, e. g. for MySQL:
If you use MySQL as Fineract database, the following configuration is highly recommended:
* Run the application in UTC (the default command line in our Docker image has the necessary parameters already set)
* Run the MySQL database server in UTC (if you use managed services like AWS RDS, then this should be the default anyway, but it would be good to double-check)
In case Fineract and MySQL do not run in UTC, MySQL might save date time values differently from PostgreSQL
Example scenario: If the Fineract instance runs in timezone: GMT+2, and the local date time is 2022-08-11 17:15 ...
* ... then PostgreSQL saves the LocalDateTime as is: 2022-08-11 17:15
* ... and MySQL saves the LocalDateTime in UTC: 2022-08-11 15:15
* ... but when we read the date time from PostgreSQL or from MySQL, both systems give us the same value: 2022-08-11 17:15 GMT+2
If a previously used Fineract instance didn't run in UTC (backward compatibility), all prior dates will be read wrongly by MySQL. This can cause issues, when you run the database migration scripts.
Recommendation: Shift all dates in your database by the timezone offset that your Fineract instance used.
CONNECTION POOL CONFIGURATION
=======
Please check `application.properties` to see which connection pool settings can be tweaked. The associated environment variables are prefixed with `FINERACT_HIKARI_*`. You can find more information about specific connection pool settings at the [HikariCP Github repository](https://github.com/brettwooldridge/HikariCP?tab=readme-ov-file#gear-configuration-knobs-baby).
NOTE: We keep backwards compatibility until one of the next releases to ensure that things are working as expected. Environment variables prefixed `fineract_tenants_*` can still be used to configure the database connection, but we strongly encourage using `FINERACT_HIKARI_*` with more options.
RELEASES
============
============
This project enforces its code conventions using [checkstyle.xml](config/checkstyle/checkstyle.xml) through Checkstyle and [fineract-formatting-preferences.xml](config/fineract-formatting-preferences.xml) through Spotless. They are configured to run automatically during the normal Gradle build, and fail if there are any violations detected. You can run the following command to automatically fix spotless violations:
[Official releases](https://fineract.apache.org/#downloads) are created quarterly, at the end of each quarter. Our [documented release procedure](https://fineract.apache.org/docs/current/#_releases) follows the [ASF release policy](https://www.apache.org/legal/release-policy.html).
`./gradlew spotlessApply`
See <https://cwiki.apache.org/confluence/display/FINERACT/Fineract+Releases> for an archive of historical release notes along with JIRA issues relevant to each release.
Since some checks are present in both Checkstyle and Spotless, the same command can help you fix some of the Checkstyle violations (but not all, other Checkstyle violations need to fixed manually).
See <https://github.com/apache/fineract/releases> for a list of PRs and contributors for each release.
You can also check for Spotless violations (only; but normally don't have to, because the regular build full already includes this anyway):
EOL/unsupported releases are [archived](https://www.apache.org/legal/release-policy.html#archived).
`./gradlew spotlessCheck`
Versioned build products created from the `develop` branch will include `-SNAPSHOT`. See [related settings](https://github.com/qoomon/gradle-git-versioning-plugin) near `version` and `gitVersioning` in `build.gradle` for details.
We recommend that you configure your favourite Java IDE to match those conventions. For Eclipse, you can go to
Window > Java > Code Style and import our [config/fineractdev-formatter.xml](config/fineractdev-formatter.xml) under formatter section and [config/fineractdev-cleanup.xml](config/fineractdev-cleanup.xml) under Clean up section. The same fineractdev-formatter.xml configuration file (that can be used in Eclipse IDE) is also used by Spotless to both check for violations and autoformat code on the CLI.
You could also use Checkstyle directly in your IDE (but you don't neccesarily have to, it may just be more convenient for you). For Eclipse, use https://checkstyle.org/eclipse-cs/ and load our checkstyle.xml into it, for IntelliJ you can use [CheckStyle-IDEA](https://plugins.jetbrains.com/plugin/1065-checkstyle-idea).
Code Coverage Reports
LICENSE
============
============
The project uses Jacoco to measure unit tests code coverage, to generate a report run the following command:
This project is licensed under [Apache License Version 2.0](https://github.com/apache/fineract/blob/develop/APACHE_LICENSETEXT.md).
`./gradlew clean build jacocoTestReport`
The Connector/J JDBC Driver client library from [MariaDB](https://www.mariadb.org) is licensed under the LGPL.
The library is often used in development when running integration tests that use the Liquibase library. That JDBC
Generated reports can be found in build/code-coverage directory.
driver is however not distributed with the Fineract product and is not required to use the product.
If you are a developer and object to using the LGPL licensed Connector/J JDBC driver,
simply do not run the integration tests that use the Liquibase library and use another JDBC driver.
Versions
============
The latest stable release can be viewed on the develop branch: [Latest Release on Develop](https://github.com/apache/fineract/tree/develop "Latest Release").
The progress of this project can be viewed here: [View change log](https://github.com/apache/fineract/blob/develop/CHANGELOG.md "Latest release change log")
License
============
This project is licensed under Apache License Version 2.0. See <https://github.com/apache/fineract/blob/develop/APACHE_LICENSETEXT.md> for reference.
The Connector/J JDBC Driver client library from MariaDB.org, which is licensed under the LGPL,
is used in development when running integration tests that use the Liquibase library. That JDBC
driver is however not included in and distributed with the Fineract product and is not
required to use the product.
If you are developer and object to using the LGPL licensed Connector/J JDBC driver,
simply do not run the integration tests that use the Liquibase library and/or use another JDBC driver.
As discussed in [LEGAL-462](https://issues.apache.org/jira/browse/LEGAL-462), this project therefore
As discussed in [LEGAL-462](https://issues.apache.org/jira/browse/LEGAL-462), this project therefore
complies with the [Apache Software Foundation third-party license policy](https://www.apache.org/legal/resolved.html).
complies with the [Apache Software Foundation third-party license policy](https://www.apache.org/legal/resolved.html).
<br><br>APACHE FINERACT PLATFORM API
PLATFORM API
============
============
The API for Fineract is documented in [apiLive.htm](fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm), and the [apiLive.htm can be viewed on fineract.apache.org](https://fineract.apache.org/docs/legacy/ "API Documentation"). If you have your own Fineract instance running, you can find this documentation under [/fineract-provider/legacy-docs/apiLive.htm](https://localhost:8443/fineract-provider/legacy-docs/apiLive.htm).
Fineract does not provide a UI, but provides an API. Running Fineract locally, the Swagger documentation can be accessed under `https://localhost:8443/fineract-provider/swagger-ui/index.html`. A live version can be accessed via [this Sandbox](https://sandbox.mifos.community/fineract-provider/swagger-ui/index.html) (not hosted by us).
The Swagger documentation (work in progress; see [FINERACT-733](https://issues.apache.org/jira/browse/FINERACT-733)) can be accessed under [/fineract-provider/swagger-ui/index.html](https://localhost:8443/fineract-provider/swagger-ui/index.html) and [live Swagger UI here on Fineract.dev](https://sandbox.mifos.community/fineract-provider/swagger-ui/index.html).
Apache Fineract supports client code generation using [Swagger Codegen](https://github.com/swagger-api/swagger-codegen) based on the [OpenAPI Specification](https://swagger.io/specification/). For more instructions on how to generate client code, check [this section](https://fineract.apache.org/docs/current/#_generate_api_client) of the Fineract documentation. [This video](https://www.youtube.com/watch?v=FlVd-0YAo6c) documents the use of the Swagger-UI.
Apache Fineract supports client code generation using [Swagger Codegen](https://github.com/swagger-api/swagger-codegen) based on the [OpenAPI Specification](https://swagger.io/specification/). For more instructions on how to generate the client code, check [fineract-doc/src/docs/en/chapters/sdk/client.adoc](fineract-doc/src/docs/en/chapters/sdk/client.adoc).
<br>API CLIENTS (Web UIs, Mobile, etc.)
============
* https://github.com/openMF/community-app/ is the "traditional" Reference Client App Web UI for the API offered by this project
* https://github.com/openMF/web-app is the next generation UI rewrite also using this project's API
* https://github.com/openMF/android-client is an Android Mobile App client for this project's API
* https://github.com/openMF has more related proejcts
<br>ONLINE DEMOS
============
* [sandbox.mifos.community](https://sandbox.mifos.community) always runs the latest version of this code
* [demo.mifos.io](https://demo.mifos.io) A demo account is provided for users to experience the functionality of the Community App. Users can use "mifos" for USERNAME and "password" for PASSWORD (without quotation marks).
* [Swagger-UI Demo video](https://www.youtube.com/watch?v=FlVd-0YAo6c) This is a demo video for Swagger-UI documentation, more information [here](https://github.com/apache/fineract#swagger-ui-documentation).
<br>DEVELOPERS
============
Please see <https://cwiki.apache.org/confluence/display/FINERACT/Contributor%27s+Zone> for the developers wiki page.
Please refer to <https://cwiki.apache.org/confluence/display/FINERACT/Fineract+101> for the first-time contribution to this project.
Please see <https://cwiki.apache.org/confluence/display/FINERACT/How-to+articles> for technical details to get started.
Please visit [our JIRA Dashboard](https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12335824) to find issues to work on, see what others are working on, or open new issues.
<br>VIDEO DEMONSTRATION
============
Apache Fineract / Mifos X Demo (November 2016) - <https://www.youtube.com/watch?v=h61g9TptMBo>
<br>SWAGGER UI DEMONSTRATION
============
We use Swagger-UI to generate and maintain our API documentation, you can see the demo video [here](https://www.youtube.com/watch?v=FlVd-0YAo6c) or a live version
[here](https://sandbox.mifos.community/fineract-provider/swagger-ui/index.html). If you interested to know more about Swagger-UI you can check their [website](https://swagger.io/).
<br>GOVERNANCE AND POLICIES
=======================
[Becoming a Committer](https://cwiki.apache.org/confluence/display/FINERACT/Becoming+a+Committer)
documents the process through which you can become a committer in this project.
<br>ERROR HANDLING GUIDELINES
------------------
* When catching exceptions, either rethrow them, or log them. Either way, include the root cause by using `catch (SomeException e)` and then either `throw AnotherException("..details..", e)` or `LOG.error("...context...", e)`.
* Completely empty catch blocks are VERY suspicous! Are you sure that you want to just "swallow" an exception? Really, 100% totally absolutely sure?? ;-) Such "normal exceptions which just happen sometimes but are actually not really errors" are almost always a bad idea, can be a performance issue, and typically are an indication of another problem - e.g. the use of a wrong API which throws an Exception for an expected condition, when really you would want to use another API that instead returns something empty or optional.
* In tests, you'll typically never catch exceptions, but just propagate them, with `@Test void testXYZ() throws SomeException, AnotherException`..., so that the test fails if the exception happens. Unless you actually really want to test for the occurence of a problem - in that case, use [JUnit's Assert.assertThrows()](https://github.com/junit-team/junit4/wiki/Exception-testing) (but not `@Test(expected = SomeException.class)`).
* Never catch `NullPointerException` & Co.
<br>LOGGING GUIDELINES
------------------
* We use [SLF4J](http://www.slf4j.org) as our logging API.
* Never, ever, use `System.out` and `System.err` or `printStackTrace()` anywhere, but always `LOG.info()` or `LOG.error()` instead.
* Use placeholder (`LOG.error("Could not... details: {}", something, exception)`) and never String concatenation (`LOG.error("Could not... details: " + something, exception)`)
* Which Log Level is appropriate?
*`LOG.error()` should be used to inform an "operator" running Fineract who supervises error logs of an unexpected condition. This includes technical problems with an external "environment" (e.g. can't reach a database), and situations which are likely bugs which need to be fixed in the code. They do NOT include e.g. validation errors for incoming API requests - that is signaled through the API response - and does (should) not be logged as an error. (Note that there is no _FATAL_ level in SLF4J; a "FATAL" event should just be logged as an _ERROR_.)
*`LOG.warn()` should be using sparingly. Make up your mind if it's an error (above) - or not!
*`LOG.info()` can be used notably for one-time actions taken during start-up. It should typically NOT be used to print out "regular" application usage information. The default logging configuration always outputs the application INFO logs, and in production under load, there's really no point to constantly spew out lots of information from frequently traversed paths in the code about what's going on. (Metrics are a better way.) `LOG.info()`*can* be used freely in tests though.
*`LOG.debug()` can be used anywhere in the code to log things that may be useful during investigations of specific problems. They are not shown in the default logging configuration, but can be enabled for troubleshooting. Developers should typically "turn down" most `LOG.info()` which they used while writing a new feature to "follow along what happens during local testing" to `LOG.debug()` for production before we merge their PRs.
*`LOG.trace()` is not used in Fineract.
Pull Requests
-------------
We request that your commit message include a FINERACT JIRA issue, and a one-liner that describe the changes.
Start with an upper case imperative verb (not past form), and a short but concise clear description. (E.g. "FINERACT-821: Add enforced HideUtilityClassConstructor checkstyle").
If your PR is failing to pass our CI build due to a test failure, then:
1. Understand if the failure is due to your PR or an unrelated unstable test.
1. If you suspect it is because of a "flaky" test, and not due to a change in your PR, then please do not simply wait for an active maintainer to come and help you, but instead be a proactive contributor to the project - see next steps. Do understand that we may not review PRs that are not green - it is the contributor's (that's you!) responsability to get a proposed PR to pass the build, not primarily the maintainers.
1. Search for the name of the failed test on https://issues.apache.org/jira/, e.g. for `AccountingScenarioIntegrationTest` you would find [FINERACT-899](https://issues.apache.org/jira/browse/FINERACT-899).
1. If you happen to read in such bugs that tests were just recently fixed, or ignored, then rebase your PR to pick up that change.
1. If you find previous comments "proving" that the same test has arbitrarily failed in at least 3 past PRs, then please do yourself raise a small separate new PR proposing to add an `@Disabled // TODO FINERACT-123` to the respective unstable test (e.g. [#774](https://github.com/apache/fineract/pull/774)) with the commit message mentioning said JIRA, as always. (Please do NOT just `@Disabled` any existing tests mixed in as part of your larger PR.)
1. If there is no existing JIRA for the test, then first please evaluate whether the failure couldn't be a (perhaps strange) impact of the change you are proposing after all. If it's not, then please raise a new JIRA to document the suspected Flaky Test, and link it to [FINERACT-850](https://issues.apache.org/jira/browse/FINERACT-850). This will allow the next person coming along hitting the same test failure to easily find it, and eventually propose to ignore the unstable test.
1. Then (only) Close and Reopen your PR, which will cause a new build, to see if it passes.
1. Of course, we very much appreciate you then jumping onto any such bugs and helping us figure out how to fix all ignored tests!
documents that we cannot accept huge "code dump" Pull Requests, with some related suggestions.
Guideline for new Feature commits involving Refactoring: If you are submitting PR for a new Feature,
and it involves refactoring, try to differentiate "new Feature code" with "Refactored" by placing
them in different commits. This helps review to review your code faster.
We have an automated Bot which marks pull requests as "stale" after a while, and ultimately automatically closes them.
Merge Strategy
--------------
This project's committers typically prefer to bring your Pull Requests in through _Rebase and Merge_ instead of _Create a Merge Commit_. (If you are unfamiliar with GitHub's UI re. this, note the somewhat hidden little triangle drop-down at the bottom of PR, visible only to committers, not contributors.) This avoids the "merge commits" which we consider to be somewhat "polluting" the projects commits log history view. We understand this doesn't give an easy automatic reference to the original PR (which GitHub automatically adds to the Merge Commit message it generates), but we consider this an only very minor inconvenience; it's typically relatively easy to find the original PR even just from the commit message, and JIRA.
We expect most proposed PRs to typically consist of a single commit. Committers may use _Squash and merge_ to combine your commits at merge time, and if they do so will rewrite your commit message as they see fit.
Neither of these two are hard absolute rules, but mere conventions. Multiple commits in single PR make sense in certain cases (e.g. branch backports).
Dependency Upgrades
-------------------
This project uses a number of 3rd-party libraries, and this section provides some guidance for their updates. We have set-up [Renovate's bot](https://renovate.whitesourcesoftware.com) to automatically raise Pull Requests for our review when new dependencies are available [FINERACT-962](https://issues.apache.org/jira/browse/FINERACT-962).
Upgrades sometimes require package name changes. Changed code should ideally have test coverage.
Our `ClasspathHellDuplicatesCheckRuleTest` detects classes that appear in more than 1 JAR. If a version bump in [`build.gradle`](https://github.com/search?q=repo%3Aapache%2Ffineract+filename%3Abuild.gradle&type=Code&ref=advsearch&l=&l=) causes changes in transitives dependencies, then you may have to add related `exclude` to our [`dependencies.gradle`](https://github.com/apache/fineract/search?q=dependencies.gradle). Running `./gradlew dependencies` helps to understand what is required.
More Information
============
More details of the project can be found at <https://cwiki.apache.org/confluence/display/FINERACT>.
"description":"API collection for UN Security Council consolidated sanctions list screening.\n\nEndpoints:\n- Screen client names against sanctions list\n- Load sanctions XML data\n- Check sanctions database status\n\nBase URL: {{baseUrl}}/fineract-provider/api/v1",
"description":"Name to screen against sanctions list"
}
]
},
"description":"Screen a client name against the UN Security Council consolidated sanctions list using GET method.\n\n**Response when match found (FLAGGED):**\n```json\n{\n \"screenedName\": \"Mohammad Ali\",\n \"matchFound\": true,\n \"status\": \"FLAGGED\",\n \"message\": \"Potential match found in UN Security Council consolidated sanctions list. Manual review required before proceeding.\",\n \"matchCount\": 2,\n \"matches\": [...]\n}\n```\n\n**Response when no match (CLEAR):**\n```json\n{\n \"screenedName\": \"John Smith\",\n \"matchFound\": false,\n \"status\": \"CLEAR\",\n \"message\": \"No match found in UN Security Council consolidated sanctions list.\",\n \"matchCount\": 0,\n \"matches\": []\n}\n```"
"description":"Get the count of active sanctions entries in the database.\n\n**Response:**\n```json\n{\n \"totalActiveEntries\": 1002,\n \"status\": \"ACTIVE\"\n}\n```"
"description":"Upload and load the UN consolidated sanctions XML file into the database.\n\nSelect the `consolidatedLegacyByPRN.xml` file in the Body > Binary section.\n\n**Response:**\n```json\n{\n \"message\": \"Sanctions data loaded successfully\",\n \"entriesLoaded\": 1002,\n \"totalActive\": 1002\n}\n```"
}
}
]
},
{
"name":"Screening Activity Logs",
"description":"View sanctions screening activity logs — every search is recorded",
"description":"Postman collection for Savings Product APIs.\n\nThis resource exposes 6 endpoints:\n1. POST /v1/savingsproducts\n2. PUT /v1/savingsproducts/{productId}\n3. GET /v1/savingsproducts\n4. GET /v1/savingsproducts/{productId}\n5. GET /v1/savingsproducts/template\n6. DELETE /v1/savingsproducts/{productId}\n\nThe create request below uses the mandatory fields required by the backend validator. If you switch accountingRule to cash-based or accrual-periodic, you must also supply the corresponding accounting mappings.",
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
Hello everyone,
We are proud to present Apache Fineract ${project['fineract.release.version']}, with the artifacts below up for a vote. Releases are important for a number of reasons: They put a stamp of approval on a set of code changes and they build momentum for future improvements.
Release notes and ChangeLog: https://cwiki.apache.org/confluence/display/FINERACT/${project['fineract.release.version']}+-+Apache+Fineract
Source and binary artifacts: https://dist.apache.org/repos/dist/dev/fineract/${project['fineract.release.version']}/
Tagged as ${project['fineract.release.version']}
Committer PGP keys, including the release signing key: https://dist.apache.org/repos/dist/dev/fineract/KEYS
Note that this release candidate contains source and binary artifacts.
This vote will be open for 72 hours:
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)
Please indicate if you are a binding vote (member of the PMC). Note: PMC members are required to download, compile, and test the artifacts before submitting their +1 vote.
Please also indicate with "Tested: YES/NO/PARTIAL" if you have locally built and/or tested these artifacts and/or a clone of the code checked out to the release commit, following the form:
Tested: YES ... Verified integrity and signatures of release artifacts locally, built from source, ran jar/war: Did everything mentioned in the current release candidate verification guidance ( https://fineract.apache.org/docs/rc/#_artifact_verification ). If you did more than that, please specify.
Tested: NO ... No testing performed on release candidate, e.g. relying on testing performed by other contributors and/or output of GitHub Actions, while exercising my right to vote.
Following are the typical things we need to verify before voting on a release candidate. And the release manager should verify them too before calling out a vote.
See https://fineract.apache.org/docs/current/#_step_9_verify_distribution_staging
Make sure release artifacts are hosted at https://dist.apache.org/repos/dist/dev/fineract
* Release candidates should be in format apache-fineract-bin-${project['fineract.release.version']}.tar.gz
* Verify signatures and hashes. You may have to import the public key of the release manager to verify the signatures. (gpg --import KEYS or gpg --recv-key <key id>)
* Git tag matches the released bits (diff -rf)
* Can compile docs and code successfully from source
* Verify DISCLAIMER, NOTICE and LICENSE (year etc)
* All files have correct headers (Rat check should be clean - gradlew rat)
[Incubating] Problems report is available at: file:///D:/CompanyProject/GitCBS/JAVA-Backend-CBS-MAIN/build/reports/problems/problems-report.html
Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.
You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.
For more on this, please refer to https://docs.gradle.org/8.14.3/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.
test:["CMD",'sh','-c','echo -e "Checking for the availability of Fineract server deployment"; while ! nc -z "localhost" 8443; do sleep 1; printf "-"; done; echo -e " >> Fineract server has started";']
test:["CMD",'sh','-c','echo -e "Checking for the availability of Fineract server deployment"; while ! nc -z "localhost" 8443; do sleep 1; printf "-"; done; echo -e " >> Fineract server has started";']
COMMENTONCOLUMNm_savings_product.average_periodIS'Average period for calculations';
COMMENTONCOLUMNm_savings_product.auto_postIS'Whether auto posting of interest is enabled';
COMMENTONCOLUMNm_savings_product.frequency_fix_dayIS'Fixed day for frequency calculations';
COMMENTONCOLUMNm_savings_product.last_interest_dateIS'Last date interest was calculated';
COMMENTONCOLUMNm_savings_product.enable_lockin_periodIS'Whether lock-in period is enabled';
COMMENTONCOLUMNm_savings_product.balance_frequencyIS'Frequency for balance calculation (e.g., Daily, Monthly, Quarterly)';
COMMENTONCOLUMNm_savings_product.account_closed_zero_balance_in_day_closingIS'Flag to indicate if account should be closed when balance reaches zero at day end';
@Tag(name="Accounting Closure",description="An accounting closure indicates that no more journal entries may be logged (or reversed) in the system, either manually or via the portfolio with an entry date prior to the defined closure date\n"
@Tag(name="Accounting Closure",description="""
+"\n"+"Field Descriptions\n"+"closingDate\n"+"The date for which the accounting closure is defined\n"+"officeId\n"
An accounting closure indicates that no more journal entries may be logged (or reversed) in the system, either manually or via the portfolio with an entry date prior to the defined closure date
+"The identifer of the branch for which accounting has been closed\n"+"comments\n"
+"Description associated with an Accounting closure")
Field Descriptions
closingDate
The date for which the accounting closure is defined
officeId
The identifer of the branch for which accounting has been closed
comments
Description associated with an Accounting closure
""")
@RequiredArgsConstructor
@RequiredArgsConstructor
publicclassGLClosuresApiResource{
publicclassGLClosuresApiResource{
@@ -76,9 +82,11 @@ public class GLClosuresApiResource {
@@ -127,8 +138,7 @@ public class GLClosuresApiResource {
@Produces({MediaType.APPLICATION_JSON})
@Produces({MediaType.APPLICATION_JSON})
@Operation(summary="Update an Accounting closure",description="Once an accounting closure is created, only the comments associated with it may be edited")
@Operation(summary="Update an Accounting closure",description="Once an accounting closure is created, only the comments associated with it may be edited")
@@ -28,4 +30,33 @@ public interface TrialBalanceRepository extends JpaRepository<TrialBalance, Long
@Query(value="select * from m_trial_balance where office_id=:officeId and account_id=:accountId and closing_balance is null order by created_date, entry_date",nativeQuery=true)
@Query(value="select * from m_trial_balance where office_id=:officeId and account_id=:accountId and closing_balance is null order by created_date, entry_date",nativeQuery=true)
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.