9 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
niteshandClaude Sonnet 5	3c58bb231f	fix(clients): pwdCategoryOptions on edit template, minor-age threshold to 18, minor KYC identity-proof bypass ... - 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>	2026-07-28 15:51:08 +05:30
niteshandClaude Sonnet 5	aabda18b69	feat(clients): enforce Mother + Father/Caretaker family members on client activation ... - 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>	2026-07-28 12:37:24 +05:30
nitesh	0e5671b706	Merge remote-tracking branch 'origin/uate' into uate	2026-07-28 10:55:05 +05:30
niteshandClaude Sonnet 5	67214ec0f8	fix(clients): stale signature bug, CKYC fixes, monthly turnover/annual income, senior citizen/PWD classification ... - 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>	2026-07-28 10:50:16 +05:30
nitesh	bc30241950	Merge remote-tracking branch 'origin/uate' into dev	2026-07-27 14:24:16 +05:30
niteshandClaude Sonnet 5	14df914b9a	feat(clients): dual-OTP verified contact changes with customer notification ... 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>	2026-07-26 14:36:48 +05:30
niteshandClaude Sonnet 5	5dc175c5e1	feat(users): auto-enroll admin-chosen OTP channel as MFA factor at creation ... 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>	2026-07-24 16:16:40 +05:30
nitesh	cf60515bf6	Merge remote-tracking branch 'nexora/uate' into merge-uate-into-dev ... # Conflicts: # .gitignore # fineract-provider/src/main/resources/db/changelog/tenant/changelog-tenant.xml # fineract-savings/src/main/java/org/apache/fineract/portfolio/savings/service/FacilityChargeAutoApplyService.java	2026-07-23 17:36:10 +05:30
niteshandClaude Sonnet 5	a098f8ba75	fix(chequebook): prevent cheque-leaf serial collisions across series at issuance time ... 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>	2026-07-23 17:24:17 +05:30