[jira] [Created] (FINERACT-2087) Further improvement of SQL validation
Aleksandar Vidakovic created FINERACT-2087: -- Summary: Further improvement of SQL validation Key: FINERACT-2087 URL: https://issues.apache.org/jira/browse/FINERACT-2087 Project: Apache Fineract Issue Type: Improvement Reporter: Aleksandar Vidakovic Fix For: 1.11.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (FINERACT-2076) SQL query optimization
[ https://issues.apache.org/jira/browse/FINERACT-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic resolved FINERACT-2076. Resolution: Fixed > SQL query optimization > -- > > Key: FINERACT-2076 > URL: https://issues.apache.org/jira/browse/FINERACT-2076 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Aleksandar Vidakovic >Assignee: Aleksandar Vidakovic >Priority: Major > Fix For: 1.10.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-2076) SQL query optimization
Aleksandar Vidakovic created FINERACT-2076: -- Summary: SQL query optimization Key: FINERACT-2076 URL: https://issues.apache.org/jira/browse/FINERACT-2076 Project: Apache Fineract Issue Type: Improvement Reporter: Aleksandar Vidakovic Assignee: Aleksandar Vidakovic Fix For: 1.10.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (FINERACT-1862) Run Reports fix
[ https://issues.apache.org/jira/browse/FINERACT-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic resolved FINERACT-1862. Resolution: Fixed > Run Reports fix > --- > > Key: FINERACT-1862 > URL: https://issues.apache.org/jira/browse/FINERACT-1862 > Project: Apache Fineract > Issue Type: Bug >Reporter: Aleksandar Vidakovic >Assignee: Aleksandar Vidakovic >Priority: Major > > See PS-1193 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-2070) Integrate the new test framework into the public build pipeline
Aleksandar Vidakovic created FINERACT-2070: -- Summary: Integrate the new test framework into the public build pipeline Key: FINERACT-2070 URL: https://issues.apache.org/jira/browse/FINERACT-2070 Project: Apache Fineract Issue Type: Improvement Reporter: Aleksandar Vidakovic Assignee: Aleksandar Vidakovic Fix For: 1.10.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-2069) QueryDSL migration: Field Configuration Service
[ https://issues.apache.org/jira/browse/FINERACT-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-2069: --- Summary: QueryDSL migration: Field Configuration Service (was: QueryDSL migration: Address Service) > QueryDSL migration: Field Configuration Service > --- > > Key: FINERACT-2069 > URL: https://issues.apache.org/jira/browse/FINERACT-2069 > Project: Apache Fineract > Issue Type: Sub-task >Reporter: Aleksandar Vidakovic >Assignee: Aleksandar Vidakovic >Priority: Major > Fix For: 1.10.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-2069) QueryDSL migration: Address Service
[ https://issues.apache.org/jira/browse/FINERACT-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-2069: --- Fix Version/s: 1.10.0 > QueryDSL migration: Address Service > --- > > Key: FINERACT-2069 > URL: https://issues.apache.org/jira/browse/FINERACT-2069 > Project: Apache Fineract > Issue Type: Sub-task >Reporter: Aleksandar Vidakovic >Assignee: Aleksandar Vidakovic >Priority: Major > Fix For: 1.10.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-2069) QueryDSL migration: Address Service
Aleksandar Vidakovic created FINERACT-2069: -- Summary: QueryDSL migration: Address Service Key: FINERACT-2069 URL: https://issues.apache.org/jira/browse/FINERACT-2069 Project: Apache Fineract Issue Type: Sub-task Reporter: Aleksandar Vidakovic Assignee: Aleksandar Vidakovic -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-2048) When standing instruction type selected is "dues", the following fields should be optional
[ https://issues.apache.org/jira/browse/FINERACT-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824858#comment-17824858 ] Aleksandar Vidakovic commented on FINERACT-2048: Pushkal is not listed in the list of assignable people. > When standing instruction type selected is "dues", the following fields > should be optional > --- > > Key: FINERACT-2048 > URL: https://issues.apache.org/jira/browse/FINERACT-2048 > Project: Apache Fineract > Issue Type: Bug >Affects Versions: 1.9.0 >Reporter: John Ruhiu >Priority: Major > Attachments: Screen Recording 2024-01-25 at 13.25.57.mov > > > When standing instruction type selected is "dues", the following fields > should be optional since they wil be picked from the loan repayment schedule: > * amount, > * interval, > * recurrence frequency, > * on month day > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-2047) Loan stays in overpaid status
Aleksandar Vidakovic created FINERACT-2047: -- Summary: Loan stays in overpaid status Key: FINERACT-2047 URL: https://issues.apache.org/jira/browse/FINERACT-2047 Project: Apache Fineract Issue Type: Bug Reporter: Aleksandar Vidakovic Assignee: Aleksandar Vidakovic Loan stays in overpaid status after disbursement reversal and new disbursement made. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-2041) summary - totalRepaymentTransaction doesnt include downpayment amount
[
https://issues.apache.org/jira/browse/FINERACT-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17810782#comment-17810782
]
Aleksandar Vidakovic commented on FINERACT-2041:
[~adamsaghy] is this issue then fixed with your PR? If yes, can we close this
ticket?
> summary - totalRepaymentTransaction doesnt include downpayment amount
> -
>
> Key: FINERACT-2041
> URL: https://issues.apache.org/jira/browse/FINERACT-2041
> Project: Apache Fineract
> Issue Type: Bug
>Reporter: Norbert Táskai
>Priority: Major
>
> *Steps to reproduce:*
> # Create Loan, approve
> # Disburse $1000 with downpayment enabled
> # Get Loan - {{summary.totalRepaymentTransaction}} field returns as 0
>
> {{{"id": 44,
> "accountNo": "00044",
> "externalId": "a1053484-3fdb-46a5-9cf9-4a087577de3d",
> "status": \{
> "id": 300,
> "code": "loanStatusType.active",
> "value": "Active",
> "pendingApproval": false,
> "waitingForDisbursal": false,
> "active": true,
> "closedObligationsMet": false,
> "closedWrittenOff": false,
> "closedRescheduled": false,
> "closed": false,
> "overpaid": false
> },
> "clientId": 34,
> "clientAccountNo": "00034",
> "clientName": "Johny Victor",
> "clientExternalId": "100a0a1a-292c-4076-b11a-882bbafd4eda",
> "clientOfficeId": 1,
> "loanProductId": 1,
> "loanProductName": "GPL_US_PI4",
> "loanProductDescription": "Global Pay Later - US - 4 Installment over 45
> Days",
> "isLoanProductLinkedToFloatingRate": false,
> "loanType": \{
> "id": 1,
> "code": "accountType.individual",
> "value": "Individual"
> },
> "currency": \{
> "code": "USD",
> "name": "US Dollar",
> "decimalPlaces": 2,
> "inMultiplesOf": 0,
> "displaySymbol": "$",
> "nameCode": "currency.USD",
> "displayLabel": "US Dollar ($)"
> },
> "principal": 900.00,
> "approvedPrincipal": 900.00,
> "proposedPrincipal": 900.00,
> "netDisbursalAmount": 300.00,
> "termFrequency": 45,
> "termPeriodFrequencyType": \{
> "id": 0,
> "code": "termFrequency.periodFrequencyType.days",
> "value": "Days"
> },
> "numberOfRepayments": 3,
> "repaymentEvery": 15,
> "repaymentFrequencyType": \{
> "id": 0,
> "code": "repaymentFrequency.periodFrequencyType.days",
> "value": "Days"
> },
> "interestRatePerPeriod": 0.00,
> "interestRateFrequencyType": \{
> "id": 5,
> "code": "periodFrequencyType.invalid",
> "value": "Invalid"
> },
> "annualInterestRate": 0.00,
> "isFloatingInterestRate": false,
> "amortizationType": \{
> "id": 1,
> "code": "amortizationType.equal.installments",
> "value": "Equal installments"
> },
> "interestType": \{
> "id": 0,
> "code": "interestType.declining.balance",
> "value": "Declining Balance"
> },
> "interestCalculationPeriodType": \{
> "id": 0,
> "code": "interestCalculationPeriodType.daily",
> "value": "Daily"
> },
> "allowPartialPeriodInterestCalculation": false,
> "transactionProcessingStrategyCode":
> "advanced-payment-allocation-strategy",
> "transactionProcessingStrategyName": "Advanced payment allocation
> strategy",
> "syncDisbursementWithMeeting": false,
> "disallowExpectedDisbursements": true,
> "timeline": \{
> "submittedOnDate": [
> 2024,
> 1,
> 7
> ],
> "submittedByUsername": "crpadapteruser",
> "submittedByFirstname": "crpadapteruser",
> "submittedByLastname": "crpadapteruser",
> "approvedOnDate": [
> 2024,
> 1,
> 7
> ],
> "approvedByUsername": "crpadapteruser",
> "approvedByFirstname": "crpadapteruser",
> "approvedByLastname": "crpadapteruser",
> "expectedDisbursementDate": [
> 2024,
> 1,
> 7
> ],
> "actualDisbursementDate": [
> 2024,
> 1,
> 7
> ],
> "disbursedByUsername": "crpadapteruser",
> "disbursedByFirstname": "crpadapteruser",
> "disbursedByLastname": "crpadapteruser",
> "actualMaturityDate": [
> 2024,
> 2,
> 21
> ],
> "expectedMaturityDate": [
> 2024,
> 2,
> 21
> ]
> },
> "summary": \{
> "currency": {
> "code": "USD",
> "name": "US Dollar",
> "decimalPlaces":
[jira] [Assigned] (FINERACT-2041) summary - totalRepaymentTransaction doesnt include downpayment amount
[
https://issues.apache.org/jira/browse/FINERACT-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandar Vidakovic reassigned FINERACT-2041:
--
Assignee: (was: Aleksandar Vidakovic)
> summary - totalRepaymentTransaction doesnt include downpayment amount
> -
>
> Key: FINERACT-2041
> URL: https://issues.apache.org/jira/browse/FINERACT-2041
> Project: Apache Fineract
> Issue Type: Bug
>Reporter: Norbert Táskai
>Priority: Major
>
> *Steps to reproduce:*
> # Create Loan, approve
> # Disburse $1000 with downpayment enabled
> # Get Loan - {{summary.totalRepaymentTransaction}} field returns as 0
>
> {{{"id": 44,
> "accountNo": "00044",
> "externalId": "a1053484-3fdb-46a5-9cf9-4a087577de3d",
> "status": \{
> "id": 300,
> "code": "loanStatusType.active",
> "value": "Active",
> "pendingApproval": false,
> "waitingForDisbursal": false,
> "active": true,
> "closedObligationsMet": false,
> "closedWrittenOff": false,
> "closedRescheduled": false,
> "closed": false,
> "overpaid": false
> },
> "clientId": 34,
> "clientAccountNo": "00034",
> "clientName": "Johny Victor",
> "clientExternalId": "100a0a1a-292c-4076-b11a-882bbafd4eda",
> "clientOfficeId": 1,
> "loanProductId": 1,
> "loanProductName": "GPL_US_PI4",
> "loanProductDescription": "Global Pay Later - US - 4 Installment over 45
> Days",
> "isLoanProductLinkedToFloatingRate": false,
> "loanType": \{
> "id": 1,
> "code": "accountType.individual",
> "value": "Individual"
> },
> "currency": \{
> "code": "USD",
> "name": "US Dollar",
> "decimalPlaces": 2,
> "inMultiplesOf": 0,
> "displaySymbol": "$",
> "nameCode": "currency.USD",
> "displayLabel": "US Dollar ($)"
> },
> "principal": 900.00,
> "approvedPrincipal": 900.00,
> "proposedPrincipal": 900.00,
> "netDisbursalAmount": 300.00,
> "termFrequency": 45,
> "termPeriodFrequencyType": \{
> "id": 0,
> "code": "termFrequency.periodFrequencyType.days",
> "value": "Days"
> },
> "numberOfRepayments": 3,
> "repaymentEvery": 15,
> "repaymentFrequencyType": \{
> "id": 0,
> "code": "repaymentFrequency.periodFrequencyType.days",
> "value": "Days"
> },
> "interestRatePerPeriod": 0.00,
> "interestRateFrequencyType": \{
> "id": 5,
> "code": "periodFrequencyType.invalid",
> "value": "Invalid"
> },
> "annualInterestRate": 0.00,
> "isFloatingInterestRate": false,
> "amortizationType": \{
> "id": 1,
> "code": "amortizationType.equal.installments",
> "value": "Equal installments"
> },
> "interestType": \{
> "id": 0,
> "code": "interestType.declining.balance",
> "value": "Declining Balance"
> },
> "interestCalculationPeriodType": \{
> "id": 0,
> "code": "interestCalculationPeriodType.daily",
> "value": "Daily"
> },
> "allowPartialPeriodInterestCalculation": false,
> "transactionProcessingStrategyCode":
> "advanced-payment-allocation-strategy",
> "transactionProcessingStrategyName": "Advanced payment allocation
> strategy",
> "syncDisbursementWithMeeting": false,
> "disallowExpectedDisbursements": true,
> "timeline": \{
> "submittedOnDate": [
> 2024,
> 1,
> 7
> ],
> "submittedByUsername": "crpadapteruser",
> "submittedByFirstname": "crpadapteruser",
> "submittedByLastname": "crpadapteruser",
> "approvedOnDate": [
> 2024,
> 1,
> 7
> ],
> "approvedByUsername": "crpadapteruser",
> "approvedByFirstname": "crpadapteruser",
> "approvedByLastname": "crpadapteruser",
> "expectedDisbursementDate": [
> 2024,
> 1,
> 7
> ],
> "actualDisbursementDate": [
> 2024,
> 1,
> 7
> ],
> "disbursedByUsername": "crpadapteruser",
> "disbursedByFirstname": "crpadapteruser",
> "disbursedByLastname": "crpadapteruser",
> "actualMaturityDate": [
> 2024,
> 2,
> 21
> ],
> "expectedMaturityDate": [
> 2024,
> 2,
> 21
> ]
> },
> "summary": \{
> "currency": {
> "code": "USD",
> "name": "US Dollar",
> "decimalPlaces": 2,
> "inMultiplesOf": 0,
> "displaySymbol": "$",
>
[jira] [Assigned] (FINERACT-2041) summary - totalRepaymentTransaction doesnt include downpayment amount
[
https://issues.apache.org/jira/browse/FINERACT-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandar Vidakovic reassigned FINERACT-2041:
--
Assignee: Aleksandar Vidakovic
> summary - totalRepaymentTransaction doesnt include downpayment amount
> -
>
> Key: FINERACT-2041
> URL: https://issues.apache.org/jira/browse/FINERACT-2041
> Project: Apache Fineract
> Issue Type: Bug
>Reporter: Norbert Táskai
>Assignee: Aleksandar Vidakovic
>Priority: Major
>
> *Steps to reproduce:*
> # Create Loan, approve
> # Disburse $1000 with downpayment enabled
> # Get Loan - {{summary.totalRepaymentTransaction}} field returns as 0
>
> {{{"id": 44,
> "accountNo": "00044",
> "externalId": "a1053484-3fdb-46a5-9cf9-4a087577de3d",
> "status": \{
> "id": 300,
> "code": "loanStatusType.active",
> "value": "Active",
> "pendingApproval": false,
> "waitingForDisbursal": false,
> "active": true,
> "closedObligationsMet": false,
> "closedWrittenOff": false,
> "closedRescheduled": false,
> "closed": false,
> "overpaid": false
> },
> "clientId": 34,
> "clientAccountNo": "00034",
> "clientName": "Johny Victor",
> "clientExternalId": "100a0a1a-292c-4076-b11a-882bbafd4eda",
> "clientOfficeId": 1,
> "loanProductId": 1,
> "loanProductName": "GPL_US_PI4",
> "loanProductDescription": "Global Pay Later - US - 4 Installment over 45
> Days",
> "isLoanProductLinkedToFloatingRate": false,
> "loanType": \{
> "id": 1,
> "code": "accountType.individual",
> "value": "Individual"
> },
> "currency": \{
> "code": "USD",
> "name": "US Dollar",
> "decimalPlaces": 2,
> "inMultiplesOf": 0,
> "displaySymbol": "$",
> "nameCode": "currency.USD",
> "displayLabel": "US Dollar ($)"
> },
> "principal": 900.00,
> "approvedPrincipal": 900.00,
> "proposedPrincipal": 900.00,
> "netDisbursalAmount": 300.00,
> "termFrequency": 45,
> "termPeriodFrequencyType": \{
> "id": 0,
> "code": "termFrequency.periodFrequencyType.days",
> "value": "Days"
> },
> "numberOfRepayments": 3,
> "repaymentEvery": 15,
> "repaymentFrequencyType": \{
> "id": 0,
> "code": "repaymentFrequency.periodFrequencyType.days",
> "value": "Days"
> },
> "interestRatePerPeriod": 0.00,
> "interestRateFrequencyType": \{
> "id": 5,
> "code": "periodFrequencyType.invalid",
> "value": "Invalid"
> },
> "annualInterestRate": 0.00,
> "isFloatingInterestRate": false,
> "amortizationType": \{
> "id": 1,
> "code": "amortizationType.equal.installments",
> "value": "Equal installments"
> },
> "interestType": \{
> "id": 0,
> "code": "interestType.declining.balance",
> "value": "Declining Balance"
> },
> "interestCalculationPeriodType": \{
> "id": 0,
> "code": "interestCalculationPeriodType.daily",
> "value": "Daily"
> },
> "allowPartialPeriodInterestCalculation": false,
> "transactionProcessingStrategyCode":
> "advanced-payment-allocation-strategy",
> "transactionProcessingStrategyName": "Advanced payment allocation
> strategy",
> "syncDisbursementWithMeeting": false,
> "disallowExpectedDisbursements": true,
> "timeline": \{
> "submittedOnDate": [
> 2024,
> 1,
> 7
> ],
> "submittedByUsername": "crpadapteruser",
> "submittedByFirstname": "crpadapteruser",
> "submittedByLastname": "crpadapteruser",
> "approvedOnDate": [
> 2024,
> 1,
> 7
> ],
> "approvedByUsername": "crpadapteruser",
> "approvedByFirstname": "crpadapteruser",
> "approvedByLastname": "crpadapteruser",
> "expectedDisbursementDate": [
> 2024,
> 1,
> 7
> ],
> "actualDisbursementDate": [
> 2024,
> 1,
> 7
> ],
> "disbursedByUsername": "crpadapteruser",
> "disbursedByFirstname": "crpadapteruser",
> "disbursedByLastname": "crpadapteruser",
> "actualMaturityDate": [
> 2024,
> 2,
> 21
> ],
> "expectedMaturityDate": [
> 2024,
> 2,
> 21
> ]
> },
> "summary": \{
> "currency": {
> "code": "USD",
> "name": "US Dollar",
> "decimalPlaces": 2,
> "inMultiplesOf": 0,
>
[jira] [Updated] (FINERACT-2044) Fix launch configuration for Spring 3.2.x
[ https://issues.apache.org/jira/browse/FINERACT-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-2044: --- Fix Version/s: 1.10.0 > Fix launch configuration for Spring 3.2.x > - > > Key: FINERACT-2044 > URL: https://issues.apache.org/jira/browse/FINERACT-2044 > Project: Apache Fineract > Issue Type: Bug >Reporter: Aleksandar Vidakovic >Priority: Major > Fix For: 1.10.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-2044) Fix launch configuration for Spring 3.2.x
Aleksandar Vidakovic created FINERACT-2044: -- Summary: Fix launch configuration for Spring 3.2.x Key: FINERACT-2044 URL: https://issues.apache.org/jira/browse/FINERACT-2044 Project: Apache Fineract Issue Type: Bug Reporter: Aleksandar Vidakovic -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-2038) Upgrade to Spring Boot 3.2.x
Aleksandar Vidakovic created FINERACT-2038: -- Summary: Upgrade to Spring Boot 3.2.x Key: FINERACT-2038 URL: https://issues.apache.org/jira/browse/FINERACT-2038 Project: Apache Fineract Issue Type: Improvement Reporter: Aleksandar Vidakovic Fix For: 1.10.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-2037) Make test AdvancedPaymentAllocationLoanRepaymentScheduleTest.uc118() time independent
Aleksandar Vidakovic created FINERACT-2037: -- Summary: Make test AdvancedPaymentAllocationLoanRepaymentScheduleTest.uc118() time independent Key: FINERACT-2037 URL: https://issues.apache.org/jira/browse/FINERACT-2037 Project: Apache Fineract Issue Type: Bug Reporter: Aleksandar Vidakovic Fix For: 1.10.0 Currently the test fails when run on certain times of the day (early afternoon CET?). Can we fix this to avoid falsely failing tests? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (FINERACT-2036) Fix code quality
[ https://issues.apache.org/jira/browse/FINERACT-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic resolved FINERACT-2036. Resolution: Fixed > Fix code quality > > > Key: FINERACT-2036 > URL: https://issues.apache.org/jira/browse/FINERACT-2036 > Project: Apache Fineract > Issue Type: Bug >Reporter: Aleksandar Vidakovic >Assignee: Aleksandar Vidakovic >Priority: Major > Fix For: 1.9.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FINERACT-2036) Fix code quality
Aleksandar Vidakovic created FINERACT-2036: -- Summary: Fix code quality Key: FINERACT-2036 URL: https://issues.apache.org/jira/browse/FINERACT-2036 Project: Apache Fineract Issue Type: Bug Reporter: Aleksandar Vidakovic Fix For: 1.9.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (FINERACT-2036) Fix code quality
[ https://issues.apache.org/jira/browse/FINERACT-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic reassigned FINERACT-2036: -- Assignee: Aleksandar Vidakovic > Fix code quality > > > Key: FINERACT-2036 > URL: https://issues.apache.org/jira/browse/FINERACT-2036 > Project: Apache Fineract > Issue Type: Bug >Reporter: Aleksandar Vidakovic >Assignee: Aleksandar Vidakovic >Priority: Major > Fix For: 1.9.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1874) Release Apache Fineract 1.9.0
[ https://issues.apache.org/jira/browse/FINERACT-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1874: --- Fix Version/s: (was: 1.9.0) > Release Apache Fineract 1.9.0 > - > > Key: FINERACT-1874 > URL: https://issues.apache.org/jira/browse/FINERACT-1874 > Project: Apache Fineract > Issue Type: Task >Reporter: Aleksandar Vidakovic >Assignee: Aleksandar Vidakovic >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1874) Release Apache Fineract 1.9.0
[ https://issues.apache.org/jira/browse/FINERACT-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1874: --- Fix Version/s: 1.9.0 > Release Apache Fineract 1.9.0 > - > > Key: FINERACT-1874 > URL: https://issues.apache.org/jira/browse/FINERACT-1874 > Project: Apache Fineract > Issue Type: Task >Reporter: Aleksandar Vidakovic >Assignee: Aleksandar Vidakovic >Priority: Major > Fix For: 1.9.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1221) Fineract Client Java SDK API has broken methods
[
https://issues.apache.org/jira/browse/FINERACT-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandar Vidakovic updated FINERACT-1221:
---
Fix Version/s: 1.10.0
(was: 1.9.0)
> Fineract Client Java SDK API has broken methods
> ---
>
> Key: FINERACT-1221
> URL: https://issues.apache.org/jira/browse/FINERACT-1221
> Project: Apache Fineract
> Issue Type: Bug
> Components: SDK
>Affects Versions: 1.8.0
>Reporter: Michael Vorburger
>Priority: Blocker
> Fix For: 1.10.0
>
>
> Our brand new "Fineract Client Java SDK API" emerging from
> https://github.com/apache/fineract/pull/1428/ for FINERACT-1216 contains at
> least some annotated Java methods which are invalid for Retrofit.
> When enabling {{apiClient.getAdapterBuilder().validateEagerly(true);}}, I'm
> seeing e.g.
> {noformat}java.lang.IllegalArgumentException: Non-body HTTP method cannot
> contain @Body.
> for method ClientApi.delete9
> at retrofit2.Utils.methodError(Utils.java:54)
> at retrofit2.Utils.methodError(Utils.java:43)
> at retrofit2.RequestFactory$Builder.build(RequestFactory.java:213)
> at retrofit2.RequestFactory.parseAnnotations(RequestFactory.java:67)
> at retrofit2.ServiceMethod.parseAnnotations(ServiceMethod.java:26)
> at retrofit2.Retrofit.loadServiceMethod(Retrofit.java:202)
> at retrofit2.Retrofit.validateServiceInterface(Retrofit.java:189)
> at retrofit2.Retrofit.create(Retrofit.java:141)
> at
> org.apache.fineract.client.ApiClient.createService(ApiClient.java:127)
> at
> org.apache.fineract.client.util.FineractClient.createService(FineractClient.java:42)
> at
> org.apache.fineract.client.test.FineractClientTest.testRetrieveAllClients(FineractClientTest.java:41){noformat}
> As a first step to eventually fixing this (and having non-regression for it),
> I'll write an automated test about it (but keep it ignored, for now).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (FINERACT-1702) Status of submitted applications for approval or processing
[ https://issues.apache.org/jira/browse/FINERACT-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1702: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Status of submitted applications for approval or processing > --- > > Key: FINERACT-1702 > URL: https://issues.apache.org/jira/browse/FINERACT-1702 > Project: Apache Fineract > Issue Type: Improvement > Components: Organization >Affects Versions: 1.7.0 >Reporter: ibrahim kimbugwe >Priority: Major > Fix For: 1.10.0 > > > Upon submitting a loan application GL entry or any other task that requires > approval in a maker checker-controlled working environment, It is very > important to have a window to monitor the status of the submission even if I > don't have the rights to approve. > This goes a long way to help in the follow-up and management of tasks. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1184) Simple Interest Functionality
[ https://issues.apache.org/jira/browse/FINERACT-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1184: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Simple Interest Functionality > - > > Key: FINERACT-1184 > URL: https://issues.apache.org/jira/browse/FINERACT-1184 > Project: Apache Fineract > Issue Type: Improvement > Components: Savings >Affects Versions: 1.8.0 >Reporter: Airsay >Priority: Major > Fix For: 1.10.0 > > > Simple Interest. While not widely used across FI, there are some clients that > don't compound interest. I've seen in the code-base that there were plans for > simple interest. I would like to see this in v1.5. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1559) New response parameters required for Loan creation response/retrieve loan information API
[
https://issues.apache.org/jira/browse/FINERACT-1559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandar Vidakovic updated FINERACT-1559:
---
Fix Version/s: 1.10.0
(was: 1.9.0)
> New response parameters required for Loan creation response/retrieve loan
> information API
> --
>
> Key: FINERACT-1559
> URL: https://issues.apache.org/jira/browse/FINERACT-1559
> Project: Apache Fineract
> Issue Type: Improvement
>Affects Versions: 1.6.0
>Reporter: Ed Cable
>Priority: Major
> Fix For: 1.10.0
>
>
> For the following API,
> GET:
> _[https://DomainName/fineract-provider/api/v1/loans/\|https://domainname/fineract-provider/api/v1/loans/]{loanId}?associations=all=guarantors,futureSchedule_
> The loan creation response and retrieve loan information requires the
> following additional parameters to be returned:
>
> |New Parameter|Value/Amount|
> |available_disbursement_amount|It is the difference of approved amount and
> disbursed amount|
> |past_due_days|No of days the loan is overdue,current date - duedate|
> |next_payment_due_date|Based on the current date, need to populate the next
> payment due date|
> |delinquent_days|No of days the loan is in arrears, current date -
> duedate-grace period|
> |delinquent_date|Date the loan is in arrears, current date - duedate-grace
> period|
> |delinquent_amount|amount overdue after the grace period|
> |last_payment_date|last repayment made date on the loan|
> |last_payment_amount|last repayment amount made date on the loan|
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (FINERACT-1449) Repayment schedule issue when advance payments are made
[ https://issues.apache.org/jira/browse/FINERACT-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1449: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Repayment schedule issue when advance payments are made > --- > > Key: FINERACT-1449 > URL: https://issues.apache.org/jira/browse/FINERACT-1449 > Project: Apache Fineract > Issue Type: Bug > Components: Loan >Affects Versions: 1.5.0 >Reporter: Bharath Gowda >Assignee: Avik Ganguly >Priority: Critical > Fix For: 1.10.0 > > Attachments: after change.png, before change.png, > loanproductconfiguration.png > > > Repayment schedule issue when advance payments are made > > To reproduce > # create a loan product as attached loan product configuration > # create a loan and disburse on '29 November 2021' for amount 3000 with > First Repayment Date as '03 January 2022' > # Now make a payment of 1 on '02 December 2021' and another payment of 1 on > '03 December 2021' > # Now check the schedule, Installment dates and Interest amount would have > changed. > Check the screenshot of the before and after change attached for reference > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1698) Prompt user to confirm Password before changing password
[ https://issues.apache.org/jira/browse/FINERACT-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1698: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Prompt user to confirm Password before changing password > > > Key: FINERACT-1698 > URL: https://issues.apache.org/jira/browse/FINERACT-1698 > Project: Apache Fineract > Issue Type: Improvement > Components: Security >Affects Versions: 1.7.0 >Reporter: ibrahim kimbugwe >Assignee: Rahul Pawar >Priority: Major > Fix For: 1.10.0 > > Attachments: image-2022-08-21-12-48-27-080.png > > > Upon updating the password inside the user profile, a user needs to be > prompted his/her current password. > Let's take a scenario of a user finishing work in the evening and forgets to > logout of the system, the current session is 5 minutes whereby if someone > gets onto the user's computer while logged in, he/she can change the password > since the system allows to change a password without need to confirm the old > password. > !image-2022-08-21-12-48-27-080.png|width=554,height=280! > This is a big security issue since the user's changed credentials can be used > even off the current PC to maliciously cause harm. > [~edcable] [~aleks], [~francisguchie] [~rrpawar] & [~eroemma] what is your > opinion on this and can it receive attention please? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1183) Ability to archive Fixed Deposit and recurring Deposit Products
[ https://issues.apache.org/jira/browse/FINERACT-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1183: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Ability to archive Fixed Deposit and recurring Deposit Products > --- > > Key: FINERACT-1183 > URL: https://issues.apache.org/jira/browse/FINERACT-1183 > Project: Apache Fineract > Issue Type: New Feature >Affects Versions: 1.8.0 >Reporter: Airsay >Priority: Major > Fix For: 1.10.0 > > > We should be able to archive Fixed Deposit and recurring deposit products > products like we have for loan products. When a product is no longer offered > by the FI, we should be able to mark that product as archived so that no new > accounts can be created for that product. > > A possible alternative is to include FD and RD in the Office–.Products Entity > to Entity Mapping. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1130) Add ErrorProne's TypeParameterUnusedInFormals
[ https://issues.apache.org/jira/browse/FINERACT-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1130: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Add ErrorProne's TypeParameterUnusedInFormals > - > > Key: FINERACT-1130 > URL: https://issues.apache.org/jira/browse/FINERACT-1130 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Michael Vorburger >Assignee: Percy Ashu >Priority: Minor > Fix For: 1.10.0 > > > Following up on FINERACT-822 for [~Percy Ashu] to add > TypeParameterUnusedInFormals some time, if interested (so that we can close > FINERACT-822 for 1.4.0). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1948) Loan repayment by account transfer transaction type should not be withdrawal
[ https://issues.apache.org/jira/browse/FINERACT-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1948: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Loan repayment by account transfer transaction type should not be withdrawal > > > Key: FINERACT-1948 > URL: https://issues.apache.org/jira/browse/FINERACT-1948 > Project: Apache Fineract > Issue Type: Improvement >Affects Versions: 1.7.2, 1.7.0, 1.8.3, 1.8.2, 1.8.1 >Reporter: ibrahim kimbugwe >Assignee: Francis Guchie >Priority: Major > Fix For: 1.10.0 > > Attachments: image-2023-07-31-23-11-05-824.png > > > When a user transfers money from a savings account to pay off a loan, the > transaction type is tagged as a withdrawal yet this is a loan repayment. The > transaction type should be adjusted to suit the transaction as it gets handy > for repayments with standing instructions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1949) Access customer information accross a multiple branch institution
[ https://issues.apache.org/jira/browse/FINERACT-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1949: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Access customer information accross a multiple branch institution > - > > Key: FINERACT-1949 > URL: https://issues.apache.org/jira/browse/FINERACT-1949 > Project: Apache Fineract > Issue Type: Improvement >Affects Versions: 1.7.0, 1.8.3 >Reporter: ibrahim kimbugwe >Assignee: Francis Guchie >Priority: Major > Fix For: 1.10.0 > > > Currently, the fineract allows a scope of branch teams to access branch > information unless they're added at head office. This feature should however > be extended to make sure that customers of a particular branch can be served > at another branch. Cases include doing deposits and withdrawals. > [~francisguchie] and [~bgowda] whats your take on this? > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1878) Profile Image sharing between Client and Staff
[ https://issues.apache.org/jira/browse/FINERACT-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1878: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Profile Image sharing between Client and Staff > -- > > Key: FINERACT-1878 > URL: https://issues.apache.org/jira/browse/FINERACT-1878 > Project: Apache Fineract > Issue Type: Bug > Components: Client >Affects Versions: 1.8.3 > Environment: Mac OS Ventura >Reporter: Drew Foster >Priority: Minor > Labels: AWS, easyfix > Fix For: 1.10.0 > > Original Estimate: 0h > Remaining Estimate: 0h > > Clients and Staff that share the same id read and write to the same image > path. The method generateClientImageParentDirectory in S3ContentRepository > only writes to "clients" image path even when writing from a staff entity. > > *Open pull request* [*here*|https://github.com/apache/fineract/pull/2945] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1703) Deactivating a system user
[ https://issues.apache.org/jira/browse/FINERACT-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1703: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Deactivating a system user > -- > > Key: FINERACT-1703 > URL: https://issues.apache.org/jira/browse/FINERACT-1703 > Project: Apache Fineract > Issue Type: Improvement > Components: Security >Affects Versions: 1.7.0 >Reporter: ibrahim kimbugwe >Assignee: Rahul Pawar >Priority: Major > Fix For: 1.10.0 > > Attachments: image-2022-08-21-18-18-58-042.png > > > As a security measure, organisations from time to time change employees. This > means users are created and sometimes deleted or deactivated. Such cases may > include an employee under investigation or under temporary suspension. After > issues are sorted, the user has to be activated again. > We need to enhance the system to have a check button for active > !image-2022-08-21-18-18-58-042.png|width=542,height=344! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1131) Add Checkstyle IllegalCatch
[ https://issues.apache.org/jira/browse/FINERACT-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1131: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Add Checkstyle IllegalCatch > --- > > Key: FINERACT-1131 > URL: https://issues.apache.org/jira/browse/FINERACT-1131 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Michael Vorburger >Assignee: Manthan Surkar >Priority: Minor > Fix For: 1.10.0 > > > Following up on FINERACT-942 for [~Manthan] to add > TypeParameterUnusedInFormals some time, if interested (so that we can close > FINERACT-942 for 1.4.0 now). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1951) Add filter on cashier teller management for transactions
[ https://issues.apache.org/jira/browse/FINERACT-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1951: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Add filter on cashier teller management for transactions > > > Key: FINERACT-1951 > URL: https://issues.apache.org/jira/browse/FINERACT-1951 > Project: Apache Fineract > Issue Type: Improvement > Environment: Mifos community App 21.07.3 >Reporter: ibrahim kimbugwe >Assignee: Francis Guchie >Priority: Major > Fix For: 1.10.0 > > Attachments: image-2023-07-09-18-24-49-473.png, > image-2023-07-09-18-26-53-403.png > > > In the cashier teller management module, the cashier may need to filter and > reconcile balances on a daily basis side the cashier teller module. For this > to be achieved, there need to be filters that allow the user to d so as per > the screenshot below > !image-2023-07-09-18-26-53-403.png|width=587,height=405! > > Filter for; > * Transaction type either cash in or cashout > * Transaction date > * Transaction ID > We also need to change the layout to have the last transaction on the first > page. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1621) All transaction date should be set to current date place holders
[ https://issues.apache.org/jira/browse/FINERACT-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1621: --- Fix Version/s: 1.10.0 (was: 1.9.0) > All transaction date should be set to current date place holders > > > Key: FINERACT-1621 > URL: https://issues.apache.org/jira/browse/FINERACT-1621 > Project: Apache Fineract > Issue Type: Improvement >Affects Versions: 1.8.0 >Reporter: ibrahim kimbugwe >Assignee: Rahul Pawar >Priority: Major > Fix For: 1.10.0 > > Attachments: loan repayment issue.JPG > > > At loan repayment, the system selects the proposed repayment date as per the > repayment schedule. I believe this should not be the case as the transaction > date always changes as many loans are not repaid at the proposed scheduled > date as they may pay before or after. To reduce errors when selecting the > transaction date, the system should pick the current date by default and > allow adjustments if it is a backdated transaction. > !loan repayment issue.JPG|width=652,height=304! > [~francisguchie] [~eroemma] & [~mkaitesi] what's your take on this? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1310) Accrual transactions not happening for foreclosed loans
[ https://issues.apache.org/jira/browse/FINERACT-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1310: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Accrual transactions not happening for foreclosed loans > --- > > Key: FINERACT-1310 > URL: https://issues.apache.org/jira/browse/FINERACT-1310 > Project: Apache Fineract > Issue Type: Bug > Components: Accounting, Loan >Affects Versions: 1.4.0 >Reporter: Bharath Gowda >Assignee: Nayan Ambali >Priority: Critical > Fix For: 1.10.0 > > > Accrual transactions not happening for foreclosed loans > > To reproduce > 1. Create a loan product(any configuration) with accrual periodic accounting > enabled. > 2. Create/approve/disburse a loan account > 3. foreclose the same loan at any date apart from due date. > 4. loan is getting closed with the interest accrual entry for the foreclosed > transaction > > Expected result, system should post the accrual transaction for the > foreclosed transaction -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1315) transfer of client from one office to another are not posting accounting entries
[ https://issues.apache.org/jira/browse/FINERACT-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1315: --- Fix Version/s: 1.10.0 (was: 1.9.0) > transfer of client from one office to another are not posting accounting > entries > > > Key: FINERACT-1315 > URL: https://issues.apache.org/jira/browse/FINERACT-1315 > Project: Apache Fineract > Issue Type: Bug > Components: Accounting, Client >Affects Versions: 1.4.0 >Reporter: Bharath Gowda >Assignee: Nayan Ambali >Priority: Blocker > Fix For: 1.10.0 > > Attachments: 1.png, 2.png > > > The transactions at the loan level which happens when we transfer a client > from one office to another are not posting accounting JE entries. > > to reproduce > 1. create/disburse an individual loan with any loan product that has > accounting enabled > 2. transfer the client from one office to another office using the "transfer > client" button from the client view screen > 3. active loans will get "transfer initiated" and "transfer approved" > transactions which will actually transfer the loan's portfolio to a new > transferred branch, which is not happening currently. > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1397) Interest calculation issue when repayment is made on the disbursement day
[ https://issues.apache.org/jira/browse/FINERACT-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1397: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Interest calculation issue when repayment is made on the disbursement day > - > > Key: FINERACT-1397 > URL: https://issues.apache.org/jira/browse/FINERACT-1397 > Project: Apache Fineract > Issue Type: Bug > Components: Loan >Affects Versions: 1.5.0 >Reporter: Bharath Gowda >Assignee: Avik Ganguly >Priority: Major > Fix For: 1.10.0 > > Attachments: interest calculation issue.xlsx, product > configuration.png > > > Interest calculation is wrong when repayment is made on the disbursement day > for the daily interest loan product > > To reproduce the issue > 1. Create a loan product with daily interest calculation and interest > recalculation enabled.(have attached the screenshot of the loan product > configuration) > 2. Create/approve/disburse a loan account with a first repayment date of 30 > days gap from the disbursement date. > 3. Make the repayment on the same day of the disbursement date and verify the > interest > > check excel calculation for example issue and expected result. > > Any other date apart from the disbursement date repayment the interest > calculation is happening currently. > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1519) Fineract.dev CD is no longer auto-updating
[ https://issues.apache.org/jira/browse/FINERACT-1519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1519: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Fineract.dev CD is no longer auto-updating > -- > > Key: FINERACT-1519 > URL: https://issues.apache.org/jira/browse/FINERACT-1519 > Project: Apache Fineract > Issue Type: Bug >Reporter: Michael Vorburger >Assignee: Michael Vorburger >Priority: Major > Fix For: 1.10.0 > > > https://github.com/vorburger/www.fineract.dev/issues/15 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1865) Optimistic locking issues while saving LoanTransactionRelation entity
[ https://issues.apache.org/jira/browse/FINERACT-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1865: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Optimistic locking issues while saving LoanTransactionRelation entity > - > > Key: FINERACT-1865 > URL: https://issues.apache.org/jira/browse/FINERACT-1865 > Project: Apache Fineract > Issue Type: Bug >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > Labels: PepperSoup > Fix For: 1.10.0 > > > GIVEN there are some repayment which ultimately overpays the loan and > LoanStatusChanged external event is turned on. > WHEN you try to revert the 2nd repayment, > THEN it throws optimistic lock error. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1001) Enable and Enforce PMD on Fineract
[ https://issues.apache.org/jira/browse/FINERACT-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1001: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Enable and Enforce PMD on Fineract > -- > > Key: FINERACT-1001 > URL: https://issues.apache.org/jira/browse/FINERACT-1001 > Project: Apache Fineract > Issue Type: Sub-task >Affects Versions: 1.8.0 >Reporter: Awasum Yannick >Priority: Minor > Fix For: 1.10.0 > > Attachments: main.html > > > Enable and Enforce PMD ( [https://pmd.github.io/ )|https://pmd.github.io/] on > Fineract. Make PMD fail until violations are fixed just like we do for > Spotbug, checkstyle etc. See previous work here: > [https://github.com/apache/fineract/pull/295] > See where PMD was commented out because it was not use: > [https://github.com/apache/fineract/pull/612] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1701) Printing posted GL transaction
[ https://issues.apache.org/jira/browse/FINERACT-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1701: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Printing posted GL transaction > -- > > Key: FINERACT-1701 > URL: https://issues.apache.org/jira/browse/FINERACT-1701 > Project: Apache Fineract > Issue Type: Improvement > Components: Accounting >Affects Versions: 1.7.0 >Reporter: ibrahim kimbugwe >Assignee: Rahul Pawar >Priority: Major > Fix For: 1.10.0 > > Attachments: image-2022-08-21-15-48-58-982.png, > image-2022-08-21-15-51-34-946.png, image-2022-08-21-15-55-06-535.png > > > In the normal Banking environment, accounting is controlled by maker and > checker where the finance assistant posts transactions then the Finance > manager approves them. Such a transaction is stamped and filled for reference > before being approved in the system. > Workflow > !image-2022-08-21-15-48-58-982.png|width=547,height=100! > We need to add a printing functionality between the approval and the creation > of the entry > !image-2022-08-21-15-55-06-535.png|width=554,height=110! > This will help in the approval process. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1307) Loan Ideal disbursement to calculation cause to wrong interest rate
[
https://issues.apache.org/jira/browse/FINERACT-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandar Vidakovic updated FINERACT-1307:
---
Fix Version/s: 1.10.0
(was: 1.9.0)
> Loan Ideal disbursement to calculation cause to wrong interest rate
>
>
> Key: FINERACT-1307
> URL: https://issues.apache.org/jira/browse/FINERACT-1307
> Project: Apache Fineract
> Issue Type: Bug
> Components: Loan
>Reporter: eitan frailich
>Assignee: eitan frailich
>Priority: Minor
> Fix For: 1.10.0
>
> Attachments: image-2021-02-02-16-43-07-381.png
>
>
> *ISSUE*
> My issue/bug happens when I am setting "First repayment on" field I get a
> repayment schedule with a wrong interest rate for the first installment.
> Example: When I set "First repayment on" to 01/02/21 and expected
> disbursement is 27/1/21(Frist image) then I get the wrong interest.The first
> installment interest is 21,232.88$ (second Image) - calculated for the entire
> month (31 days) instead of 5 days (the time from the disbursement to the
> first repayment), the right interest should be 3424.75$.
> *After debugging:*
> In AbstractLoanScheduleGenerator there is a function
> {{calculateInterestStartDateForPeriod}} - it uses the {{idealDisbursment}}
> for setting the interest start date for the first installment, The
> {{idealDisbursment}} is calculated by
> {{idealDisbursementDateBasedOnFirstRepaymentDate}} which does
> [{{firstRepaymentDate}} - 1 repayment Period Frequency] aka, for 01/02/21
> with months as repyment frequency it will return 01/01/21.
> So when we dont set the "First repayment on" the {{idealDisbursment}} will be
> the expected disbursement date because the first repayment is always
> {{expectedDisbursment}}+1. But if we set the "First repayment on" we get the
> wrong value for the {{idealDisbursment}} - in my example we got 01/0/21 and
> this is why the first installment interest was calculated for an entire month
> instead of 5 days.
> *Is it a bug or not?*
> I am not sure why {{idealDisbursementDateBasedOnFirstRepaymentDate}} exists,
> the simple solution is to do idealDisbursment=expectedDisbursmentDate.I
> tried it locally and looks like it works, I will be happy to make a PR, but
> want to make sure indeed that the
> {{idealDisbursementDateBasedOnFirstRepaymentDate}} is redundant.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (FINERACT-1322) Add Support for a Bi Monthly Loan Product
[ https://issues.apache.org/jira/browse/FINERACT-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1322: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Add Support for a Bi Monthly Loan Product > - > > Key: FINERACT-1322 > URL: https://issues.apache.org/jira/browse/FINERACT-1322 > Project: Apache Fineract > Issue Type: New Feature > Components: Loan >Affects Versions: 1.8.0 >Reporter: Yemdjih Kaze Nasser >Priority: Major > Fix For: 1.10.0 > > > Add the ability to create a loan that is collected twice a month. Date > selection would be one of two options > Two dates selected for each month: default dates are already part of this > ensemble i.e 15th and 30th, 10th and 25th > These date combinations may change midway for e,g 10/25 may become 15/30, > Which means we can edit the loan product’ First and second date thus > affecting the schedule change from that day. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1561) Add new tagging fields to Data Tables
[
https://issues.apache.org/jira/browse/FINERACT-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandar Vidakovic updated FINERACT-1561:
---
Fix Version/s: 1.10.0
(was: 1.9.0)
> Add new tagging fields to Data Tables
> -
>
> Key: FINERACT-1561
> URL: https://issues.apache.org/jira/browse/FINERACT-1561
> Project: Apache Fineract
> Issue Type: Improvement
> Components: Data Tables
>Affects Versions: 1.6.0
>Reporter: Ed Cable
>Priority: Major
> Fix For: 1.10.0
>
>
> For retrieiving loan information for clients, we need to add additional
> response parameters to the below API:
>
> GET:
> [_https://DomainName/fineract-provider/api/v1/datatables/\{datatableName}/\{loanId}?genericResultSet=true_|https://domainname/fineract-provider/api/v1/datatables/%7BdatatableName%7D/%7BloanId%7D?genericResultSet=true]
>
> |New Parameter|Value/Amount|
> |tag_added_time|column value added time stamp|
> |tag_removed_time|column value modified time stamp|
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (FINERACT-1917) Major improvement to Savings Account
[ https://issues.apache.org/jira/browse/FINERACT-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1917: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Major improvement to Savings Account > > > Key: FINERACT-1917 > URL: https://issues.apache.org/jira/browse/FINERACT-1917 > Project: Apache Fineract > Issue Type: Improvement > Components: Savings >Reporter: James Dailey >Assignee: James Dailey >Priority: Major > Labels: BeanSalad > Fix For: 1.10.0 > > > This ticket is to capture any additional design ideas around the improvements > to misnamed "savings" account. While this started as "Savings" account, > where an interest rate may be assumed, it also now includes the idea of a > payment transaction account or checking account or wallet. Thus, the more > genericized version of this "should be" Current Account, or Payment Account. > Setting that naming issue aside, please upload any design documents you may > have to enhanced "savings accounts" in fineract. I understand that other > implementations have forked the code and built entirely new stuff, so it > would be good to get your ideas here. If all you can do is share > requirements, please do so in attachments to this ticket. Internal deadline > for sharing is April 30th. > Peter has created a set of tickets - please comment on those directly if you > have specific concerns or ideas for them. > Tickets in Peter's Order (Peter - please edit for clarity) > 1751 DONE (batch API related) > 1912 in progress > 1910 in progress > 1943 > 1939 > 1931 > 1938 > 1911 in progress > 1915 > 1916 > 1917 > 1831 > 1921 > 1929 > 1909 > webapp: > 1721 > 1727 > 1726 > 1722 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1950) Disallow backdated transactions - A Global Configuration
[ https://issues.apache.org/jira/browse/FINERACT-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1950: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Disallow backdated transactions - A Global Configuration > - > > Key: FINERACT-1950 > URL: https://issues.apache.org/jira/browse/FINERACT-1950 > Project: Apache Fineract > Issue Type: Improvement >Reporter: ibrahim kimbugwe >Assignee: Francis Guchie >Priority: Major > Fix For: 1.10.0 > > > We need to have a global configuration to disallow backdated transactions for > a given period without necessarily closing an accounting period in the > closing entries. > A use case of a teller not being allowed to post a backdated transaction on a > customer after the till was balanced or after COB. The accountant can however > have the right to post GL transactions on a back date. > > This should however be set as a global configuration that can be turned on > and off. > > [~francisguchie] and [~bgowda] and [~eroemma] what do you think of this > improvement? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-2028) Have correct Audit Log entries inserted related to Jobs
[ https://issues.apache.org/jira/browse/FINERACT-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-2028: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Have correct Audit Log entries inserted related to Jobs > --- > > Key: FINERACT-2028 > URL: https://issues.apache.org/jira/browse/FINERACT-2028 > Project: Apache Fineract > Issue Type: Improvement > Components: Job Scheduler >Affects Versions: 1.8.4 >Reporter: Peter Santa >Priority: Major > Labels: BeanSalad > Fix For: 1.10.0 > > > h1. Background > Currently there are no audit logs inserted while running jobs. > h1. Goal > Have correct audit log inserted. > h1. Acceptance Criteria > * there is a log entry in case the job is triggered -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1540) Rounding Mode unable to change from default 6
[ https://issues.apache.org/jira/browse/FINERACT-1540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1540: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Rounding Mode unable to change from default 6 > - > > Key: FINERACT-1540 > URL: https://issues.apache.org/jira/browse/FINERACT-1540 > Project: Apache Fineract > Issue Type: Bug > Components: Loan, System >Affects Versions: 1.7.0 >Reporter: Sifiso Mtetwa >Priority: Blocker > Labels: LOAN > Fix For: 1.10.0 > > Attachments: roundingmode.jpg, roundingmodeerror.jpg > > > If you create a product with Declining balance and Equal Amortisation the > scheduled repayments are never consistently equal. This is because Rounding > mode is currently a default of 6 in Global configurations. However if you > would like to change it to > > HALF_DOWN: If the discarded digit is .5 or lower, the last digit is rounded > down. > HALF_UP: If the discarded digit is .5 or greater, the next digit is rounded > up. > FLOOR: Rounds down to the nearest digit even if the discarded digit is .5 or > greater. > CEILING: If the discarded digit is anything but zero, the next digit is > rounded up. > as in this ticket [https://mifosforge.jira.com/browse/MIFOSX-858] > > Currently if you try and change to another value other than 6 it fails with > error "Unable to modify this configuration as it is a trap door > configuration. - " > This issue dates as far back as 2014 and still persists in Fineract 1.6.0. Is > there a fix for this issue or if there are any branches that have solved this > that we can merge. > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1966) Consolidate committer zone content from various sources into asciidoc
[ https://issues.apache.org/jira/browse/FINERACT-1966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1966: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Consolidate committer zone content from various sources into asciidoc > - > > Key: FINERACT-1966 > URL: https://issues.apache.org/jira/browse/FINERACT-1966 > Project: Apache Fineract > Issue Type: New Feature > Components: Docs >Reporter: John Ruhiu >Priority: Major > Fix For: 1.10.0 > > > Consolidate committer zone content from various sources into asciidoc in > order to have a single source of truth that is easier to maintain. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1664) Wrong Number of clients in a center
[ https://issues.apache.org/jira/browse/FINERACT-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1664: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Wrong Number of clients in a center > > > Key: FINERACT-1664 > URL: https://issues.apache.org/jira/browse/FINERACT-1664 > Project: Apache Fineract > Issue Type: Bug > Components: Groups >Affects Versions: 1.7.0, 1.8.0 >Reporter: ibrahim kimbugwe >Assignee: Rahul Pawar >Priority: Major > Fix For: 1.10.0 > > Attachments: image-2022-07-08-20-36-53-060.png > > > The number of clients in a center is wrong at the center details panel. It is > supposed to show the number of groups multiplied by the number of individual > members in individual groups. > !image-2022-07-08-20-36-53-060.png|width=534,height=303! > > [~francisguchie] , [~rrpawar] and [~eroemma] have you seen this issue? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1485) New Loan Charge type "upfront disbursement fees"
[ https://issues.apache.org/jira/browse/FINERACT-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1485: --- Fix Version/s: 1.10.0 (was: 1.9.0) > New Loan Charge type "upfront disbursement fees" > > > Key: FINERACT-1485 > URL: https://issues.apache.org/jira/browse/FINERACT-1485 > Project: Apache Fineract > Issue Type: Improvement > Components: Charges, Loan >Affects Versions: 1.8.0 >Reporter: Bharath Gowda >Assignee: Rahul Pawar >Priority: Major > Fix For: 1.10.0 > > Attachments: Upfront fee requirement.xlsx, screenshot-1.png > > > Refer Attachment for full details of the requirement. > |Requirement|Changes | > |New loan entity - fee type to be introduced |Upfront Disbursement Fee| > | > Upfront fee can be on |1. % approved amount > 2. Flat| > |Actual Disbursement Amount =|Disbursement amount entered - upfront fees > amount| > |Repayment schedule|Repayment schedule should be calculated based on the > actual disbursement amount(Disbursement amount entered - upfront fees)| > |Transaction|Upfront fees should be collected at the time of disbursement(as > shown in the transaction sample)| > |Accounting entry|no changes in accounting entries. it remains standard OOB > for disbursement, fees, and transactions| > |Repayment schedule calculation |once disbursed with the actual > disbursement amount- all calculation remains the same as OOB as per > product configuration| -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1959) Consolidate contributor's zone content from various sources into asciidoc
[ https://issues.apache.org/jira/browse/FINERACT-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1959: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Consolidate contributor's zone content from various sources into asciidoc > - > > Key: FINERACT-1959 > URL: https://issues.apache.org/jira/browse/FINERACT-1959 > Project: Apache Fineract > Issue Type: New Feature >Reporter: John Ruhiu >Priority: Major > Fix For: 1.10.0 > > > In order to have comprehensive and cohesive documentation, I am consolidating > content from various sources such as the wiki into asciidoc format which will > then be published using antora static generator. > This ticket covers the consolidation of contributor zone content. The > following sources were used: > * [https://cwiki.apache.org/confluence/display/FINERACT/Contributor%27s+Zone] > * [https://github.com/apache/fineract/blob/develop/CONTRIBUTING.md] > * [https://github.com/apache/fineract/#pull-requests] > * [https://github.com/apache/fineract/#checkstyle-and-spotless] > * [https://github.com/apache/fineract/#logging-guidelines] > * [https://github.com/apache/fineract/#error-handling-guidelines] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-2027) Permission evaluation for jobs
[ https://issues.apache.org/jira/browse/FINERACT-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-2027: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Permission evaluation for jobs > -- > > Key: FINERACT-2027 > URL: https://issues.apache.org/jira/browse/FINERACT-2027 > Project: Apache Fineract > Issue Type: Improvement > Components: Job Scheduler >Affects Versions: 1.8.4 >Reporter: Peter Santa >Priority: Major > Labels: BeanSalad > Fix For: 1.10.0 > > > h1. Background > Currently, when a job gets triggered via API, the permission of the > authenticated user is evaluated, whether it has permission to run jobs, > generally. If yes, the initiator user gets replaced by System user in the > context, and the job’s actions get triggered using that context. There are no > further permission checking while running jobs, e.g. for the specific job, or > a step of the job. > Whenever any permission checking gets introduced, during running the job, > performing actions will not be permitted, because by default the used System > user does not have any permission - this could break currently running, live > systems. > h1. Goal > Have the permissions evaluated based on the authenticated user and the > action, when triggering a job via API. Have job-specific permission. > h1. Analysis > * to be evaluated, whether it worked like this earlier, or got broken when > implementing features recently. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1918) Create Loan Product - field transactionProcessingStrategyCode is breaking Mifos-UI
[
https://issues.apache.org/jira/browse/FINERACT-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandar Vidakovic updated FINERACT-1918:
---
Fix Version/s: 1.10.0
(was: 1.9.0)
> Create Loan Product - field transactionProcessingStrategyCode is breaking
> Mifos-UI
> --
>
> Key: FINERACT-1918
> URL: https://issues.apache.org/jira/browse/FINERACT-1918
> Project: Apache Fineract
> Issue Type: Bug
> Components: Loan
>Affects Versions: 1.9.0
>Reporter: Mohit Sinha
>Priority: Major
> Fix For: 1.10.0
>
> Attachments: Screenshot 2023-04-06 at 3.04.35 PM.png, Screenshot
> 2023-04-06 at 3.05.08 PM.png, Screenshot 2023-04-06 at 3.05.27 PM.png
>
>
> Till version {_}1.8.4{_}, the API {_}api/v1/loanproducts{_}, was having the
> field {_}transactionProcessingStrategyId{_}.
> I have verified that the functionality works fine till {_}1.8.4{_}.
> This field is currently handled in the develop branch of openmf/community-app.
> In the current _develop_ branch of Fineract,
> _transactionProcessingStrategyCode_ is expected in place of it.
> So, this is causing a breaking change in the community-app.
> Should we fix it over here by allowing both these fields and giving more
> precedence to _transactionProcessingStrategyId_ if both the fields are passed.
> Or should a commit be made in the community-app to fix this?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (FINERACT-1436) Support to add Multi Disbursement details on same day
[ https://issues.apache.org/jira/browse/FINERACT-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1436: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Support to add Multi Disbursement details on same day > - > > Key: FINERACT-1436 > URL: https://issues.apache.org/jira/browse/FINERACT-1436 > Project: Apache Fineract > Issue Type: Improvement >Affects Versions: 1.8.0 >Reporter: Bharath Gowda >Priority: Major > Fix For: 1.10.0 > > Attachments: image-2021-11-08-14-01-38-190.png > > > Support to add Multi Disbursement details on same day > Currently, in a multi disbursement loan account, it is not possible to add > multiple disbursements on the same day. > We need to implement this option to support one of the most common use case > in credit lines or other similar products. > > To reproduce > 1. Create a loan product with multi-tranche enabled > 2. Create a loan account with 1 tranche (with amount lesser than approved > amount) > 3. disburse the loan > 4. Now try to add another tranche for the same day. > the system will not allow adding another tranche on the same day with the > error msg "Tranche disbursement date must be unique -" > !image-2021-11-08-14-01-38-190.png! > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1185) Interest Posting on Anniversary Dates
[ https://issues.apache.org/jira/browse/FINERACT-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1185: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Interest Posting on Anniversary Dates > - > > Key: FINERACT-1185 > URL: https://issues.apache.org/jira/browse/FINERACT-1185 > Project: Apache Fineract > Issue Type: New Feature >Affects Versions: 1.8.0 >Reporter: Airsay >Priority: Critical > Fix For: 1.10.0 > > > "Anniversary" Interest posting period. Some clients don't necessarily post > interest on the last day of the week, or month or quarter. What they do is > post interest on the "anniversary" date. So for a fixed deposit or recurring > deposit account opened on the 1st of the month, interest is posted on the > first of the month for monthly interests. Those opened say on the 29th are > posted on the 29th (or the last day of the month if that month doesn't have > 29 days like February). A similar thing is done for quarterly or bi-annual > postings. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-2025) SQL Query Improvement
[ https://issues.apache.org/jira/browse/FINERACT-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-2025: --- Fix Version/s: 1.10.0 (was: 1.9.0) > SQL Query Improvement > - > > Key: FINERACT-2025 > URL: https://issues.apache.org/jira/browse/FINERACT-2025 > Project: Apache Fineract > Issue Type: Bug >Affects Versions: 1.8.4 >Reporter: Ed Cable >Assignee: Mihaly Dallos >Priority: Major > Fix For: 1.10.0 > > > Multiple areas within fineract-provider to be improved. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1398) Standardize the Character Set and the Collation
[ https://issues.apache.org/jira/browse/FINERACT-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1398: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Standardize the Character Set and the Collation > --- > > Key: FINERACT-1398 > URL: https://issues.apache.org/jira/browse/FINERACT-1398 > Project: Apache Fineract > Issue Type: Improvement > Components: Database, Migration Scripts >Affects Versions: 1.8.0 >Reporter: Victor Romero >Priority: Major > Fix For: 1.10.0 > > > It is required to have a Standard in Fineract for handling the Information > entered into the Database so then the Database creation, tables and migration > script should use the Standard Charset and Collation defined for Fineract. > It is proposed to use as Standard in Fineract: utf8mb4 as charset and > utf8mb4_unicode_ci as collation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1403) Advance repayment issue after loan rescheduling
[ https://issues.apache.org/jira/browse/FINERACT-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1403: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Advance repayment issue after loan rescheduling > --- > > Key: FINERACT-1403 > URL: https://issues.apache.org/jira/browse/FINERACT-1403 > Project: Apache Fineract > Issue Type: Bug > Components: Loan >Affects Versions: 1.5.0 >Reporter: Bharath Gowda >Assignee: Avik Ganguly >Priority: Major > Fix For: 1.10.0 > > Attachments: after advance repayment.png, before advance > repayment.png, product configuration.png > > > The loan repayment schedule is calculating the wrong principal when advance > payment is done after the loan reschedule is done. > > To reproduce, > 1. Create a loan product as per the shared screenshot > 2. Create a loan account and reschedule any installment and make the payment > for the rescheduled date > 3. Make an advance payment for an installment (for any installment after the > rescheduled installment) > Issue > when advance payment is done, the system is changing the principal amount, > and in turn, the installment is still not completely paid > because of this, the loan is considered overdue even if the payment is done > on/before time. > > Please find the example screenshot attached of the issue loan with complete > explanation and expected result > please do let me know if you need any more clarification -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1750) User permissions not available
[ https://issues.apache.org/jira/browse/FINERACT-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1750: --- Fix Version/s: 1.10.0 (was: 1.9.0) > User permissions not available > --- > > Key: FINERACT-1750 > URL: https://issues.apache.org/jira/browse/FINERACT-1750 > Project: Apache Fineract > Issue Type: Bug > Components: User Management >Affects Versions: 1.7.0 >Reporter: ibrahim kimbugwe >Assignee: Francis Guchie >Priority: Major > Fix For: 1.10.0 > > Attachments: client summary-1.png, permissoin error-1.png > > > We setup users with different permissions. It has come to our attention that > some permissions are not available like the client summary. Others are > available but even when granted, the system does not allow users to access > that information. An example is the client summary and the credit bureau. > !client summary-1.png|width=831,height=378! > !permissoin error-1.png|width=838,height=341! > There is no permission for read credit bureau and client summary. The same > applies to the reports, even when a user is given the rights to view a > report, the system does not show any report unless you give the person the > report super user rights which should not be the case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1699) Print Submitted collection sheet
[ https://issues.apache.org/jira/browse/FINERACT-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1699: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Print Submitted collection sheet > > > Key: FINERACT-1699 > URL: https://issues.apache.org/jira/browse/FINERACT-1699 > Project: Apache Fineract > Issue Type: Improvement > Components: Groups >Affects Versions: 1.7.0 >Reporter: ibrahim kimbugwe >Assignee: Rahul Pawar >Priority: Major > Fix For: 1.10.0 > > Attachments: image-2022-08-21-14-55-53-508.png > > > On submitting a collection sheet, the system posts the money to the > respective accounts. There is however no check to see the submitted sheet > after submission. > !image-2022-08-21-14-55-53-508.png|width=558,height=480! > We are looking at a scenario where the system user posts the correct figures > to the wrong person. All the validations are okay with the totals matching. > This would mean that customer A gets money that was supposed to be posted > onto customer B and vice versa. We need to have a printout either before > submission or after submission to be verified and filed by the organisation. > This will go further to enable the organisation to handle customers' issues > related to mismatching figures with their passbooks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1227) Client Java API for binary document files and images are generated wrong
[
https://issues.apache.org/jira/browse/FINERACT-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandar Vidakovic updated FINERACT-1227:
---
Fix Version/s: 1.10.0
(was: 1.9.0)
> Client Java API for binary document files and images are generated wrong
>
>
> Key: FINERACT-1227
> URL: https://issues.apache.org/jira/browse/FINERACT-1227
> Project: Apache Fineract
> Issue Type: Bug
> Components: SDK
>Affects Versions: 1.8.0
>Reporter: Michael Vorburger
>Priority: Major
> Fix For: 1.10.0
>
>
> The {{org.apache.fineract.client.services.DocumentsApi.downloadFile(String,
> Long, Long)}} (for
> {{_entityType_/_entityId_/documents/_documentId_/attachment}}) returns
> {{Call}}.. it's missing the binary downloaded file?
> Must be something wrong in the Swagger annotations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (FINERACT-1560) Enhance Retrieve loan information by Client ID API for new required response parameters
[ https://issues.apache.org/jira/browse/FINERACT-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1560: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Enhance Retrieve loan information by Client ID API for new required response > parameters > --- > > Key: FINERACT-1560 > URL: https://issues.apache.org/jira/browse/FINERACT-1560 > Project: Apache Fineract > Issue Type: Improvement > Components: Loan >Affects Versions: 1.6.0, 1.7.0, 1.8.0 >Reporter: Ed Cable >Assignee: Rahul Pawar >Priority: Major > Fix For: 1.10.0 > > > For retrieving the loan information for a client, we need to enhance the > following API with additonal parameters outlined below. > +GET:+ > _https://DomainName/api/v1/loans/template?templateType=individual=1=1_ > > |New Parameter|Value/Amount| > |available_disbursement_amount|It is the difference of approved amount and > disbursed amount| > |past_due_days|No of days the loan is overdue,current date - duedate| > |next_payment_due_date|Based on the current date, need to populate the next > payment due date| > |delinquent_days|No of days the loan is in arrears, current date - > duedate-grace period| > |delinquent_date|Date the loan is in arrears, current date - duedate-grace > period| > |delinquent_amount|amount overdue after the grace period| > |last_payment_date|last repayment made date on the loan| > |last_payment_amount|last repayment amount made date on the loan| > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1700) Bulk JLG loan Application not displaying loan terms
[ https://issues.apache.org/jira/browse/FINERACT-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1700: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Bulk JLG loan Application not displaying loan terms > --- > > Key: FINERACT-1700 > URL: https://issues.apache.org/jira/browse/FINERACT-1700 > Project: Apache Fineract > Issue Type: Bug > Components: Groups >Affects Versions: 1.7.0 >Reporter: ibrahim kimbugwe >Assignee: Francis Guchie >Priority: Major > Fix For: 1.10.0 > > Attachments: image-2022-08-21-15-31-25-813.png > > > During the bulk JLG loan application, procedures should follow as per the > documentation here, > [https://docs.mifos.org/mifosx/user-manual/for-operational-users-mifos-x-web-app/accounts-and-transactions/loan-accounts/how-to-process-bulk-jlg-loan-application] > However, after adding client loan amounts and submitting the application, the > system allows the application to go through without returning to the loan > terms page for the individual clients. This means that Incase of a charge > that requires a savings account, the validation will fail since the API does > not return the loan terms window for all the applied loans. > !image-2022-08-21-15-31-25-813.png|width=547,height=376! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1957) Fix Interchanged Balances On Savings Withdrawal Transaction and Savings Withdrawal Charge Transaction
[ https://issues.apache.org/jira/browse/FINERACT-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1957: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Fix Interchanged Balances On Savings Withdrawal Transaction and Savings > Withdrawal Charge Transaction > - > > Key: FINERACT-1957 > URL: https://issues.apache.org/jira/browse/FINERACT-1957 > Project: Apache Fineract > Issue Type: Improvement > Components: Savings >Affects Versions: 1.7.3, 1.7.2, 1.8.3, 1.8.2 >Reporter: Kigenyi Wilfred >Assignee: Francis Guchie >Priority: Major > Fix For: 1.10.0 > > > When using automatic withdrawal charges on a savings account, it sometimes > happens that the withdrawal transaction and the corresponding withdrawal > charge transaction happen at "The same time". Sometimes the withdrawal > transaction happens before the charge transaction and sometimes it is the > other way round, so one cannot predict if the transaction id for the charge > transaction will be greater or less that of the actual withdrawal > transaction. Since the SavingsAccountTransactionComparator compares > created_date (these can be the same) and id (there is no assurance as to > which one will come first), the comparison become unpredictable for this > particular case and the logic sometimes ends up interchanging running > balances on the transactions. So when a list of transactions is pulled it may > show the interchanged running balances for withdrawal charge transaction and > the withdrawal transaction. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1704) Code cleanup
[ https://issues.apache.org/jira/browse/FINERACT-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1704: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Code cleanup > > > Key: FINERACT-1704 > URL: https://issues.apache.org/jira/browse/FINERACT-1704 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Minor > Fix For: 1.10.0 > > > Doing some cleanup and fix typos. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1960) Periodic Accrual Accounting for Savings product
[ https://issues.apache.org/jira/browse/FINERACT-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1960: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Periodic Accrual Accounting for Savings product > --- > > Key: FINERACT-1960 > URL: https://issues.apache.org/jira/browse/FINERACT-1960 > Project: Apache Fineract > Issue Type: Improvement > Components: Savings >Reporter: Bharath Gowda >Assignee: Ed Cable >Priority: Major > Fix For: 1.10.0 > > > *As a* user > *I want to* _configure periodic accural accounting for Savings products_ > *in order to* _have accural accounting journal entries for Savings accounts_ > h4. *Background and details:* > Fineract supports only cash-based accounting entries for deposit products > there is a need for accrual accounting for products > *Acceptance criteria* > # user should be able to confiugre periodic accural accounting for Savings > products > # Monetory transactions should post accrual jounral entries for savings > accounts > # Refer below wiki for complete requirement > # user should be able to configure this from the Webapp UI as well. > [https://cwiki.apache.org/confluence/display/FINERACT/Periodic+Accrual+Accounting+option+for+Deposit+Products] > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1586) Reduce Boilerplate Code by Introducing lombok to Reduce getters/setters and Mapstruct to map REST DTO to Entity Objects
[ https://issues.apache.org/jira/browse/FINERACT-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1586: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Reduce Boilerplate Code by Introducing lombok to Reduce getters/setters and > Mapstruct to map REST DTO to Entity Objects > --- > > Key: FINERACT-1586 > URL: https://issues.apache.org/jira/browse/FINERACT-1586 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Rahul Goel >Priority: Minor > Labels: full-time, gsoc2023, mentor > Fix For: 1.10.0 > > > Lombok could help us to not only reduce a large amount of code, but also to > fix a couple of inconsistencies in the code base: > * getters/setters with non-standard characters (e. g. underscores) > * getters/setters with typos > The layered architecture of Fineract requires mapping between REST DTO > classes and internal entity classes. The current code base contains various > strategies to achieve this: > * private functions > * static functions > * mapping classes > All of these approaches are very manual (and error prone) and difficult to > maintain. Mapstruct can help here: > * throw errors at compile time (missing new attributes, type changes etc.) > * one common concept (easier to understand) > * reduce manually maintained code and replace mostly generated code > Challenges: > * maintain immutability (especially in DTO classes) > * should we fluent builder pattern? > * backwards compatibility > * these improvements cannot be introduced as one pull request, but have to > be split up at least at the “module” level (clients, loans, accounts etc.). > This would result in approximately 30 pull requests; if we split up Lombok > and Mapstruct then it would be 30 PRs each (=60); we would need this fine > grained approach to make a transition as painless as possible > * some classes are maybe beyond repair (e. g. Loan.java with 6000 lines of > code, the smaller part getters/setters and a long list of utility/business > logic functions) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1670) Introduce Auditable entities - Storing date time in UTC
[ https://issues.apache.org/jira/browse/FINERACT-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1670: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Introduce Auditable entities - Storing date time in UTC > --- > > Key: FINERACT-1670 > URL: https://issues.apache.org/jira/browse/FINERACT-1670 > Project: Apache Fineract > Issue Type: Improvement >Affects Versions: 1.7.0, 1.8.0 >Reporter: Adam Saghy >Assignee: Adam Saghy >Priority: Major > Fix For: 1.10.0 > > Attachments: Re_ Timezone issues with Daylight savings.rtfd.zip > > > AbstractAuditableCustom interface to be used more widely with entities. > Many Fineract entity has no proper audit fields (creation date & time, last > modification date & time, created by, modified by entries. > Many entities has a variety of the above fields but with custom > implementation and not fit perfectly for audit purposes (see LoanTransaction). > All business entity ( utility entities excluded) should implement the above > interface and fill properly the audit fields with a common, generic way. > The similar custom fields to be removed / repurposed. > The Datetime fields to be stored in UTC! The datetime fields when its fetched > from the DB it is UTC, so it needs to be converted to the proper tenant > timezone if there is any business logic attached to them. > > Storing in UTC is important to avoid daylight savings and "incorrect timezone > is used" issues: > - Some places the tenant timezone used > - Som places the system timezone used > > *Acceptance criteria* > * Every custom fields with similar purpose to be decommissioned > * All datetime field to be utc > * It must be a backward-compatible change! > ** Column cannot be removed! > *Change proposal* > * created_on_utc: Timezone aware datetime field > * last_modified_on_utc: Timezone aware datetime field > * created_by: Long (AppUser id) > * last_modified_by: Lond (AppUser id) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1577) TLS support in fully managed serverless environments
[ https://issues.apache.org/jira/browse/FINERACT-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1577: --- Fix Version/s: 1.10.0 (was: 1.9.0) > TLS support in fully managed serverless environments > > > Key: FINERACT-1577 > URL: https://issues.apache.org/jira/browse/FINERACT-1577 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Victor Romero >Assignee: Victor Romero >Priority: Major > Fix For: 1.10.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1576) GCP Cloud SQL Support
[ https://issues.apache.org/jira/browse/FINERACT-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1576: --- Fix Version/s: 1.10.0 (was: 1.9.0) > GCP Cloud SQL Support > - > > Key: FINERACT-1576 > URL: https://issues.apache.org/jira/browse/FINERACT-1576 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Victor Romero >Assignee: Victor Romero >Priority: Major > Fix For: 1.10.0 > > > GCP Cloud SQL Support has advantage for using a fully managed SQL > environment, Cloud SQL on GCP supports MySQL & Postgresql -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1575) IPv6 Support for deploying Apache Fineract on Serverless Cloud Deployment
[ https://issues.apache.org/jira/browse/FINERACT-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17803829#comment-17803829 ] Aleksandar Vidakovic commented on FINERACT-1575: Isn't this solvable with a simple JVM command line parameter (some like "prefer IPv6" vs "prefer IPv4")? > IPv6 Support for deploying Apache Fineract on Serverless Cloud Deployment > - > > Key: FINERACT-1575 > URL: https://issues.apache.org/jira/browse/FINERACT-1575 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Victor Romero >Assignee: Victor Romero >Priority: Major > Fix For: 1.9.0 > > > When deploying the Apache Fineract in fully managed serverless environment we > got issues because the SpringBoot is requesting a full compliance IPV6 > address, if the address is not following the convention Spring is throwing > exception and then anything from the HTTP will be rejected. > > https://github.com/spring-projects/spring-framework/issues/27013 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1575) IPv6 Support for deploying Apache Fineract on Serverless Cloud Deployment
[ https://issues.apache.org/jira/browse/FINERACT-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1575: --- Fix Version/s: 1.10.0 > IPv6 Support for deploying Apache Fineract on Serverless Cloud Deployment > - > > Key: FINERACT-1575 > URL: https://issues.apache.org/jira/browse/FINERACT-1575 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Victor Romero >Assignee: Victor Romero >Priority: Major > Fix For: 1.10.0 > > > When deploying the Apache Fineract in fully managed serverless environment we > got issues because the SpringBoot is requesting a full compliance IPV6 > address, if the address is not following the convention Spring is throwing > exception and then anything from the HTTP will be rejected. > > https://github.com/spring-projects/spring-framework/issues/27013 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1575) IPv6 Support for deploying Apache Fineract on Serverless Cloud Deployment
[ https://issues.apache.org/jira/browse/FINERACT-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1575: --- Fix Version/s: (was: 1.9.0) > IPv6 Support for deploying Apache Fineract on Serverless Cloud Deployment > - > > Key: FINERACT-1575 > URL: https://issues.apache.org/jira/browse/FINERACT-1575 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Victor Romero >Assignee: Victor Romero >Priority: Major > > When deploying the Apache Fineract in fully managed serverless environment we > got issues because the SpringBoot is requesting a full compliance IPV6 > address, if the address is not following the convention Spring is throwing > exception and then anything from the HTTP will be rejected. > > https://github.com/spring-projects/spring-framework/issues/27013 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1417) Introduce a new pivot date to filter the savings transactions.
[ https://issues.apache.org/jira/browse/FINERACT-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1417: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Introduce a new pivot date to filter the savings transactions. > -- > > Key: FINERACT-1417 > URL: https://issues.apache.org/jira/browse/FINERACT-1417 > Project: Apache Fineract > Issue Type: New Feature > Components: Savings >Reporter: Benura Abeywardena >Assignee: Benura Abeywardena >Priority: Major > Fix For: 1.10.0 > > > Current fineract code base use multiple for loops to calculate the > transaction related data on a savings transaction. This adds an unnecessary > latency to a transaction request. By introducing a pivot date, this number of > iterations can be reduced with the help of savings account summary available. > However, in this scenario back dated transactions will not be allowed. Since, > there can be scenarios where back dated transactions are needed, a global > configuration is introduced to prevent breaking the existing use cases > completely. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1289) Tax component not working as expected
[ https://issues.apache.org/jira/browse/FINERACT-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1289: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Tax component not working as expected > - > > Key: FINERACT-1289 > URL: https://issues.apache.org/jira/browse/FINERACT-1289 > Project: Apache Fineract > Issue Type: Bug > Components: Accounting, Charges >Affects Versions: 1.4.0 >Reporter: Bharath Gowda >Assignee: Chirag Gupta >Priority: Major > Fix For: 1.10.0 > > Attachments: loan charge config.png, loan charge split not > happening.png, loan product config -1.png, loan product config -2.png, tax > component config.jpeg, tax group config.png > > > tax attached to the loan charge is not getting affected at the > loan/accounting level > To reproduce > 1. Create a tax component-> create a tax group with the component created. > 2. Create loan charge(any parameter, refer to the attachment for the > parameters I used) and map the tax group created. > 3. Add the charge to the loan product (with periodic accrual accounting) > enabled > 4. create/approve/disburse a loan from that loan product. > 5. Ideally the charge with the tax attached should have JE splits for charge > amount and tax amount separated. > But the tax bifurcation is not happening > > Have attached > product config screenshot, charge config screenshot, tax config screenshot, > and loan issue screenshot for more understanding > Please add a comment if you need any help > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1095) Remove direct sqlSearch support from /clients and all other APIs [Security & Performance]
[
https://issues.apache.org/jira/browse/FINERACT-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandar Vidakovic updated FINERACT-1095:
---
Fix Version/s: 1.10.0
(was: 1.9.0)
> Remove direct sqlSearch support from /clients and all other APIs [Security &
> Performance]
> -
>
> Key: FINERACT-1095
> URL: https://issues.apache.org/jira/browse/FINERACT-1095
> Project: Apache Fineract
> Issue Type: Improvement
>Reporter: Michael Vorburger
>Assignee: Mihaly Dallos
>Priority: Major
> Fix For: 1.10.0
>
>
> While code reviewing PRs from [~Manthan] such as
> [https://github.com/apache/fineract/pull/1171/files] and
> [https://github.com/apache/fineract/pull/1123/files] re. FINERACT-854, I've
> learnt about Fineract's support for an {{sqlSearch}} parameter on a number of
> its APIs, such as {{/clients}} (and others).
> According to
> [https://demo.fineract.dev/fineract-provider/api-docs/apiLive.htm] :
> {quote}_sqlSearch
> String optional
> Use an sql fragment valid for the underlying client schema to filter
> results. e.g. display_name like %K%
> {quote}
> [https://github.com/apache/fineract/search?p=2=sqlSearch_q=sqlSearch]
> shows all current occurrences. There are a number, but not THAT many either.
> (By far not every API supports this, only a handful.)
> This can be used e.g. like this:
> [https://demo.fineract.dev/fineract-provider/api/v1/clients?paged=true=c.account_no=3=default]
> To me, this is an egregious violation of "layering architecture". Basically,
> the REST API gives you direct SQL database access! You apparently have to
> know the exact name of not the SQL table but the alias used in the respective
> internally hard-coded query (note the use of {{c.}} in the example above, NOT
> {{m_client}}), and the internal SQL column name (note the use of
> {{account_no}}, NOT {{accountNo}}). There is no real documentation how to use
> this, and even if there were, in my tests I've noticed its fairly easy to
> provoke _500 Internal Server Errors_ when using {{sqlSearch}} with a slightly
> wrong syntax.
> From a security point of view, it's not quite as bad as it looks, because
> there is code with heuristics to "validate" the {{sqlSearch}} and prevent SQL
> Injections. But that could have holes (I don't want to know!), so... this
> still isn't great, at all, IMHO.
> From a performance point of view, permitting clients to run arbitrary queries
> isn't great either. You can't really reliable offer performance guarantees,
> or offer tuning with indices, if at the end of the day the wide open API just
> lets a client "query whatever they want" anyway.
> Use of {{sqlSearch}} by (public) API clients isn't that hard to find. I did
> some digging, and:
> * The new web-app UI doesn't use sqlSearch (or not yet), see
> [https://github.com/openMF/web-app/search?q=sqlSearch_q=sqlSearch]
> * The old community-app UI does use sqlSearch, see
> [https://github.com/openMF/community-app/search?p=1=sqlSearch_q=sqlSearch].
> But only in 2 very specific places, for Loans' {{l.loan_status_id in
> (100,200)}} and Clients' {{c.status_enum=100}}. This was apparently
> introduced by [~vishwasbabu] in
> [https://github.com/openMF/community-app/pull/1582|https://github.com/openMF/community-app/pull/1582/files]
> for [MIFOSX-2712.|https://mifosforge.jira.com/browse/MIFOSX-2712.] It's
> noteworthy that the Find on
> [https://cui.fineract.dev/.../clients|https://cui.fineract.dev/?baseApiUrl=https://demo.fineract.dev=default#/clients]
> does NOT use {{sqlSearch}} but the [/search
> API|https://demo.fineract.dev/fineract-provider/api-docs/apiLive.htm#search]
> * other repos on openMF, such as Mobile Apps & Co, don't realy seem to
> actively use {{sqlSearch}}, looking at
> [https://github.com/search?p=7=org%3AopenMF+sqlSearch=Code]
> Other than that, I don't know if anyone actively using {{sqlSearch}} would
> have any major objections to... just simply altogether removing this
> entirely? Folks may of course be using this in their own client UIs, but...
> they really shouldn't, this is a "bad" API. If you are missing a query
> facility, just contribute to the upstream project and raise a pull request to
> add whatever query option you are missing to whatever Fineract API (such as
> e.g. by status for Loans and Clients).
> Let's further discuss on the developer mailing list on thread "Use of
> sqlSearch argument in Groups/Clients List" if anyone wants to strongly defend
> {{sqlSearch}}. If not, let's just completely remove it. We do have to first
> replace the small current use in the community-app.
> PS: Nota bene that this issue isn't stating that a REST API with query
> capabilities is bad
[jira] [Updated] (FINERACT-1394) Partially Revert FIN-1112 "Replace ZoneId.systemDefault() with tenant's timezone"
[
https://issues.apache.org/jira/browse/FINERACT-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandar Vidakovic updated FINERACT-1394:
---
Fix Version/s: 1.10.0
(was: 1.9.0)
> Partially Revert FIN-1112 "Replace ZoneId.systemDefault() with tenant's
> timezone"
> -
>
> Key: FINERACT-1394
> URL: https://issues.apache.org/jira/browse/FINERACT-1394
> Project: Apache Fineract
> Issue Type: Bug
>Reporter: Avik Ganguly
>Assignee: Avik Ganguly
>Priority: Major
> Fix For: 1.10.0
>
>
> [~ptuomola] [~Percy Ashu] [~awasum] [~vorburger] :
> FINERACT-826
> actualDisbursementDate.toDate() got replaced by
> java.util.Date.from(actualDisbursementDate.atStartOfDay(ZoneId.systemDefault()).toInstant());
> Before FINERACT-1112
> actualDisbursementDate = T
> Server Timezone : +05:30Z, Tenant Timezone : +6Z
> ZoneId zone = ZoneId.systemDefault(); //+05:30Z
> ZonedDateTime dateTime = actualDisbursementDate.atStartOfDay(zone);
> //Midnight +5:30Z
> Instant instant = dateTime.toInstant(); // T-1 Midnight + 18:30 0Z
> Date dt = Date.from(instant); // T-1 Midnight + 18:30 + 5:30 = T 00:00 +05:30Z
> FINERACT-1112
> If tenant timezone is ahead of server timezone, then :-
> Server Timezone : +05:30Z, Tenant Timezone : +6Z
> actualDisbursementDate = T
> ZoneId zone = DateUtils.getDateTimeZoneOfTenant(); //+6Z // Previously
> ZoneId.systemDefault()
> ZonedDateTime dateTime = actualDisbursementDate.atStartOfDay(zone);
> //Midnight +6Z
> Instant instant = dateTime.toInstant(); // T-1 Midnight + 18 0Z
> Date dt = Date.from(instant); // T-1 Midnight + 18 + 5:30 = T-1 23:30 +05:30Z
> If tenant timezone and server timezones are different, then this creates a
> T-1 issue for all txn dates populated by application.
> {quote}Hi - in all the places where this currently calls
> ZoneId.systemDefault(), should we not be retrieving the appropriate tenant
> timezone instead? I know that's not what the previous code does, but wouldn't
> that be the right behaviour for any logic that is related to a specific
> tenant - i.e. we should be using the tenant's timezone for any dates?
> {quote}
> {quote}actualDisbursementDate.toDate() got replaced by
> java.util.Date.from(actualDisbursementDate.atStartOfDay(ZoneId.systemDefault()).toInstant());
> {quote}
> This part looks mostly correct as this is the most popular way
> ([https://stackoverflow.com/questions/22929237/convert-java-time-localdate-into-java-util-date-type/22929420])
> to convert time.date to util.date. Note that the popular answer is
> questioned in it's comments section because atStartOfDay changes the time but
> overall the answer fixes the question.
> Problem is with using DateUtils.getDateTimeZoneOfTenant() instead of
> ZoneId.systemDefault() as this deviates from the solution provided for
> Fineract-826. A tenant is already passing the correct tenant-specific date in
> the API. There is no need to mess with the date by applying tenant timezone
> all over again.
> We have reverted DateUtils.getDateTimeZoneOfTenant() to
> ZoneId.systemDefault() wherever date was being parsed with atStartOfDay logic
> and so far SIT is successful. Please approve the corresponding PR if you
> approve of this logic reversal.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (FINERACT-1052) Over Payment of loans is Allowed by Default
[ https://issues.apache.org/jira/browse/FINERACT-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1052: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Over Payment of loans is Allowed by Default > > > Key: FINERACT-1052 > URL: https://issues.apache.org/jira/browse/FINERACT-1052 > Project: Apache Fineract > Issue Type: New Feature > Components: Loan >Affects Versions: 1.3.0, 1.4.0 >Reporter: Francis Guchie >Assignee: Francis Guchie >Priority: Critical > Labels: newbie > Fix For: 1.10.0 > > Attachments: 5.8m Loan Balance.png, 5.8m loan Balance Over Payment > Message.png, Config - Disable Loan Over Payment.jpg, RESTRICTING OVER PAYMENT > OF LOANS.docx > > > Impacted versions: all MifosX versions including latest build > Steps to reproduce: > Select any loan in MifosX and make a payment over and above the dues > Current behavior: > MifosX will accept this > Expected behavior: > We create a global setting where its optional for super user to set allow or > restrict users from over paying loans -- This can be done at global > configurations => -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1102) Swagger Codegen Client JAR should be available on a Maven repo
[ https://issues.apache.org/jira/browse/FINERACT-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-1102: --- Fix Version/s: 1.10.0 (was: 1.9.0) > Swagger Codegen Client JAR should be available on a Maven repo > -- > > Key: FINERACT-1102 > URL: https://issues.apache.org/jira/browse/FINERACT-1102 > Project: Apache Fineract > Issue Type: Improvement > Components: SDK >Reporter: Michael Vorburger >Assignee: Aleksandar Vidakovic >Priority: Major > Fix For: 1.10.0 > > > FINERACT-838 contributed Swagger Codegen Client generation. > In order for the JAR built from that to actually be easily usable, we should > "distribute" it... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (FINERACT-2012) Fineract resource settings
[ https://issues.apache.org/jira/browse/FINERACT-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic resolved FINERACT-2012. Resolution: Fixed > Fineract resource settings > -- > > Key: FINERACT-2012 > URL: https://issues.apache.org/jira/browse/FINERACT-2012 > Project: Apache Fineract > Issue Type: Bug > Components: Deployment >Reporter: Peter Santa >Assignee: Aleksandar Vidakovic >Priority: Major > Labels: BeanSalad > Fix For: 1.9.0 > > > Currently the build.gradle file for fineract-provider sets some options for > the Java runtime. Among these there are some memory-related options: > '-Xms1G', > '-XX:MinRAMPercentage=25', > '-XX:MaxRAMPercentage=80', > Unfortunately these options can't be easily overwritten via environment > variables, because: > _JAVA_OPTIONS --> this is a non-standard option, not all JVM implementations > necessarily support this (https://bugs.openjdk.org/browse/JDK-4971166), and > instead of _JAVA_OPTIONS, JAVA_TOOL_OPTIONS is recommended > JAVA_TOOL_OPTIONS --> unfrtunately explicitly specified command line > arguments take precedence of values set as part of JAVA_TOOL_OPTIONS, so this > method doesn't work > JDK_TOOL_OPTIONS --> same issue as with JAVA_TOOL_OPTIONS > The best way to approach this would be to not set these memory-related > options (at least not the maximums) during build-time, enabling the usage of > JAVA_TOOL_OPTIONS/JDK_TOOL_OPTIONS. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (FINERACT-1210) Swagger TypeScript client
[ https://issues.apache.org/jira/browse/FINERACT-1210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic resolved FINERACT-1210. Resolution: Fixed Still needs to be published to NPM, but the code generation is in place. > Swagger TypeScript client > - > > Key: FINERACT-1210 > URL: https://issues.apache.org/jira/browse/FINERACT-1210 > Project: Apache Fineract > Issue Type: New Feature > Components: SDK >Reporter: Michael Vorburger >Assignee: Aleksandar Vidakovic >Priority: Major > Fix For: 1.9.0 > > > As a follow up to FINERACT-838 and FINERACT-1189, it could be pretty neat to > code generate a TypeScript client by Swagger. I would prioritize this AFTER > finishing work on the Java client (so do e.g. FINERACT-1102 and > FINERACT-1209 FIRST), but BEFORE e.g. Go, Ruby, Swift and other clients. > To me, this seems like a useful goal, as it could be used by future UIs. > Especially if we were to push it to NPM (equivalent to FINERACT-1102). > [~aleks] [~ChinmayKulkarni] [~ptuomola] > Fineract SDK - here we come. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-2009) Upgrade latest framework libs
[ https://issues.apache.org/jira/browse/FINERACT-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-2009: --- Priority: Blocker (was: Minor) > Upgrade latest framework libs > - > > Key: FINERACT-2009 > URL: https://issues.apache.org/jira/browse/FINERACT-2009 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Aleksandar Vidakovic >Assignee: Aleksandar Vidakovic >Priority: Blocker > Fix For: 1.9.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (FINERACT-1893) Run Reports fix for develop
[ https://issues.apache.org/jira/browse/FINERACT-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic resolved FINERACT-1893. Resolution: Fixed > Run Reports fix for develop > --- > > Key: FINERACT-1893 > URL: https://issues.apache.org/jira/browse/FINERACT-1893 > Project: Apache Fineract > Issue Type: Sub-task >Reporter: Aleksandar Vidakovic >Assignee: Aleksandar Vidakovic >Priority: Major > Fix For: 1.9.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (FINERACT-2009) Upgrade latest framework libs
[ https://issues.apache.org/jira/browse/FINERACT-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic resolved FINERACT-2009. Resolution: Fixed > Upgrade latest framework libs > - > > Key: FINERACT-2009 > URL: https://issues.apache.org/jira/browse/FINERACT-2009 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Aleksandar Vidakovic >Assignee: Aleksandar Vidakovic >Priority: Minor > Fix For: 1.9.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (FINERACT-2009) Upgrade latest framework libs
[ https://issues.apache.org/jira/browse/FINERACT-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic reopened FINERACT-2009: > Upgrade latest framework libs > - > > Key: FINERACT-2009 > URL: https://issues.apache.org/jira/browse/FINERACT-2009 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Aleksandar Vidakovic >Assignee: Aleksandar Vidakovic >Priority: Minor > Fix For: 1.9.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-2022) Type-safe native SQL queries
[ https://issues.apache.org/jira/browse/FINERACT-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-2022: --- Labels: FIPS (was: ) > Type-safe native SQL queries > > > Key: FINERACT-2022 > URL: https://issues.apache.org/jira/browse/FINERACT-2022 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Aleksandar Vidakovic >Priority: Major > Labels: FIPS > Fix For: 1.10.0 > > > h2. Background and Motivation > Fineract initially had only JPA as its storage mechanism. When we moved from > Mifos to the Apache Software Foundation we had to give up Hibernate as the > default/standard JPA implementation and used the Apache sister project > OpenJPA. OpenJPA had a couple of performance and standard compliance related > issues which lead some developers to use plain native SQL queries in their > service implementations. Because MySQL was for a long time the only > configured database in the development environment developers started to > introduce database system dependent query constructs (e. g. date functions). > This was one of the main reasons why Fineract got stuck for a long time with > MySQL 5.7 and for a while we couldn't even upgrade to the latest MySQL 8 > version. Support for PostgreSQL was requested by the community repeatedly > over the years, but couldn't be provided due to the these database dependency > issues. Starting with Fineract 1.6.x we replaced OpenJPA with EclipseLink and > added a thin abstraction layer for database system specific functions which > allowed us to support PostgreSQL. > Nevertheless, we still have a lot (and growing) number of SQL native queries > that are provided as Strings. This makes refactoring at the least a very time > consuming task. Our database compatibility support is very limited (only > specific functions) and as we wrote the code ourselves we have an additional > burden to maintain it. Supporting more database systems (SQL Server, Oracle) > in this setup is not worth the effort. > h2. Target Personas > * developers > * integrators > * BaaS > h2. Goals > * introduce QueryDSL to generate code for type-safe SQL queries > * use QueryDSL also for complex JPA queries > * make sure all repository classes follow Spring Data best practices (aka > remove homegrown boilerplate code and annotations as much as possible) > * implement any unsupported features related to database queries as QueryDSL > extensions/plugins > * automatically generate most/all of the query related code > * avoid/remove all custom "@Query" annotations from repository classes > * avoid/remove all JdbcTemplate use; all queries need to be included > * avoid SQL/OQL queries as much as possible by using Spring Data query > function mapping > h2. Non-Goals > * replace all JPA related code with pure Spring Data JDBC and QueryDSL > h2. Proposed API Changes > h3. Spring Data JPA > Generate OQL DSL with QueryDSL and replace all custom JPA queries (either in > "@Query" annotations and/or in direct use of "EntityManager"). > h3. Spring Data JDBC > Generate SQL DSL with QueryDSL and replace all (String based) SQL queries > (either in "@Query" annotations and/or in direct use of "JdbcTemplate"). > h3. Business logic services > Avoid all direct use of JdbcTemplate or EntityManager. Make sure all query > related data is contained only in repository classes. Optional: enforce this > as a architecture rule with ArchUnit. > h2. Risks > Effectively we'll have three different database abstraction mechanisms in > place with with slightly different behavior: > * Spring Data JPA > * Spring Data JDBC > * QueryDSL > It might make sense to eliminate at least one of them in a later iteration. > h2. ETA > We have roughly 50 feature packages/modules with database related > functionality. Some are larger than others; first migrations could take a bit > longer before we establish a routine. A rough calculation would be 3-4 days > per feature/module which results in 150-200 development days or about 6 > months to finish this task. It might make sense to introduce specific unit > tests to ensure that we don't introduce regressions. This could add some > overhead (maybe 1 day) to the initial estimate. > h2. Diagrams > TBD > h4. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-2022) Type-safe native SQL queries
[ https://issues.apache.org/jira/browse/FINERACT-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-2022: --- Description: h2. Background and Motivation Fineract initially had only JPA as its storage mechanism. When we moved from Mifos to the Apache Software Foundation we had to give up Hibernate as the default/standard JPA implementation and used the Apache sister project OpenJPA. OpenJPA had a couple of performance and standard compliance related issues which lead some developers to use plain native SQL queries in their service implementations. Because MySQL was for a long time the only configured database in the development environment developers started to introduce database system dependent query constructs (e. g. date functions). This was one of the main reasons why Fineract got stuck for a long time with MySQL 5.7 and for a while we couldn't even upgrade to the latest MySQL 8 version. Support for PostgreSQL was requested by the community repeatedly over the years, but couldn't be provided due to the these database dependency issues. Starting with Fineract 1.6.x we replaced OpenJPA with EclipseLink and added a thin abstraction layer for database system specific functions which allowed us to support PostgreSQL. Nevertheless, we still have a lot (and growing) number of SQL native queries that are provided as Strings. This makes refactoring at the least a very time consuming task. Our database compatibility support is very limited (only specific functions) and as we wrote the code ourselves we have an additional burden to maintain it. Supporting more database systems (SQL Server, Oracle) in this setup is not worth the effort. h2. Target Personas * developers * integrators * BaaS h2. Goals * introduce QueryDSL to generate code for type-safe SQL queries * use QueryDSL also for complex JPA queries * make sure all repository classes follow Spring Data best practices (aka remove homegrown boilerplate code and annotations as much as possible) * implement any unsupported features related to database queries as QueryDSL extensions/plugins * automatically generate most/all of the query related code * avoid/remove all custom "@Query" annotations from repository classes * avoid/remove all JdbcTemplate use; all queries need to be included * avoid SQL/OQL queries as much as possible by using Spring Data query function mapping h2. Non-Goals * replace all JPA related code with pure Spring Data JDBC and QueryDSL h2. Proposed API Changes h3. Spring Data JPA Generate OQL DSL with QueryDSL and replace all custom JPA queries (either in "@Query" annotations and/or in direct use of "EntityManager"). h3. Spring Data JDBC Generate SQL DSL with QueryDSL and replace all (String based) SQL queries (either in "@Query" annotations and/or in direct use of "JdbcTemplate"). h3. Business logic services Avoid all direct use of JdbcTemplate or EntityManager. Make sure all query related data is contained only in repository classes. Optional: enforce this as a architecture rule with ArchUnit. h2. Risks Effectively we'll have three different database abstraction mechanisms in place with with slightly different behavior: * Spring Data JPA * Spring Data JDBC * QueryDSL It might make sense to eliminate at least one of them in a later iteration. h2. ETA We have roughly 50 feature packages/modules with database related functionality. Some are larger than others; first migrations could take a bit longer before we establish a routine. A rough calculation would be 3-4 days per feature/module which results in 150-200 development days or about 6 months to finish this task. It might make sense to introduce specific unit tests to ensure that we don't introduce regressions. This could add some overhead (maybe 1 day) to the initial estimate. h2. Diagrams TBD h4. > Type-safe native SQL queries > > > Key: FINERACT-2022 > URL: https://issues.apache.org/jira/browse/FINERACT-2022 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Aleksandar Vidakovic >Priority: Major > Fix For: 1.10.0 > > > h2. Background and Motivation > Fineract initially had only JPA as its storage mechanism. When we moved from > Mifos to the Apache Software Foundation we had to give up Hibernate as the > default/standard JPA implementation and used the Apache sister project > OpenJPA. OpenJPA had a couple of performance and standard compliance related > issues which lead some developers to use plain native SQL queries in their > service implementations. Because MySQL was for a long time the only > configured database in the development environment developers started to > introduce database system dependent query constructs (e. g. date functions). > This was one of the main
[jira] [Created] (FINERACT-2022) Type-safe native SQL queries
Aleksandar Vidakovic created FINERACT-2022: -- Summary: Type-safe native SQL queries Key: FINERACT-2022 URL: https://issues.apache.org/jira/browse/FINERACT-2022 Project: Apache Fineract Issue Type: Improvement Reporter: Aleksandar Vidakovic Fix For: 1.10.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-2021) Type-safe REST API layer
[ https://issues.apache.org/jira/browse/FINERACT-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-2021: --- Description: h2. Background and Motivation Fineract initial planning and code architecture predates some of the frameworks and current best practices. That and the fact that we have some not so easy to parse data structures led to the decision to use Google's GSON library and parse incoming API requests manually and to capture all request bodies in String variables. The downside of doing this decision are: * by capturing all incoming request bodies in Strings we lose all type information * we need to manually reintroduce types by creating dummy classes that are solely there to create an OpenAPI descriptor * it is easy to introduce bugs while refactoring, because non of the refactoring tools in any of the IDEs can help * we have to maintain a lot of "magic" Strings to poke into the JSON data structures (again, no type-safety) * we have a lot of boilerplate code for manual JSON parsing that we have to maintain (rough estimate 10-15% of the entire code base) * because the JSON parsing is so tedious and time consuming a couple of developers decided to skip the layered architecture rules; and with that they tied the REST API layer to the business logic/service layer (not a good practice); the business logic should not contain any information about how and in which format we exchange API requests h2. Target Personas * developers * integrators * BaaS h2. Goals * migrate current JAX-RS REST resource classes to Spring's Web MVC * use Spring Boot's first class integration of Jackson for JSON parsing * get rid of entire manual JSON code base (including the use of GSON) * handle difficult/non-standard data structures with Jackson Serializer and Deserializer implementations * all incoming and outgoing API requests need to be mapped to proper Java classes in packages "data" * all business logic services need to have "data" classes as input and output parameters * remove all JSON related input and output parameters from business logic services * remove all dummy/helper classes related to OpenAPI descriptor generation * clear separation between data and domain/entity classes * domain classes should be only used internal to respective business logic service and not leak outside of its package/feature/module * use MapStruct ([https://mapstruct.org/)] to generate as much mapping code as possible without manual intervention (mappers should only be used internal to business logic services) * use validation annotations on data classes to delegate as much as possible to Java validation framework instead of doing our own boilerplate "if-then-else" code * keep REST API backwards compatibility with version 1.9.0 h2. Non-Goals * change/improve REST API structure * move all current RESTeasy based integration tests to Spring MVC's JUnit test support (separate project/pull request/ticket) h2. Proposed API Changes h3. JAX-RS REST resource classes Move all JAX-RS REST resource classes to Spring Web MVC controllers (with all annotations etc.). It might be possible to use OpenRewrite to automate part of this work (there is a module for refactoring JAX-RS to Spring Web MVC. This allows us to take advantage of first class support for JUnit like testing in Spring (replacing our unmaintainable integration tests... which lack themselves type safety). h3. REST controller input and output parameters Make sure all endpoint receive and generate type safe data. All input/output parameter related data structures should reside in "data" packages. h3. Business logic services All input and output parameters in the business logic layer need to be mapped to "data" classes. Internal domain/entity classes should not leak outside of the business logic classes. h3. Data/DTO to domain/entity mapping All mapping between data and domain classes should be mapped with MapStruct. The developers only have to provide annotations (if necessary) and automate the mapping code generation with MapStruct. h2. Risks Migrating from JAX-RS to Spring Web MVC and re-introduce type-safety will be an ongoing effort over a couple of weeks/months. During that time we'll have 2 different frameworks handling the API requests. There might be subtle changes in the behavior. h2. ETA We have roughly 50 feature packages/modules with REST API resource classes. Some are larger than others; first migrations could take a bit longer before we establish a routine. A rough calculation would be 3-4 days per feature/module which results in 150-200 development days or about 6 months to finish this task. h2. Diagrams TBD was: h2. Background and Motivation Fineract initial planning and code architecture predates some of the frameworks and current best practices. That and the fact that we have some
[jira] [Updated] (FINERACT-2021) Type-safe REST API layer
[ https://issues.apache.org/jira/browse/FINERACT-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-2021: --- Labels: FIPS (was: ) > Type-safe REST API layer > > > Key: FINERACT-2021 > URL: https://issues.apache.org/jira/browse/FINERACT-2021 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Aleksandar Vidakovic >Priority: Major > Labels: FIPS > Fix For: 1.10.0 > > > h2. Background and Motivation > Fineract initial planning and code architecture predates some of the > frameworks and current best practices. That and the fact that we have some > not so easy to parse data structures led to the decision to use Google's GSON > library and parse incoming API requests manually and to capture all request > bodies in String variables. The downside of doing this decision are: > * by capturing all incoming request bodies in Strings we lose all type > information > * we need to manually reintroduce types by creating dummy classes that are > solely there to create an OpenAPI descriptor > * it is easy to introduce bugs while refactoring, because non of the > refactoring tools in any of the IDEs can help > * we have to maintain a lot of "magic" Strings to poke into the JSON data > structures (again, no type-safety) > * we have a lot of boilerplate code for manual JSON parsing that we have to > maintain (rough estimate 10-15% of the entire code base) > * because the JSON parsing is so tedious and time consuming a couple of > developers decided to skip the layered architecture rules; and with that they > tied the REST API layer to the business logic/service layer (not a good > practice); the business logic should not contain any information about how > and in which format we exchange API requests > h2. Target Personas > * developers > * integrators > * BaaS > h2. Goals > * migrate current JAX-RS REST resource classes to Spring's Web MVC > * use Spring Boot's first class integration of Jackson for JSON parsing > * get rid of entire manual JSON code base (including the use of GSON) > * handle difficult/non-standard data structures with Jackson Serializer and > Deserializer implementations > * all incoming and outgoing API requests need to be mapped to proper Java > classes in packages "data" > * all business logic services need to have "data" classes as input and > output parameters > * remove all JSON related input and output parameters from business logic > services > * remove all dummy/helper classes related to OpenAPI descriptor generation > * clear separation between data and domain/entity classes > * domain classes should be only used internal to respective business logic > service and not leak outside of its package/feature/module > * use MapStruct ([https://mapstruct.org/)] to generate as much mapping code > as possible without manual intervention (mappers should only be used internal > to business logic services) > * use validation annotations on data classes to delegate as much as possible > to Java validation framework instead of doing our own boilerplate > "if-then-else" code > * keep REST API backwards compatibility with version 1.9.0 > h2. Non-Goals > * change/improve REST API structure > * move all current RESTeasy based integration tests to Spring MVC's JUnit > test support (separate project/pull request/ticket) > h2. Proposed API Changes > h3. JAX-RS REST resource classes > Move all JAX-RS REST resource classes to Spring Web MVC controllers (with all > annotations etc.). It might be possible to use OpenRewrite to automate part > of this work (there is a module for refactoring JAX-RS to Spring Web MVC. > This allows us to take advantage of first class support for JUnit like > testing in Spring (replacing our unmaintainable integration tests... which > lack themselves type safety). > h3. REST controller input and output parameters > Make sure all endpoint receive and generate type safe data. All input/output > parameter related data structures should reside in "data" packages. > h3. Business logic services > All input and output parameters in the business logic layer need to be mapped > to "data" classes. Internal domain/entity classes should not leak outside of > the business logic classes. > h3. Data/DTO to domain/entity mapping > All mapping between data and domain classes should be mapped with MapStruct. > The developers only have to provide annotations (if necessary) and automate > the mapping code generation with MapStruct. > h2. Risks > Migrating from JAX-RS to Spring Web MVC and re-introduce type-safety will be > an ongoing effort over a couple of weeks/months. During that time we'll have > 2 different frameworks handling the API requests. There might be subtle > changes in the behavior. >
[jira] [Updated] (FINERACT-2021) Type-safe REST API layer
[ https://issues.apache.org/jira/browse/FINERACT-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-2021: --- Description: h2. Background and Motivation Fineract initial planning and code architecture predates some of the frameworks and current best practices. That and the fact that we have some not so easy to parse data structures led to the decision to use Google's GSON library and parse incoming API requests manually and to capture all request bodies in String variables. The downside of doing this decision are: * by capturing all incoming request bodies in Strings we lose all type information * we need to manually reintroduce types by creating dummy classes that are solely there to create an OpenAPI descriptor * it is easy to introduce bugs while refactoring, because non of the refactoring tools in any of the IDEs can help * we have to maintain a lot of "magic" Strings to poke into the JSON data structures (again, no type-safety) * we have a lot of boilerplate code for manual JSON parsing that we have to maintain (rough estimate 10-15% of the entire code base) * because the JSON parsing is so tedious and time consuming a couple of developers decided to skip the layered architecture rules; and with that they tied the REST API layer to the business logic/service layer (not a good practice); the business logic should not contain any information about how and in which format we exchange API requests h2. Target Personas * developers * integrators * BaaS h2. Goals * migrate current JAX-RS REST resource classes to Spring's Web MVC * use Spring Boot's first class integration of Jackson for JSON parsing * get rid of entire manual JSON code base (including the use of GSON) * handle difficult/non-standard data structures with Jackson Serializer and Deserializer implementations * all incoming and outgoing API requests need to be mapped to proper Java classes in packages "data" * all business logic services need to have "data" classes as input and output parameters * remove all JSON related input and output parameters from business logic services * remove all dummy/helper classes related to OpenAPI descriptor generation * clear separation between data and domain/entity classes * domain classes should be only used internal to respective business logic service and not leak outside of its package/feature/module * use MapStruct ([https://mapstruct.org/)] to generate as much mapping code as possible without manual intervention (mappers should only be used internal to business logic services) * use validation annotations on data classes to delegate as much as possible to Java validation framework instead of doing our own boilerplate "if-then-else" code * keep REST API backwards compatibility with version 1.9.0 h2. Non-Goals * change/improve REST API structure * move all current RESTeasy based integration tests to Spring MVC's JUnit test support (separate project/pull request/ticket) h2. Proposed API Changes h3. JAX-RS REST resource classes Move all JAX-RS REST resource classes to Spring Web MVC controllers (with all annotations etc.). It might be possible to use OpenRewrite to automate part of this work (there is a module for refactoring JAX-RS to Spring Web MVC. This allows us to take advantage of first class support for JUnit like testing in Spring (replacing our unmaintainable integration tests... which lack themselves type safety). h3. REST controller input and output parameters Make sure all endpoint receive and generate type safe data. All input/output parameter related data structures should reside in "data" packages. h3. Business logic services All input and output parameters in the business logic layer need to be mapped to "data" classes. Internal domain/entity classes should not leak outside of the business logic classes. h3. Data/DTO to domain/entity mapping All mapping between data and domain classes should be mapped with MapStruct. The developers only have to provide annotations (if necessary) and automate the mapping code generation with MapStruct. h2. Risks Migrating from JAX-RS to Spring Web MVC and re-introduce type-safety will be an ongoing effort over a couple of weeks/months. During that time we'll have 2 different frameworks handling the API requests. There might be subtle changes in the behavior. h2. ETA We have roughly 50 feature packages/modules with REST API resource classes. Some are larger than others; first migrations could take a bit longer before we establish a routine. A rough calculation would be 3-4 days per feature/module which results in 150-200 development days or about 6 months to finish this task. h2. Diagrams > Type-safe REST API layer > > > Key: FINERACT-2021 > URL: https://issues.apache.org/jira/browse/FINERACT-2021 > Project:
[jira] [Created] (FINERACT-2021) Type-safe REST API layer
Aleksandar Vidakovic created FINERACT-2021: -- Summary: Type-safe REST API layer Key: FINERACT-2021 URL: https://issues.apache.org/jira/browse/FINERACT-2021 Project: Apache Fineract Issue Type: Improvement Reporter: Aleksandar Vidakovic Fix For: 1.10.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-2012) Fineract resource settings
[ https://issues.apache.org/jira/browse/FINERACT-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785982#comment-17785982 ] Aleksandar Vidakovic commented on FINERACT-2012: Thank you [~peter.santa] ... I will take care of this... should arrive soon as a PR. > Fineract resource settings > -- > > Key: FINERACT-2012 > URL: https://issues.apache.org/jira/browse/FINERACT-2012 > Project: Apache Fineract > Issue Type: Bug > Components: Deployment >Reporter: Peter Santa >Assignee: Aleksandar Vidakovic >Priority: Major > Labels: BeanSalad > Fix For: 1.9.0 > > > Currently the build.gradle file for fineract-provider sets some options for > the Java runtime. Among these there are some memory-related options: > '-Xms1G', > '-XX:MinRAMPercentage=25', > '-XX:MaxRAMPercentage=80', > Unfortunately these options can't be easily overwritten via environment > variables, because: > _JAVA_OPTIONS --> this is a non-standard option, not all JVM implementations > necessarily support this (https://bugs.openjdk.org/browse/JDK-4971166), and > instead of _JAVA_OPTIONS, JAVA_TOOL_OPTIONS is recommended > JAVA_TOOL_OPTIONS --> unfrtunately explicitly specified command line > arguments take precedence of values set as part of JAVA_TOOL_OPTIONS, so this > method doesn't work > JDK_TOOL_OPTIONS --> same issue as with JAVA_TOOL_OPTIONS > The best way to approach this would be to not set these memory-related > options (at least not the maximums) during build-time, enabling the usage of > JAVA_TOOL_OPTIONS/JDK_TOOL_OPTIONS. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (FINERACT-2012) Fineract resource settings
[ https://issues.apache.org/jira/browse/FINERACT-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic reassigned FINERACT-2012: -- Assignee: Aleksandar Vidakovic > Fineract resource settings > -- > > Key: FINERACT-2012 > URL: https://issues.apache.org/jira/browse/FINERACT-2012 > Project: Apache Fineract > Issue Type: New Feature > Components: Deployment >Reporter: Peter Santa >Assignee: Aleksandar Vidakovic >Priority: Major > Labels: BeanSalad > Fix For: 1.9.0 > > > Currently the build.gradle file for fineract-provider sets some options for > the Java runtime. Among these there are some memory-related options: > '-Xms1G', > '-XX:MinRAMPercentage=25', > '-XX:MaxRAMPercentage=80', > Unfortunately these options can't be easily overwritten via environment > variables, because: > _JAVA_OPTIONS --> this is a non-standard option, not all JVM implementations > necessarily support this (https://bugs.openjdk.org/browse/JDK-4971166), and > instead of _JAVA_OPTIONS, JAVA_TOOL_OPTIONS is recommended > JAVA_TOOL_OPTIONS --> unfrtunately explicitly specified command line > arguments take precedence of values set as part of JAVA_TOOL_OPTIONS, so this > method doesn't work > JDK_TOOL_OPTIONS --> same issue as with JAVA_TOOL_OPTIONS > The best way to approach this would be to not set these memory-related > options (at least not the maximums) during build-time, enabling the usage of > JAVA_TOOL_OPTIONS/JDK_TOOL_OPTIONS. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-2012) Fineract resource settings
[ https://issues.apache.org/jira/browse/FINERACT-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-2012: --- Issue Type: Bug (was: New Feature) > Fineract resource settings > -- > > Key: FINERACT-2012 > URL: https://issues.apache.org/jira/browse/FINERACT-2012 > Project: Apache Fineract > Issue Type: Bug > Components: Deployment >Reporter: Peter Santa >Assignee: Aleksandar Vidakovic >Priority: Major > Labels: BeanSalad > Fix For: 1.9.0 > > > Currently the build.gradle file for fineract-provider sets some options for > the Java runtime. Among these there are some memory-related options: > '-Xms1G', > '-XX:MinRAMPercentage=25', > '-XX:MaxRAMPercentage=80', > Unfortunately these options can't be easily overwritten via environment > variables, because: > _JAVA_OPTIONS --> this is a non-standard option, not all JVM implementations > necessarily support this (https://bugs.openjdk.org/browse/JDK-4971166), and > instead of _JAVA_OPTIONS, JAVA_TOOL_OPTIONS is recommended > JAVA_TOOL_OPTIONS --> unfrtunately explicitly specified command line > arguments take precedence of values set as part of JAVA_TOOL_OPTIONS, so this > method doesn't work > JDK_TOOL_OPTIONS --> same issue as with JAVA_TOOL_OPTIONS > The best way to approach this would be to not set these memory-related > options (at least not the maximums) during build-time, enabling the usage of > JAVA_TOOL_OPTIONS/JDK_TOOL_OPTIONS. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-670) Transaction 'Notes' should be displayed in summary of transaction
[ https://issues.apache.org/jira/browse/FINERACT-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic updated FINERACT-670: -- Fix Version/s: (was: 1.9.0) > Transaction 'Notes' should be displayed in summary of transaction > - > > Key: FINERACT-670 > URL: https://issues.apache.org/jira/browse/FINERACT-670 > Project: Apache Fineract > Issue Type: Improvement > Components: Loan >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Major > Labels: GSOC, Volunteer, gci, p1 > Fix For: 3.0.0 > > > Whenever we make Transactions like Loan Repayments, we can capture Notes. But > currently, after transaction is done ,these notes can be seen in Loan > Account tab rather than in Transaction Details. This makes it difficult to > determine which transaction the note applied to. > Expected: Notes should be shown in Transaction details page. Likewise, this > notes field should be part of the fields that would get displayed in a > transaction details report. -- This message was sent by Atlassian Jira (v8.20.10#820010)
