[jira] [Created] (FINERACT-2077) Release 1.10 macro ticket
James Dailey created FINERACT-2077: -- Summary: Release 1.10 macro ticket Key: FINERACT-2077 URL: https://issues.apache.org/jira/browse/FINERACT-2077 Project: Apache Fineract Issue Type: Improvement Reporter: James Dailey Assignee: James Dailey Fix For: 1.10.0 This is the ticket for the release 1.10. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-2075) Introduce Lombok to the loanproduct module
[
https://issues.apache.org/jira/browse/FINERACT-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839832#comment-17839832
]
James Dailey commented on FINERACT-2075:
Release manager says: If this is resolved within 72 hrs, by April 25, 2024,
then it will get the tag 1.10, if not I will move it to a future Release tag.
If this ticket is "partly resolved", as part of a larger refactoring, then I
suggest you resolve the ticket and open a new one for after April 25th.
This way we have a closed ticket and contributed PRs that match with a closed
ticket.
> Introduce Lombok to the loanproduct module
> --
>
> Key: FINERACT-2075
> URL: https://issues.apache.org/jira/browse/FINERACT-2075
> Project: Apache Fineract
> Issue Type: Sub-task
>Reporter: Zeyad Nasef
>Priority: Minor
> Fix For: 1.10.0
>
>
> Refactor the classes under the {{loanproduct}} package by introducing some
> lombok annotations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (FINERACT-1164) Docker Hub Images from release branches
[
https://issues.apache.org/jira/browse/FINERACT-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dailey reopened FINERACT-1164:
This issue is back. The build on docker does not work. It has been failing
for the past two + years.
The docker file is not present in the current GitHub Root directory. According
to [Infra@a.o|mailto:Infra@a.o] that it the problem.
I'll go back in the history to find the old docker file but I suspect that some
of the setup has changed. Does anyone want to take this ticket?
This needs to be built directly from Apache Fineract GitHub. (I realize this
does not allow the Mifos front end to be included, but that is not the job of
the project.)
> Docker Hub Images from release branches
> ---
>
> Key: FINERACT-1164
> URL: https://issues.apache.org/jira/browse/FINERACT-1164
> Project: Apache Fineract
> Issue Type: Improvement
>Reporter: Michael Vorburger
>Assignee: James Dailey
>Priority: Major
> Fix For: 1.9.0
>
>
> [https://hub.docker.com/r/apache/fineract] currently builds from the latest
> code on the {{develop}} branch.
> Upon announcing the 1.4.0 release on the mailing list, someone suggested that
> it could be nice to have to distribute releases on Docker Hub as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (FINERACT-1164) Docker Hub Images from release branches
[
https://issues.apache.org/jira/browse/FINERACT-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dailey reassigned FINERACT-1164:
--
Assignee: James Dailey (was: Aleksandar Vidakovic)
> Docker Hub Images from release branches
> ---
>
> Key: FINERACT-1164
> URL: https://issues.apache.org/jira/browse/FINERACT-1164
> Project: Apache Fineract
> Issue Type: Improvement
>Reporter: Michael Vorburger
>Assignee: James Dailey
>Priority: Major
> Fix For: 1.9.0
>
>
> [https://hub.docker.com/r/apache/fineract] currently builds from the latest
> code on the {{develop}} branch.
> Upon announcing the 1.4.0 release on the mailing list, someone suggested that
> it could be nice to have to distribute releases on Docker Hub as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FINERACT-2020) loan account summary data in clients account api should contain currency
[ https://issues.apache.org/jira/browse/FINERACT-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805320#comment-17805320 ] James Dailey commented on FINERACT-2020: You can take this to the listserv and try to get some response. Include a link to this ticket and explain. But, for your awareness...This is a volunteer run project and we don't respond to all tickets. The most I can say is "Perhaps this belongs on the roadmap for 2024". If you have a suggested PR for this, then you can propose that once you've introduced the idea on the listserv. I'm assuming this is for version 1.8.4 as you mentioned that in the "affects". Are you pulling from Dev to see the latest? This will not be fixed in 1.84 which is already released, and will not be fixed in 1.9 which is undergoing voting for release now. It could make it into 1.10 if you make it happen. Please stop the multiple entries in the ticket. > loan account summary data in clients account api should contain currency > -- > > Key: FINERACT-2020 > URL: https://issues.apache.org/jira/browse/FINERACT-2020 > Project: Apache Fineract > Issue Type: Improvement > Components: Loan >Affects Versions: 1.8.4 >Reporter: Udo Bassey >Priority: Minor > Labels: easyfix > Fix For: 1.10.0 > > Attachments: Loan account summary without currency.png, > Loan_account_summary_data.png, Savings_account_summary_data.png, > image-2024-01-01-10-35-21-683.png > > Original Estimate: 168h > Remaining Estimate: 168h > > We want the loan account summary data to contain currency as we will like to > know the currencies tied to different loan products during set up. > The client account endpoint > [https://baseurl/fineract-provider/api/v1/clients/23/accounts] returns a > payload containing both savings and loan account, the savings account summary > contains currency while the loan account summary does not contain currency. > The aim is to replicate what already exist on the savings account summary for > the loan account summary by bringing in currency. > Attached is the response payload for savings account with currency > !Savings_account_summary_data.png! > Below is the response payload for a loan account without currency > !Loan account summary without currency.png! > And here is a sample response of expected response for loan accounts with > currency field included > !Loan_account_summary_data.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-2020) loan account summary data in clients account api should contain currency
[ https://issues.apache.org/jira/browse/FINERACT-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dailey updated FINERACT-2020: --- Fix Version/s: 1.10.0 (was: 1.8.4) > loan account summary data in clients account api should contain currency > -- > > Key: FINERACT-2020 > URL: https://issues.apache.org/jira/browse/FINERACT-2020 > Project: Apache Fineract > Issue Type: Improvement > Components: Loan >Affects Versions: 1.8.4 >Reporter: Udo Bassey >Priority: Minor > Labels: easyfix > Fix For: 1.10.0 > > Attachments: Loan account summary without currency.png, > Loan_account_summary_data.png, Savings_account_summary_data.png, > image-2024-01-01-10-35-21-683.png > > Original Estimate: 168h > Remaining Estimate: 168h > > We want the loan account summary data to contain currency as we will like to > know the currencies tied to different loan products during set up. > The client account endpoint > [https://baseurl/fineract-provider/api/v1/clients/23/accounts] returns a > payload containing both savings and loan account, the savings account summary > contains currency while the loan account summary does not contain currency. > The aim is to replicate what already exist on the savings account summary for > the loan account summary by bringing in currency. > Attached is the response payload for savings account with currency > !Savings_account_summary_data.png! > Below is the response payload for a loan account without currency > !Loan account summary without currency.png! > And here is a sample response of expected response for loan accounts with > currency field included > !Loan_account_summary_data.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-2020) loan account summary data should contain currency
[ https://issues.apache.org/jira/browse/FINERACT-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792973#comment-17792973 ] James Dailey commented on FINERACT-2020: h3. *Please do explain what you are trying to do. * For example, you could write a test that FAILS because the functionality isn't there. Then anyone on the project could see what you mean. But, if you have a UI issue - then that doesn't belong here. If you have struggled with the configuration documentation, then propose that the documentation be improved and once you have figured that out, write it down and send it back as a contribution to the project. If this is truly a code issue, and you have an easyfix to propose, then place some ideas in the ticket so that we have an idea what you plan. example: I plan to change the API return for Account Summary API to return the value in the database for the currency code or, I plan to add a column to a specific database table for account currency > loan account summary data should contain currency > --- > > Key: FINERACT-2020 > URL: https://issues.apache.org/jira/browse/FINERACT-2020 > Project: Apache Fineract > Issue Type: Improvement > Components: Loan >Affects Versions: 1.8.4 >Reporter: Udo Bassey >Priority: Major > Labels: easyfix > Fix For: 1.8.4 > > Original Estimate: 168h > Remaining Estimate: 168h > > We want the loan account summary data to contain currency as we will like to > know the currencies tied to different loan products during set up. -- 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 ] James Dailey updated FINERACT-1917: --- Description: 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 was: 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 1912 1943 1910 1939 1931 1938 1911 1915 1916 1917 1831 1921 1929 1909 webapp: 1721 1727 1726 1722 > 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.9.0, 1.8.4 > > > 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-1917) Major improvement to Savings Account
[ https://issues.apache.org/jira/browse/FINERACT-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dailey updated FINERACT-1917: --- Description: 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 1912 1943 1910 1939 1931 1938 1911 1915 1916 1917 1831 1921 1929 1909 webapp: 1721 1727 1726 1722 was: 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 1751 1912 1943 1910 1939 1931 1938 1911 1915 1916 1917 1831 webapp: 1721 1727 1726 1722 > 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.9.0, 1.8.4 > > > 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 > 1912 > 1943 > 1910 > 1939 > 1931 > 1938 > 1911 > 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-1917) Major improvement to Savings Account
[ https://issues.apache.org/jira/browse/FINERACT-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dailey updated FINERACT-1917: --- Description: 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 1751 1912 1943 1910 1939 1931 1938 1911 1915 1916 1917 1831 webapp: 1721 1727 1726 1722 was: 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. > 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.9.0, 1.8.4 > > > 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 > 1751 > 1912 > 1943 > 1910 > 1939 > 1931 > 1938 > 1911 > 1915 > 1916 > 1917 > 1831 > webapp: > 1721 > 1727 > 1726 > 1722 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1911) Assign Data Table to Transaction (Savings)
[
https://issues.apache.org/jira/browse/FINERACT-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17732603#comment-17732603
]
James Dailey commented on FINERACT-1911:
Peter - I think Bharat makes a good point here in that the data tables were not
initially designed to be used in this way. IF we get into the design here and
find that this approach isn't useful we should instead go back to the
requirement, which is to have additional and flexible fields for the
transaction record.
If that requires a new thing, under the hood, that should be surfaced in this
ticket.
[~mkkor] please identify issues with the approach we are taking or if it can be
done according to Peter's design spec here.
> Assign Data Table to Transaction (Savings)
> --
>
> Key: FINERACT-1911
> URL: https://issues.apache.org/jira/browse/FINERACT-1911
> Project: Apache Fineract
> Issue Type: New Feature
> Components: Data Tables
>Reporter: Peter Santa
>Priority: Major
> Labels: BeanSalad
>
> h1. Background
> Currently data tables can be assigned to several entity types, but
> transaction is not an option.
> h1. Goal
> The context is mainly Transactions of {*}Saving Accounts{*}, but it would be
> great to implement the feature generally.
> The goal would be to make it possible to
> * {*}assign data table to transactions{*}, and
> * support multi-row and single-row tables - as it is already supported for
> data tables that could be assigned to other entities.
> h1. Acceptance Criteria
> * it is supported to assign *data tables to Transaction entities* of - at
> least - savings accounts, and the solution fits into the current data table
> conception
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (FINERACT-1910) Data Table query - Advanced
[
https://issues.apache.org/jira/browse/FINERACT-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dailey reassigned FINERACT-1910:
--
Assignee: (was: James Dailey)
> Data Table query - Advanced
> ---
>
> Key: FINERACT-1910
> URL: https://issues.apache.org/jira/browse/FINERACT-1910
> Project: Apache Fineract
> Issue Type: New Feature
> Components: Data Tables
>Reporter: Peter Santa
>Priority: Critical
> Labels: BeanSalad
> Attachments: dataTableAdvancedFilteringExample.txt
>
>
> h1. Background
> FINERACT-1747
> h1. Goal
> Have the querying possibilities - that have been developed with FINERACT-1747
> - extended with the following features:
> * pagination - similarly to several Fineract API endpoints
> * sorting based on given attribute
> * filter for closed (greather-than-or-equal, less-than-or-equal) interval in
> case of the following typed fields:
> ** date
> ** date and time
> ** number
> ** decimal
> ** string/text that can be parsed to numeric
> * contains search in string and text fields
> * exact match for string and text fields
> The filtering parameters should be applied with "AND" relation.
> h1. Solution Concept
> Have the solution concept aligned between
> * FINERACT-1910
> * FINERACT-1912
> * FINERACT-1915
> If multiple columns would be used as column filter, it is advisable not to
> put this number of query parameters in the url, but in the body, like
> graphql. With this, a request would look like:
> h3. URL
> GET
> {{{}url{}}}/datatables/{{{}dataTableId{}}}/query?resultColumns=column3,column6,column4=0=10=desc=transaction_date
> h3. Body
> See the attached [^dataTableAdvancedFilteringExample.txt].
> The filtering parameters should be applied with "AND" relation.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (FINERACT-1910) Data Table query - Advanced
[
https://issues.apache.org/jira/browse/FINERACT-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dailey reassigned FINERACT-1910:
--
Assignee: James Dailey (was: Mihaly Dallos)
> Data Table query - Advanced
> ---
>
> Key: FINERACT-1910
> URL: https://issues.apache.org/jira/browse/FINERACT-1910
> Project: Apache Fineract
> Issue Type: New Feature
> Components: Data Tables
>Reporter: Peter Santa
>Assignee: James Dailey
>Priority: Critical
> Labels: BeanSalad
> Attachments: dataTableAdvancedFilteringExample.txt
>
>
> h1. Background
> FINERACT-1747
> h1. Goal
> Have the querying possibilities - that have been developed with FINERACT-1747
> - extended with the following features:
> * pagination - similarly to several Fineract API endpoints
> * sorting based on given attribute
> * filter for closed (greather-than-or-equal, less-than-or-equal) interval in
> case of the following typed fields:
> ** date
> ** date and time
> ** number
> ** decimal
> ** string/text that can be parsed to numeric
> * contains search in string and text fields
> * exact match for string and text fields
> The filtering parameters should be applied with "AND" relation.
> h1. Solution Concept
> Have the solution concept aligned between
> * FINERACT-1910
> * FINERACT-1912
> * FINERACT-1915
> If multiple columns would be used as column filter, it is advisable not to
> put this number of query parameters in the url, but in the body, like
> graphql. With this, a request would look like:
> h3. URL
> GET
> {{{}url{}}}/datatables/{{{}dataTableId{}}}/query?resultColumns=column3,column6,column4=0=10=desc=transaction_date
> h3. Body
> See the attached [^dataTableAdvancedFilteringExample.txt].
> The filtering parameters should be applied with "AND" relation.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FINERACT-1917) Major improvement to Savings Account
[ https://issues.apache.org/jira/browse/FINERACT-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17730249#comment-17730249 ] James Dailey commented on FINERACT-1917: Rob - yes, this code is not well labeled and the concept is essentially a “current account”. A savings account could be seen as a current account w some limitations like number of free withdrawals per month. Savings account and current accounts also can offer interest. Both or considered liabilities of the Bank, but savings often have additional regulations and compliance reporting. > 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.9.0, 1.8.4 > > > 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. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (FINERACT-1912) Transaction query - Advanced
[
https://issues.apache.org/jira/browse/FINERACT-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dailey reassigned FINERACT-1912:
--
Assignee: James Dailey (was: Mihaly Dallos)
> Transaction query - Advanced
>
>
> Key: FINERACT-1912
> URL: https://issues.apache.org/jira/browse/FINERACT-1912
> Project: Apache Fineract
> Issue Type: New Feature
> Components: Savings
>Reporter: Peter Santa
>Assignee: James Dailey
>Priority: Major
> Labels: BeanSalad
>
> h1. Background
> Currently transactions of a Saving Account cannot be filtered - either all of
> them are in the response (using ...?associations=all), or none of them.
> Pagination and sorting is not supported.
> h1. Goal
> For Transactions related to - at least - Savings Account, support having:
> * pagination - following the concept in Fineract, implemented already for
> other entities
> * sorting - following the concept in Fineract, implemented already for other
> entities
> * filtering for
> ** transaction date:
> *** greather-than-or-equal
> *** less-than-or-equal
> ** amount
> *** greather-than-or-equal
> *** less-than-or-equal
> ** deposit/withdraw
> ** externalId - if FINERACT-1760 is already implemented
> The filtering parameters should be applied with "AND" relation.
> The response should have the transaction details on a similar way, as it is
> in the transactions array of:
> {{{}{}}}{color:#212121}/savingsaccounts/<{color}{{{}account_id>{}}}{color:#212121}?associations=all{color}
> h1. Solution Concept
> Have the solution concept aligned between
> * FINERACT-1910
> * FINERACT-1912
> * FINERACT-1915
> The API should support passing the required parameters.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (FINERACT-1917) Major improvement to Savings Account
[ https://issues.apache.org/jira/browse/FINERACT-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dailey reassigned FINERACT-1917: -- Assignee: James Dailey > 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.9.0, 1.8.4 > > > 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. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1908) Modular Security Architecture
[
https://issues.apache.org/jira/browse/FINERACT-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17713660#comment-17713660
]
James Dailey commented on FINERACT-1908:
Let's discuss this on the listserv. And, let's also consider the broader
market conditions and solutions.
Let's consider Spring Authentication:
https://www.baeldung.com/spring-security-oauth-auth-server
> Modular Security Architecture
> -
>
> Key: FINERACT-1908
> URL: https://issues.apache.org/jira/browse/FINERACT-1908
> Project: Apache Fineract
> Issue Type: Improvement
>Reporter: Aleksandar Vidakovic
>Assignee: Aleksandar Vidakovic
>Priority: Major
> Labels: FIPS
> Fix For: 1.9.0
>
> Attachments: FIPS-0001.pdf, image (9).png
>
>
> Background and Motivation
>
> Our current security architecture is based on a example in Spring Security’s
> documentation and implemented on top of JDBC. For a long time we’ve only
> supported basic authentication which was later complemented with a homegrown
> OAuth implementation and another module for one time passwords. On the
> authorization side we support a straight forward RBAC (role based access
> control) model again implemented on top of JDBC. This approach worked for
> quite a while, but end users and integrators wish a more flexible solution.
> Effectively, we are forcing users to adapt to our current security model. In
> most cases they have already existing security infrastructure (e.g.
> ActiveDirectory/LDAP for user info storage and role assignments) and would
> like to integrate Fineract with it. And last, in some more advanced and more
> complex setups the role/permission based access concept might not be
> sufficient for authorization; sometimes additional information (external to
> Fineract) might be needed for additional evaluation. The current setup makes
> it at the least very hard (if not impossible) to achieve these goals.
>
> h2. Target Personas
>
> * integrators
> * end users
> * BaaS
>
> h2. Goals
>
> * separate the current security infrastructure as much as possible from
> Fineract’s core; i. e. make it a custom module
> * create the OAuth Client aka Keycloak module as a drop-in replacement for
> the current security mechanics
> * delegate everything authentication/authorization related to 3rd party
> libs/frameworks/products/services
> * re-use 3rd party libs/frameworks/products/services user interfaces and
> remove corresponding views (e. g. user management) from Fineract web app
> * as minimal refactoring as possible in the short/mid term
> * keep backwards compatibility for a couple of major releases
> * provide good documentation and/or automated tools for migration
>
> h2. Non-Goals
>
> * Fineract as a standalone identity server
>
> h2. Proposed API Changes
>
> h3. AppUser
>
> Unfortunately this class is both JPA entity class and implements Spring
> Security’s "User" interface. The current dependencies and usage in code is
> not ideal (at least when it’s business logic), but the main challenge is that
> the database table behind this JPA entity is related pretty much all over the
> place via joins.
>
> h3. PlatformUserDetailsService
>
> Ideally this service should not be used directly anymore in Fineract’s core.
>
> h3. OAuth Client Auto Configuration
>
> After years of having multiple competing OAuth packages Spring consolidated
> their efforts in two libraries:
>
> {color:#00}implementation
> "org.springframework.boot:spring-boot-starter-oauth2-client"{color}
> {{implementation
> "org.springframework.boot:spring-boot-starter-oauth2-resource-server"}}
>
> Especially the Keycloak configuration is very easy (3 lines in
> application.properties).
>
> h3. BCrypt Support Module for Keycloak
>
> Unfortunately Keycloak doesn’t support BCrypt hashing for passwords out of
> the box, but BCrypt is widely used in Spring Boot applications and the
> default for Fineract. It’s very easy to create an extension module for
> Keycloak to supprot BCrypt too; that way we can migrate existing user
> accounts out of Fineract’s database tables without forcing everyone to reset
> their passwords. Not a strict technical requirement, but helps to smooth the
> transition.
>
> h3. Open Policy Agent integration
>
> To my knowledge there is no official Spring Security module/support for Open
> Policy Agent. Doesn’t really matter that much, because the communication with
> the OPA server is pretty much handled via one endpoint (again, for Java there
> is no official client, but the implementation is easy). Enforcing the OPA
> rules happens then with a Spring Security Voter. Some more thought needs to
> go into what information we send to OPA. At the least we would need:
> * user
[jira] [Created] (FINERACT-1917) Major improvement to Savings Account
James Dailey created FINERACT-1917: -- Summary: 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 Fix For: 1.9.0, 1.8.4 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. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINCN-355) Fineract CN Release 0.2.0
[ https://issues.apache.org/jira/browse/FINCN-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17686173#comment-17686173 ] James Dailey commented on FINCN-355: I see no blocking issues raised as of Feb 8th, 2023. > Fineract CN Release 0.2.0 > - > > Key: FINCN-355 > URL: https://issues.apache.org/jira/browse/FINCN-355 > Project: Fineract Cloud Native > Issue Type: Task >Reporter: Victor Romero >Assignee: Victor Romero >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1793) mysql docker is giving database connector error and application docker not running when trying to setup
[ https://issues.apache.org/jira/browse/FINERACT-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dailey updated FINERACT-1793: --- Priority: Trivial (was: Blocker) > mysql docker is giving database connector error and application docker not > running when trying to setup > --- > > Key: FINERACT-1793 > URL: https://issues.apache.org/jira/browse/FINERACT-1793 > Project: Apache Fineract > Issue Type: Bug > Components: Deployment >Reporter: mahaboob basha shaik >Priority: Trivial > Labels: #review > > mysql docker is giving database connector error and application docker not > running when trying to setup -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1793) mysql docker is giving database connector error and application docker not running when trying to setup
[ https://issues.apache.org/jira/browse/FINERACT-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648192#comment-17648192 ] James Dailey commented on FINERACT-1793: Without additional information, this ticket will be closed. > mysql docker is giving database connector error and application docker not > running when trying to setup > --- > > Key: FINERACT-1793 > URL: https://issues.apache.org/jira/browse/FINERACT-1793 > Project: Apache Fineract > Issue Type: Bug > Components: Deployment >Reporter: mahaboob basha shaik >Priority: Blocker > Labels: #review > > mysql docker is giving database connector error and application docker not > running when trying to setup -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1798) Extension point: command processing service
[ https://issues.apache.org/jira/browse/FINERACT-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17632007#comment-17632007 ] James Dailey commented on FINERACT-1798: Aleks - When implementing this, please ensure we are looking at security aspects - additional command processing suggests to me a new potential route for attack. At a very high level commands should have isolated capability. Workflow enhancements within the application seem like a nice to have. Would it make more sense to have this external to the application? > Extension point: command processing service > --- > > Key: FINERACT-1798 > URL: https://issues.apache.org/jira/browse/FINERACT-1798 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Aleksandar Vidakovic >Assignee: Aleksandar Vidakovic >Priority: Major > Fix For: 1.9.0 > > > Make the current - synchronous - command processing service replaceable. > Provide an example implementation in custom modules based on Apache Camel + > LMAX disruptor routes. Provide enough documentation to enable users to > implement their own command processing (could by a way to integrate workflow > engines). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-1793) mysql docker is giving database connector error and application docker not running when trying to setup
[ https://issues.apache.org/jira/browse/FINERACT-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dailey updated FINERACT-1793: --- Labels: #review (was: ) > mysql docker is giving database connector error and application docker not > running when trying to setup > --- > > Key: FINERACT-1793 > URL: https://issues.apache.org/jira/browse/FINERACT-1793 > Project: Apache Fineract > Issue Type: Bug > Components: Deployment >Reporter: mahaboob basha shaik >Priority: Blocker > Labels: #review > > mysql docker is giving database connector error and application docker not > running when trying to setup -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1793) mysql docker is giving database connector error and application docker not running when trying to setup
[ https://issues.apache.org/jira/browse/FINERACT-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17631905#comment-17631905 ] James Dailey commented on FINERACT-1793: This ticket is not sufficiently detailed. Please provide full details of version, development environment, and steps a dev could take to reproduce the error in their environment. Tickets without detail as to which versions are effected, and which development or run time environment are involved, quickly get stale on our Jira. As discussed on list we are removing stale tickets and keeping only ticket about the most recent release, or that are aimed at fixing a problem in a recent release as part of a patch process. Those using older versions are encouraged to upgrade to more recent versions. > mysql docker is giving database connector error and application docker not > running when trying to setup > --- > > Key: FINERACT-1793 > URL: https://issues.apache.org/jira/browse/FINERACT-1793 > Project: Apache Fineract > Issue Type: Bug > Components: Deployment >Reporter: mahaboob basha shaik >Priority: Blocker > Labels: #review > > mysql docker is giving database connector error and application docker not > running when trying to setup -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (FINERACT-1799) Release Apache Fineract 1.7.1
[ https://issues.apache.org/jira/browse/FINERACT-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dailey closed FINERACT-1799. -- Resolution: Won't Fix Please hold off. This needs to be coordinated with dev and release processes. Please work with the release manager. > Release Apache Fineract 1.7.1 > - > > Key: FINERACT-1799 > URL: https://issues.apache.org/jira/browse/FINERACT-1799 > Project: Apache Fineract > Issue Type: Task >Reporter: Manoj Mohanan >Assignee: James Dailey >Priority: Major > > Umbrella issue for tracking all activity for this Fineract release 1.7.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1799) Release Apache Fineract 1.7.1
[ https://issues.apache.org/jira/browse/FINERACT-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17631757#comment-17631757 ] James Dailey commented on FINERACT-1799: I am closing this down to make it clear to devs that this is not yet consistent with the development practices at Fineract. If we can bring this to the next release and/or fit within the patch concept, we can bring this back. It is creating confusion. > Release Apache Fineract 1.7.1 > - > > Key: FINERACT-1799 > URL: https://issues.apache.org/jira/browse/FINERACT-1799 > Project: Apache Fineract > Issue Type: Task >Reporter: Manoj Mohanan >Assignee: James Dailey >Priority: Major > > Umbrella issue for tracking all activity for this Fineract release 1.7.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (FINERACT-1799) Release Apache Fineract 1.7.1
[ https://issues.apache.org/jira/browse/FINERACT-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dailey reassigned FINERACT-1799: -- Assignee: James Dailey (was: Manoj Mohanan) > Release Apache Fineract 1.7.1 > - > > Key: FINERACT-1799 > URL: https://issues.apache.org/jira/browse/FINERACT-1799 > Project: Apache Fineract > Issue Type: Task >Reporter: Manoj Mohanan >Assignee: James Dailey >Priority: Major > > Umbrella issue for tracking all activity for this Fineract release 1.7.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1253) Publish the result of the built Fineract doc (and JAR & WAR while we're at it?)
[
https://issues.apache.org/jira/browse/FINERACT-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629852#comment-17629852
]
James Dailey commented on FINERACT-1253:
Aleksander - Is this ticket still relevant? You've completed the design and
implementation of an ascii doc generator?
> Publish the result of the built Fineract doc (and JAR & WAR while we're at
> it?)
> ---
>
> Key: FINERACT-1253
> URL: https://issues.apache.org/jira/browse/FINERACT-1253
> Project: Apache Fineract
> Issue Type: New Feature
>Reporter: Michael Vorburger
>Priority: Major
> Labels: Roadmap2022
>
> FINERACT-1191 made me think that it would be great if we could publish the
> result of the built Fineract doc on a site somewhere. Both the PDF and the
> HTM site that Asciidoc presumably builds (I haven't checked it) should be
> "available" somewhere - otherwise that entire effort is not "visible" - which
> would be a shame.
> I'm thinking it could either go to some place like
> https://fineract.apache.org
> or up on https://www.fineract.dev. From a more technical perspective, I guess
> the choices we have is to have it 1. either hosted in a branch of
> https://github.com/apache/fineract, 2. on
> https://github.com/apache/fineract-site (image
> https://fineract.apache.org/docs?), 3. served either from a new Apache Git
> repo (with GitHub pages? Or ASF static page hosting? Need to ask ASF..), 4.
> pushed to a new non-Apache Git repo, 5. no Git repo but just a container with
> static content I can build and run on https://www.fineract.dev as Cloud Run,
> 6. another static CDN.
> We should also make sure that web search crawlers index it by submitting it
> e.g. on G Search Console and have an appropriate robots.txt in it.
> If we do do this, it may be an opportunity to build, keep and HTTP serve the
> {{develop}} version of the JAR & WAR as well while we're at it?
> [~aleks] and [~ptuomola] et al. do chime in.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (FINERACT-1794) Address improvement in file upload APIs
James Dailey created FINERACT-1794: -- Summary: Address improvement in file upload APIs Key: FINERACT-1794 URL: https://issues.apache.org/jira/browse/FINERACT-1794 Project: Apache Fineract Issue Type: Improvement Reporter: James Dailey Let's discuss the necessary steps to improve file uploading. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-232) Ability to Post General Ledger Entries Directly to Customer Account
[ https://issues.apache.org/jira/browse/FINERACT-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dailey updated FINERACT-232: -- Labels: Roadmap2022 functional gsoc large (was: functional gsoc large) > Ability to Post General Ledger Entries Directly to Customer Account > --- > > Key: FINERACT-232 > URL: https://issues.apache.org/jira/browse/FINERACT-232 > Project: Apache Fineract > Issue Type: Improvement > Components: Accounting, Loan, Savings >Reporter: Dayna Harp >Priority: Major > Labels: Roadmap2022, functional, gsoc, large > Attachments: Complete New UI Mock up for Journal Entry Screen.png, > Enhancements for Journal Entry.pdf > > > https://mifosforge.jira.com/browse/MIFOSX-2182 > From MIFOS X: As an accountant, i would like to be able to make a transfer > from a client's account (Savings Account or Loan Account) to a GL Account and > also be able to make transfer from a GL Account (e.g Cash at Hand) to > Client's Account (e.g Savings Account or Loan Account) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-204) Design a small page for cashiers - Teller Cash Management other than the admin user page
[ https://issues.apache.org/jira/browse/FINERACT-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17626273#comment-17626273 ] James Dailey commented on FINERACT-204: --- This has been open for a long time. We're closing this ticket and similar related to Cashier or Teller operations. If there is a group of people wanting to work on this as part of the current roadmap activities (Q4 2022), then please make a note and suggest how to approach the design. One thought is that the core Fineract application should not be involved in cash handling but rather there should be an outside Teller Management and Cashier operational module that connects to the core APIs. This would potentially be an area of new development. > Design a small page for cashiers - Teller Cash Management other than the > admin user page > > > Key: FINERACT-204 > URL: https://issues.apache.org/jira/browse/FINERACT-204 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Ippez Roberts >Priority: Major > > As a cashier, when i have been assigned to a teller, i don't need to go > through the Admin>Organisation>Teller Cash Management menu and further drill > down to select a teller and the select my name as a cashier - Even able to > see other Tellers/cashiers > Its hectic, suppose we have about 10 tellers, how will i know to which teller > i have been assigned? > So when i have been assigned to a teller, there should be user friendly menu > to just the cashier details (page where your have Allocate Cash, Settle Cash, > and View/Print my transactions. That's all for a cashier's page. > Suggestion, maybe during user creation, include "Is Cashier" like what we > have for a "Is Loan Office" such that that page is only accessed when the > flag "Is Cashier" is turned on. > And also when settling Cash, there should be validation of balances check ie. > Allocation Cash+ Cash In - Cash Out = Cash at Hand(real cash with the > cashier) - So there should be provision to enter Cash at Hand -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-200) Separate Current Accounts from Savings Accounts
[ https://issues.apache.org/jira/browse/FINERACT-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dailey updated FINERACT-200: -- Labels: Roadmap2022 gsoc p3 (was: gsoc p3) > Separate Current Accounts from Savings Accounts > --- > > Key: FINERACT-200 > URL: https://issues.apache.org/jira/browse/FINERACT-200 > Project: Apache Fineract > Issue Type: Improvement > Components: Savings >Reporter: Dayna Harp >Priority: Minor > Labels: Roadmap2022, gsoc, p3 > > https://mifosforge.jira.com/browse/MIFOSX-1361 > Current Accounts and Savings accounts are two different category of deposit > products. At least at the User Interface, these should be treated as two > different products. At the platform level, we should have a field that > differentiate these (perhaps m_savings.product.deposit_type_enum and > m_savings_account.account_type_enum) > Savings accounts should not allow overdraft and hence the parameters > associated to overdraft can be defaulted to null. > Current accounts allow overdraft and overdraft limits and charges/interest > for overdrafts. Also they usually have zero interest rate, but we should > retain the interest rate fields for current account. > Fees - should be separated out for current accounts and savings accounts. > Also, need to be evaluated how this will impact savings reports. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-134) Add support for Revolving Line of Credit products
[ https://issues.apache.org/jira/browse/FINERACT-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dailey updated FINERACT-134: -- Labels: Roadmap2022 (was: ) > Add support for Revolving Line of Credit products > - > > Key: FINERACT-134 > URL: https://issues.apache.org/jira/browse/FINERACT-134 > Project: Apache Fineract > Issue Type: New Feature >Reporter: Ed Cable >Priority: Major > Labels: Roadmap2022 > > As part of the Q2 work on Flexible Loan Schedules phase 3, we should explore > supporting a new product for a revolving line of credit. > We have had requests from customer like the Paradigm Project for revolving > lines of credit to purchase non-durable goods like solar cook stoves etc: > http://www.theparadigmproject.org/ > The primary difference between a revolving and non-revolving line of credit > is that repayments on RLOC replenish the available credit balance, becoming > available for borrowing again. See http://goo.gl/0itVoh -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-129) Loan Approval/Disbursal by Amount (Data-Driven Authorization)
[ https://issues.apache.org/jira/browse/FINERACT-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dailey updated FINERACT-129: -- Labels: Roadmap2022 (was: ) > Loan Approval/Disbursal by Amount (Data-Driven Authorization) > - > > Key: FINERACT-129 > URL: https://issues.apache.org/jira/browse/FINERACT-129 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Ed Cable >Priority: Major > Labels: Roadmap2022 > > As reported at https://mifosforge.jira.com/browse/MIFOSX-2649 > In the last three RFPs I have worked on in March 2016, each had a requirement > to define level of authority by amount. > For Example: > * New loan officer may approve and/or disburse loans up to 10,000 > * A seasoned loan officer may approve and/or disburse loans up to 30,000 > * A management level loan officer may approve and/or disburse loans up to > 75,000 > This should be configurable at the user level within the Loan Officer Role. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-91) Add Support for Multi-Currency/Cross-Currency Transactions/Currency Exchange into Fineract
[ https://issues.apache.org/jira/browse/FINERACT-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dailey updated FINERACT-91: - Labels: Roadmap2022 gsoc2016 (was: gsoc2016) > Add Support for Multi-Currency/Cross-Currency Transactions/Currency Exchange > into Fineract > -- > > Key: FINERACT-91 > URL: https://issues.apache.org/jira/browse/FINERACT-91 > Project: Apache Fineract > Issue Type: New Feature >Reporter: Ed Cable >Priority: Major > Labels: Roadmap2022, gsoc2016 > > Many Fineract users operate in multiple currencies either within one country > or across multiple countries. Fineract has basic multi-currency support in > tersm of the ability to support multiple currencies across the organization > and define loan products in specific currencies. Support is needed to > actually track and manage the foreign exchange rate of these currencies. > A couple specs are in place at: > https://mifosforge.jira.com/wiki/display/MIFOSX/Cross-Currency+Transactions > and > https://mifosforge.jira.com/wiki/display/MIFOSX/Currency+Exchange > If you watch this video of a demo Robert did of the FINEM system he built, > you can see the work a partner has done in implementing this feature: > https://www.youtube.com/watch?v=kQXiwDcbqrk -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-832) ATM Connectors
[ https://issues.apache.org/jira/browse/FINERACT-832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dailey updated FINERACT-832: -- Labels: (was: Roadmap2022) > ATM Connectors > -- > > Key: FINERACT-832 > URL: https://issues.apache.org/jira/browse/FINERACT-832 > Project: Apache Fineract > Issue Type: New Feature > Components: System >Affects Versions: 1.3.0 > Environment: FINERACT/MIFOS >Reporter: Saul Barragan >Priority: Trivial > > Thanks for your time, before of nothing,... > > Hello to Who may concern, > > I review the documentation of FINERACT: > [https://cwiki.apache.org/confluence/display/FINERACT/ATM+Connectors] > In specific where is the ATM Connector in the part of features in progress... > This documentation is from 2016. > The question is: Today in the last versión of FINERACT or MIFOS, ATM > Connectors is working? > > Thanks! > > Saul C. A. Barragan Vargas > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-832) ATM Connectors
[ https://issues.apache.org/jira/browse/FINERACT-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17626271#comment-17626271 ] James Dailey commented on FINERACT-832: --- ATM connectors do not belong in the core of Fineract. Rather, ATMs are a payments channel that should pass through the payments hub per our architectural design. > ATM Connectors > -- > > Key: FINERACT-832 > URL: https://issues.apache.org/jira/browse/FINERACT-832 > Project: Apache Fineract > Issue Type: New Feature > Components: System >Affects Versions: 1.3.0 > Environment: FINERACT/MIFOS >Reporter: Saul Barragan >Priority: Trivial > > Thanks for your time, before of nothing,... > > Hello to Who may concern, > > I review the documentation of FINERACT: > [https://cwiki.apache.org/confluence/display/FINERACT/ATM+Connectors] > In specific where is the ATM Connector in the part of features in progress... > This documentation is from 2016. > The question is: Today in the last versión of FINERACT or MIFOS, ATM > Connectors is working? > > Thanks! > > Saul C. A. Barragan Vargas > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-38) Period Close feature where inc & exp booked to retained earnings account
[ https://issues.apache.org/jira/browse/FINERACT-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dailey updated FINERACT-38: - Labels: Roadmap2022 functional (was: functional) > Period Close feature where inc & exp booked to retained earnings account > > > Key: FINERACT-38 > URL: https://issues.apache.org/jira/browse/FINERACT-38 > Project: Apache Fineract > Issue Type: Improvement > Components: Accounting >Reporter: Dayna Harp >Priority: Major > Labels: Roadmap2022, functional > Time Spent: 40m > Remaining Estimate: 0h > > https://mifosforge.jira.com/browse/MIFOSX-2337 > Relates to: https://mifosforge.jira.com/browse/MIFOSX-2288 (see attachments > and narrative) > financial year end to be user definable and to have the full effect of > closing off the year with initialization of the profit and loss account. Year > end process should be run as/when the institution is ready to close their > books and may not necessarily happen exactly > Musoni is implementing and sharing the following: > Ability to close a financial year from an accounting perspective (booking off > income and expense accounts against your retained earnings equity account). > The high-level spec of this feature is: > * When a user performs a financial close period (existing feature) we have > added various parameters to the call that allow you to also book off the > income and expenses generated in that period. > * Once you submit this request the various balances will be pulled out and > the difference between all expenses and income accounts will be booked off > against a (specified) equity account. > * The journal entry that is generated to perform this booking will be stored > with the close period so that it can be reversed again if a close period is > reopened. > * There is a preview/template API endpoint that allows you to preview the > booking that is going to be performed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1729) Overdraft Interest Calculated Wrongly
[ https://issues.apache.org/jira/browse/FINERACT-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17615223#comment-17615223 ] James Dailey commented on FINERACT-1729: Frank - We also need to know what source code or build you are using. The community is prioritizing fixes to releases 1.7 and later as of this date. (10-Oct-2022). If this is in the dev branch on GitHub as of a specific date, also indicate that. The display is of course from the Mifos UI, so the assumption is that the UI is doing the right thing. It may or may not be the case. Can you also verify via API call? > Overdraft Interest Calculated Wrongly > - > > Key: FINERACT-1729 > URL: https://issues.apache.org/jira/browse/FINERACT-1729 > Project: Apache Fineract > Issue Type: Bug >Reporter: Frank Nkuyahaga >Priority: Blocker > Attachments: Screenshot 2022-09-08 at 10.16.51.png > > > *Steps to Reproduce* > # Create a savings account with overdraft setup (say 365% per year which is > approx. 1% per day) > # Make a withdrawal to take the account into overdraft. Backdate this > withdrawal a few days > # Run the interest posting job > # Go back to the account and observe the interest postings > *Expected* > Interest should be posted correctly for all the days since the withdraw date > to the current date. That means, the interest posted on the first day should > affect the end of day balance for the first day and this should be taken into > account when posting interest for the second day and so on. > *Actual* > The overdraft interest amount is wrong and it's the same for all the days. > See attachment. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-12) For Overdue/Due Fee/Int,Principal strategy with variable installment, late repayment is not working as expected
[ https://issues.apache.org/jira/browse/FINERACT-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dailey updated FINERACT-12: - Labels: Volunteer cleanup22 gci gsoc p1 (was: Volunteer gci gsoc p1) > For Overdue/Due Fee/Int,Principal strategy with variable installment, late > repayment is not working as expected > --- > > Key: FINERACT-12 > URL: https://issues.apache.org/jira/browse/FINERACT-12 > Project: Apache Fineract > Issue Type: Bug > Components: Loan >Affects Versions: 1.8.0 >Reporter: Dayna Harp >Priority: Major > Labels: Volunteer, cleanup22, gci, gsoc, p1 > Fix For: 1.9.0 > > > https://mifosforge.jira.com/browse/MIFOSX-2401 > 1. Create loan product with following datasets, > Terms > Terms vary based on loan cycle : false > Principal: 10,000 ( Min: , Max : ) > Number of Repayments: 12 ( Min: , Max) > Repay Every: 1 Months > Nominal Interest Rate: 1 ( Min: , Max) Per month > Minimum days between disbursal and first repayment date > Settings > Amortization Equal installments > Interest Method Declining Balance > Interest Calculation Period Daily > Arrears Tolerance > Repayment Strategy Overdue/Due Fee/Int,Principal > Days in year Actual > Days in month Actual > Principal Threshold (%) for Last Instalment 0 > Allow fixing of the installment amount No > Variable Installments (Min:0 , Max:365) > Interest Recalculation > Recalculate Interest Yes > Advance payments adjustment type Reduce number of installments > Pre-closure interest calculation rule Calculate till pre closure date > Interest recalculation compounding on None > Frequency for recalculate Outstanding Principal Daily > Frequency Interval for recalculation 1 > Frequency Date for recalculation 01 October 2015 > Is Arrears recognization based on original schedule No > 2. Create a client and submit new loan application on 01 October 2015. > 3. Click on More -> Edit repayment schedule in which delete repayment for 01 > November 2015 and click on validate and submit button. > 4. Approve and disburse loan on 01 October 2015. > 5. Make repayment on 15 December 2015. > > In Overdue/Due Fee/Int,Principal repayment strategy one entry on 15 > > December 2015 should get created, which is not getting getting created. > > Interest should get calculated upto 14 December 2015. (Disbursement date 01 > > October 2015 and first repayment is doing on 15 December 2015). > Attachments: https://mifosforge.jira.com/browse/MIFOSX-2401 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-12) For Overdue/Due Fee/Int,Principal strategy with variable installment, late repayment is not working as expected
[ https://issues.apache.org/jira/browse/FINERACT-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17603634#comment-17603634 ] James Dailey commented on FINERACT-12: -- Archiving this ticket for clean up. > For Overdue/Due Fee/Int,Principal strategy with variable installment, late > repayment is not working as expected > --- > > Key: FINERACT-12 > URL: https://issues.apache.org/jira/browse/FINERACT-12 > Project: Apache Fineract > Issue Type: Bug > Components: Loan >Affects Versions: 1.8.0 >Reporter: Dayna Harp >Priority: Major > Labels: Volunteer, gci, gsoc, p1 > Fix For: 1.9.0 > > > https://mifosforge.jira.com/browse/MIFOSX-2401 > 1. Create loan product with following datasets, > Terms > Terms vary based on loan cycle : false > Principal: 10,000 ( Min: , Max : ) > Number of Repayments: 12 ( Min: , Max) > Repay Every: 1 Months > Nominal Interest Rate: 1 ( Min: , Max) Per month > Minimum days between disbursal and first repayment date > Settings > Amortization Equal installments > Interest Method Declining Balance > Interest Calculation Period Daily > Arrears Tolerance > Repayment Strategy Overdue/Due Fee/Int,Principal > Days in year Actual > Days in month Actual > Principal Threshold (%) for Last Instalment 0 > Allow fixing of the installment amount No > Variable Installments (Min:0 , Max:365) > Interest Recalculation > Recalculate Interest Yes > Advance payments adjustment type Reduce number of installments > Pre-closure interest calculation rule Calculate till pre closure date > Interest recalculation compounding on None > Frequency for recalculate Outstanding Principal Daily > Frequency Interval for recalculation 1 > Frequency Date for recalculation 01 October 2015 > Is Arrears recognization based on original schedule No > 2. Create a client and submit new loan application on 01 October 2015. > 3. Click on More -> Edit repayment schedule in which delete repayment for 01 > November 2015 and click on validate and submit button. > 4. Approve and disburse loan on 01 October 2015. > 5. Make repayment on 15 December 2015. > > In Overdue/Due Fee/Int,Principal repayment strategy one entry on 15 > > December 2015 should get created, which is not getting getting created. > > Interest should get calculated upto 14 December 2015. (Disbursement date 01 > > October 2015 and first repayment is doing on 15 December 2015). > Attachments: https://mifosforge.jira.com/browse/MIFOSX-2401 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1330) Pay Charge & withdrawals is violating Overdraft conditions on current and past Transactions
[ https://issues.apache.org/jira/browse/FINERACT-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17601936#comment-17601936 ] James Dailey commented on FINERACT-1330: Thanks Rahul - Yes, I saw that. Since this ticket was open for 530 days I wanted to make sure that the original reporter had a chance to see the resolution if he wants. > Pay Charge & withdrawals is violating Overdraft conditions on current and > past Transactions > --- > > Key: FINERACT-1330 > URL: https://issues.apache.org/jira/browse/FINERACT-1330 > Project: Apache Fineract > Issue Type: Bug > Components: Charges, Savings >Affects Versions: 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0 >Reporter: Francis Guchie >Assignee: Rahul Pawar >Priority: Major > Fix For: 1.9.0 > > Attachments: image-2021-03-10-23-45-06-414.png, > image-2021-03-10-23-45-21-854.png, image-2021-03-10-23-45-37-975.png, > image-2021-03-10-23-45-57-298.png, image-2021-03-10-23-46-46-146.png > > > h1. To better understand this issue start from FINERACT-1147 > Fineract uses future balance to effect transactions thus violating other > rules like OVER-DRAFT disabled > * Create a client on 01 Jan 2021 > * Apply a savings account on 01 jan 2021 – *OVER DRAFT NOT ALLOWED* > * Add transactions 4Jan2021 of 50k, 5Jan2021 of 150k and 13 Jan2021 of 500k, > 1 Feb2021 of 500k to make a total of 1.2million on the account > * Now make a withdrawal on 29 Jan2021 of 900,000 > !image-2021-03-10-23-45-06-414.png! > ## Fineract should reject this transaction since overdraft not allowed and > because 900K > 700k available balance below is the message- this message is > in place !image-2021-03-10-23-45-21-854.png! > * Now let’s add a savings charge of 900,000 due for 29Jan 2021 and pay it up > on 29 Jan 2021 !image-2021-03-10-23-45-37-975.png! > * Lets pay the charge on 29Jan 2021 !image-2021-03-10-23-45-57-298.png! > * On submission the charge gets paid getting the Account into Negative on > 29Jan 2021 yet this account's Over-draft is disabled > !image-2021-03-10-23-46-46-146.png! > *Two issues here* > * Overdraft is disabled but the rule has been violated > * Fineract is using real-time balance (in my view) to effect back-dated > transactions > The rule of thumb should be the “balance at transaction date” to be > considered during transactions and not available balance -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1330) Pay Charge & withdrawals is violating Overdraft conditions on current and past Transactions
[ https://issues.apache.org/jira/browse/FINERACT-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17601925#comment-17601925 ] James Dailey commented on FINERACT-1330: [~francisguchie] thanks for reporting this. I noticed our devs have recently come up with a resolution ... will be in next release. I'm going through outstanding tickets. > Pay Charge & withdrawals is violating Overdraft conditions on current and > past Transactions > --- > > Key: FINERACT-1330 > URL: https://issues.apache.org/jira/browse/FINERACT-1330 > Project: Apache Fineract > Issue Type: Bug > Components: Charges, Savings >Affects Versions: 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0 >Reporter: Francis Guchie >Assignee: Rahul Pawar >Priority: Major > Fix For: 1.9.0 > > Attachments: image-2021-03-10-23-45-06-414.png, > image-2021-03-10-23-45-21-854.png, image-2021-03-10-23-45-37-975.png, > image-2021-03-10-23-45-57-298.png, image-2021-03-10-23-46-46-146.png > > > h1. To better understand this issue start from FINERACT-1147 > Fineract uses future balance to effect transactions thus violating other > rules like OVER-DRAFT disabled > * Create a client on 01 Jan 2021 > * Apply a savings account on 01 jan 2021 – *OVER DRAFT NOT ALLOWED* > * Add transactions 4Jan2021 of 50k, 5Jan2021 of 150k and 13 Jan2021 of 500k, > 1 Feb2021 of 500k to make a total of 1.2million on the account > * Now make a withdrawal on 29 Jan2021 of 900,000 > !image-2021-03-10-23-45-06-414.png! > ## Fineract should reject this transaction since overdraft not allowed and > because 900K > 700k available balance below is the message- this message is > in place !image-2021-03-10-23-45-21-854.png! > * Now let’s add a savings charge of 900,000 due for 29Jan 2021 and pay it up > on 29 Jan 2021 !image-2021-03-10-23-45-37-975.png! > * Lets pay the charge on 29Jan 2021 !image-2021-03-10-23-45-57-298.png! > * On submission the charge gets paid getting the Account into Negative on > 29Jan 2021 yet this account's Over-draft is disabled > !image-2021-03-10-23-46-46-146.png! > *Two issues here* > * Overdraft is disabled but the rule has been violated > * Fineract is using real-time balance (in my view) to effect back-dated > transactions > The rule of thumb should be the “balance at transaction date” to be > considered during transactions and not available balance -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (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:comment-tabpanel=17601922#comment-17601922 ] James Dailey commented on FINERACT-1586: Can you also self-assign? > 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, gsoc2022, mentor > Fix For: 1.9.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] [Commented] (FINERACT-1498) Liquibase support
[ https://issues.apache.org/jira/browse/FINERACT-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17489662#comment-17489662 ] James Dailey commented on FINERACT-1498: Looking at this issue - I think we should introduce the concept to the Community with whatever changes that must entail in forward migration of existing production instances. > Liquibase support > - > > Key: FINERACT-1498 > URL: https://issues.apache.org/jira/browse/FINERACT-1498 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Arnold Galovics >Assignee: Arnold Galovics >Priority: Major > > Switch to Liquibase schema migration instead of Flyway in order to be > database-independent for schema migrations. > > This is especially needed for bringing in PostgreSQL support on top of the > current MySQL support. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (FINERACT-739) Loan (Installment in multiples of) Rounding not working
[ https://issues.apache.org/jira/browse/FINERACT-739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486661#comment-17486661 ] James Dailey commented on FINERACT-739: --- If there isn't someone working on this, then remove from release 1.6. > Loan (Installment in multiples of) Rounding not working > --- > > Key: FINERACT-739 > URL: https://issues.apache.org/jira/browse/FINERACT-739 > Project: Apache Fineract > Issue Type: Bug > Components: Loan >Affects Versions: 1.3.0 >Reporter: Okeleke Mike >Priority: Major > Fix For: 1.6.0 > > Attachments: SS1.png, SS2.png, SS3.png > > > Loan repay schedule is not affected by *Installment in multiples of (IIM)* > setting in Loan Product screen > when you set the IIM to say: 1000, you are expected to have your total > repayments calculated to the nearest 1000 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (FINERACT-675) Address issue with creating rejected data table at office level
[ https://issues.apache.org/jira/browse/FINERACT-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486656#comment-17486656 ] James Dailey commented on FINERACT-675: --- There is no description and no information on this ticket. [~edcable] can this ticket be closed? Or, pushed to a later release. > Address issue with creating rejected data table at office level > > > Key: FINERACT-675 > URL: https://issues.apache.org/jira/browse/FINERACT-675 > Project: Apache Fineract > Issue Type: Sub-task > Components: Data Tables >Reporter: Ed Cable >Priority: Major > Fix For: 1.6.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (FINERACT-736) Update API docs for associating pre-defined nominal interest rates to loan products
[ https://issues.apache.org/jira/browse/FINERACT-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17486655#comment-17486655 ] James Dailey commented on FINERACT-736: --- Seems to still be an orphaned issue. I think it can be safely moved out of planned 1.6 release. > Update API docs for associating pre-defined nominal interest rates to loan > products > --- > > Key: FINERACT-736 > URL: https://issues.apache.org/jira/browse/FINERACT-736 > Project: Apache Fineract > Issue Type: Sub-task >Reporter: Vishwas Babu A J >Priority: Major > Labels: gsoc2019 > Fix For: 1.6.0 > > > With > [https://github.com/apache/fineract/commit/aaa61695cf27419a2bc9e018fc6e2715512a1094] > , the functionality for "Associating pre-defined nominal interest rates to > loan products" has been added in > [https://github.com/apache/fineract/tree/Fineract-614.] > The API documentation for the same needs to be updated at > [https://github.com/apache/fineract/blob/Fineract-614/api-docs/apiLive.htm] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (FINERACT-984) Postgres support
[ https://issues.apache.org/jira/browse/FINERACT-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17173439#comment-17173439 ] James Dailey edited comment on FINERACT-984 at 12/15/21, 6:42 PM: -- [~vorburger] [~ptuomola] I only just came across this ticket so will try to get Istvan Molnar from DPC to comment here as they were using Liquibase to support Postgres was (Author: edcable): [~vorburger] [~ptuomola] I only just came across this ticket so will try to get Istvan Molnar from DPC to comment here as they were using Liquibase to support Postgres and I was in process of getting the customer they did this work for to commit it back upstream. > Postgres support > > > Key: FINERACT-984 > URL: https://issues.apache.org/jira/browse/FINERACT-984 > Project: Apache Fineract > Issue Type: New Feature >Reporter: Michael Vorburger >Priority: Major > > [~ptuomola] in FINERACT-982 brought up if Fineract (non-CN) has looked at > Postgres support? > I'm not sure what the effort is, but someone motivated sure could try it out. > The Postgres JDBC driver is BSD licenses, which is fine for the ASF. > Personally I'd probably suggest "instead" not "in addition" to MySQL - but > that requires a data migration tool. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (FINERACT-1406) Upgrade JDK 11 LTS to JDK 17 LTS
[ https://issues.apache.org/jira/browse/FINERACT-1406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17450808#comment-17450808 ] James Dailey commented on FINERACT-1406: Any update on this? > Upgrade JDK 11 LTS to JDK 17 LTS > > > Key: FINERACT-1406 > URL: https://issues.apache.org/jira/browse/FINERACT-1406 > Project: Apache Fineract > Issue Type: Improvement >Affects Versions: 1.5.0 >Reporter: Victor Romero >Assignee: Victor Romero >Priority: Major > Labels: tech-debt > Fix For: 1.6.0 > > > Upgrade JDK 11 LTS to JDK 17 LTS -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (FINERACT-1439) Performance hammered by too many EAGER Load
[ https://issues.apache.org/jira/browse/FINERACT-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dailey updated FINERACT-1439: --- Description: Putting this in JIRA now to emphasize a pattern we need to avoid and to call for some PRs to correct some issues recently introduced into dev branch. We should use Eager load in SQL very very infrequently. Use lazy loading to avoid the hit to performance. Get only what you need, when you need it. Eager loading retrieves the full model and relational data. In a complex data model like fineract, that means loading dozens of tables data that you won't use in your operation. That is a pattern we must avoid to keep the platform scalable. We need to not only tune (see https://issues.apache.org/jira/browse/FINERACT-912) but to set up tests to avoid creating new problems as features are added. I think the tests need to exercise each API and get a response back within a predetermined timeframe. Doing the right SQL statements is harder, but more rewarding!! was: Putting this in JIRA now to emphasize a pattern we need to avoid and to call for some PRs to correct some issues recently introduced into dev branch. We should use Eager very very infrequently. Use lazy loading to avoid the hit to performance. Eager loading retrieves the full model and relational data. In a complex data model like finer act, that means loading dozens of tables data that you won't use in your operation. That is a pattern we must avoid to keep the platform scalable. > Performance hammered by too many EAGER Load > --- > > Key: FINERACT-1439 > URL: https://issues.apache.org/jira/browse/FINERACT-1439 > Project: Apache Fineract > Issue Type: Bug >Reporter: James Dailey >Assignee: Ed Cable >Priority: Major > > Putting this in JIRA now to emphasize a pattern we need to avoid and to call > for some PRs to correct some issues recently introduced into dev branch. We > should use Eager load in SQL very very infrequently. Use lazy loading to > avoid the hit to performance. Get only what you need, when you need it. > Eager loading retrieves the full model and relational data. In a complex > data model like fineract, that means loading dozens of tables data that you > won't use in your operation. That is a pattern we must avoid to keep the > platform scalable. > We need to not only tune (see > https://issues.apache.org/jira/browse/FINERACT-912) but to set up tests to > avoid creating new problems as features are added. I think the tests need to > exercise each API and get a response back within a predetermined timeframe. > Doing the right SQL statements is harder, but more rewarding!! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (FINERACT-1439) Performance hammered by too many EAGER Load
[ https://issues.apache.org/jira/browse/FINERACT-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dailey reassigned FINERACT-1439: -- Assignee: Ed Cable > Performance hammered by too many EAGER Load > --- > > Key: FINERACT-1439 > URL: https://issues.apache.org/jira/browse/FINERACT-1439 > Project: Apache Fineract > Issue Type: Bug >Reporter: James Dailey >Assignee: Ed Cable >Priority: Major > > Putting this in JIRA now to emphasize a pattern we need to avoid and to call > for some PRs to correct some issues recently introduced into dev branch. We > should use Eager very very infrequently. Use lazy loading to avoid the hit > to performance. > Eager loading retrieves the full model and relational data. In a complex > data model like finer act, that means loading dozens of tables data that you > won't use in your operation. That is a pattern we must avoid to keep the > platform scalable. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (FINERACT-1439) Performance hammered by too many EAGER Load
James Dailey created FINERACT-1439: -- Summary: Performance hammered by too many EAGER Load Key: FINERACT-1439 URL: https://issues.apache.org/jira/browse/FINERACT-1439 Project: Apache Fineract Issue Type: Bug Reporter: James Dailey Putting this in JIRA now to emphasize a pattern we need to avoid and to call for some PRs to correct some issues recently introduced into dev branch. We should use Eager very very infrequently. Use lazy loading to avoid the hit to performance. Eager loading retrieves the full model and relational data. In a complex data model like finer act, that means loading dozens of tables data that you won't use in your operation. That is a pattern we must avoid to keep the platform scalable. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (FINERACT-1415) Make sure that using this pseudorandom number generator is safe
[
https://issues.apache.org/jira/browse/FINERACT-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17432138#comment-17432138
]
James Dailey commented on FINERACT-1415:
[~bgowda] if you can also link this ticket to other tickets, please do so. It
helps to have related tickets get resolved.
> Make sure that using this pseudorandom number generator is safe
> ---
>
> Key: FINERACT-1415
> URL: https://issues.apache.org/jira/browse/FINERACT-1415
> Project: Apache Fineract
> Issue Type: Improvement
>Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0
>Reporter: Victor Romero
>Assignee: Victor Romero
>Priority: Major
> Labels: tech-debt
> Fix For: 1.6.0
>
>
> [https://sonarcloud.io/project/security_hotspots?id=apache_fineract#]
>
> Using pseudorandom number generators (PRNGs) is security-sensitive. For
> example, it has led in the past to the following vulnerabilities:
> * [CVE-2013-6386|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6386]
> * [CVE-2006-3419|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3419]
> * [CVE-2008-4102|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4102]
> When software generates predictable values in a context requiring
> unpredictability, it may be possible for an attacker to guess the next value
> that will be generated, and use this guess to impersonate another user or
> access sensitive information.
> As the {{java.util.Random}} class relies on a pseudorandom number generator,
> this class and relating {{java.lang.Math.random()}} method should not be used
> for security-critical applications or for protecting sensitive data. In such
> context, the {{java.security.SecureRandom}} class which relies on a
> cryptographically strong random number generator (RNG) should be used in
> place.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FINERACT-1406) Upgrade JDK 11 LTS to JDK 17 LTS
[ https://issues.apache.org/jira/browse/FINERACT-1406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17431362#comment-17431362 ] James Dailey commented on FINERACT-1406: Victor - can you resolve the validation tests? i.e. the PR needs to be ready to pass the tests or the proposal can be to change the tests in the case that the tests are wrongly constructed. > Upgrade JDK 11 LTS to JDK 17 LTS > > > Key: FINERACT-1406 > URL: https://issues.apache.org/jira/browse/FINERACT-1406 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Victor Romero >Assignee: Victor Romero >Priority: Major > > Upgrade JDK 11 LTS to JDK 17 LTS -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-1398) Standardize the Character Set and the Collation
[ https://issues.apache.org/jira/browse/FINERACT-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425154#comment-17425154 ] James Dailey commented on FINERACT-1398: Discussed on list Having a standardized Unicode implementation will simplify, and Utf8mb4 instead of a mix of utf8* is a no-brainer... > 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.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.5.1 >Reporter: Victor Romero >Priority: Major > Fix For: 1.6.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.3.4#803005)
[jira] [Comment Edited] (FINERACT-1170) Automated Load Testing scenarios & tooling
[ https://issues.apache.org/jira/browse/FINERACT-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218432#comment-17218432 ] James Dailey edited comment on FINERACT-1170 at 10/21/20, 5:23 PM: --- [~edcable] should definitely weigh in. In our first generation of Mifos (precursor) we had continuous integration running with a complete data set that could be loaded via a SQL script during build. That data included PART A and some of PART B below: PART A - SETUP Import of Clients (Customers) Import of all Configs required (GL, Users, Groups, Offices, data scoping, etc) Import of Accounts (multiple per client) Import of history of Transactions (multiple and dating back several months) Then, run: * PART B - CREATE Create New Client; Create New Product; Create New Account (Approve Loan Process); Create New Payment Schedule; Do Disbursement (transaction); * PART C - CREATE ON EXISTING Create Transaction on Pre-Existing Client ; Create Transaction on New Client (repayment); Advance the date ; Repeat B & C above ; PART D - MODIFY * Modify Client Record ; Modify Client Payments ; Modify Group Details ; Modify Product (as allowed by rules) ; PART E - BATCH JOBS and REPORTS Do Batch Jobs GENERATE Reports PART F - SCALABILITY & PERFORMANCE TESTING * Multiple Users Signed on * Multiple Accounts being created and modified * Reports running in background * Transactions hitting across 10,000 accounts * Scale resources (processors, memory, I/O) was (Author: jdailey): [~edcable] should definitely weigh in. In our first generation of Mifos (precursor) we had continuous integration running with a complete data set that could be loaded via a SQL script during build. That data included: PART A - SETUP Import of Clients (Customers) Import of all Configs required (GL, Users, Groups, Offices, data scoping, etc) Import of Accounts (multiple per client) Import of history of Transactions (multiple and dating back several months) Then, run: * PART B - CREATE Create New Client; Create New Product; Create New Account (Approve Loan Process); Create New Payment Schedule; Do Disbursement (transaction); * PART C - CREATE ON EXISTING Create Transaction on Pre-Existing Client ; Create Transaction on New Client (repayment); Advance the date ; Repeat B & C above ; PART D - MODIFY * Modify Client Record ; Modify Client Payments ; Modify Group Details ; Modify Product (as allowed by rules) ; PART E - BATCH JOBS and REPORTS Do Batch Jobs GENERATE Reports PART F - SCALABILITY & PERFORMANCE TESTING * Multiple Users Signed on * Multiple Accounts being created and modified * Reports running in background * Transactions hitting across 10,000 accounts * Scale resources (processors, memory, I/O) > Automated Load Testing scenarios & tooling > -- > > Key: FINERACT-1170 > URL: https://issues.apache.org/jira/browse/FINERACT-1170 > Project: Apache Fineract > Issue Type: New Feature >Reporter: Michael Vorburger >Priority: Critical > Labels: scalability > > During [ApacheCon @Home Sep 29 - Oct 1, > 2020|https://apachecon.com/acah2020/index.html], in a number of [sessions on > the Fineract track|https://apachecon.com/acah2020/tracks/fineract.html], > including: > * the BOFs, > * the "[To Infinity and Beyond: Scaling Fineract for the > Enterprise|https://docs.google.com/document/d/18pdICOm8jEZN5VI7MuHJK_jLO2UCu_NJMYivm0QAQOo/edit]; > panel > * the "[Running > Fineract.dev|https://docs.google.com/presentation/d/1-VP4bNkc5kZ3B0yme_vYLiY1qpswnfz8ainnX5fp3l8/]; > presentation > We have spoken about Fineract scalability ideas, and possible next steps. > We have identified that what we require most as a community to progress on > Fineract scalability (see [our JIRA issues with 'scalability' > label|https://issues.apache.org/jira/issues/?jql=labels%20%3D%20scalability%20and%20project%20%3D%22Apache%20Fineract%22%20]) > is a Automated Load Testing scenarios & tooling. > Tools suitable to build this include [JMeter|https://jmeter.apache.org], > [Gatling.io|https://gatling.io], perhaps even simply > [Postman|https://www.postman.com/] with > [Newman|https://github.com/postmanlabs/newman]. > We would, ideally, like for this to eventually run in our CI. > FYI [~avikg] ([~avikganguly]? [~avikganguly010]?), [~vromero] > ([~Fintecheando]?), [~aleks], [~edcable], [~jdailey] ([~jamespdailey]), > Istvan not on JIRA? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-1170) Automated Load Testing scenarios & tooling
[ https://issues.apache.org/jira/browse/FINERACT-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218432#comment-17218432 ] James Dailey commented on FINERACT-1170: [~edcable] should definitely weigh in. In our first generation of Mifos (precursor) we had continuous integration running with a complete data set that could be loaded via a SQL script during build. That data included: PART A - SETUP Import of Clients (Customers) Import of all Configs required (GL, Users, Groups, Offices, data scoping, etc) Import of Accounts (multiple per client) Import of history of Transactions (multiple and dating back several months) Then, run: * PART B - CREATE Create New Client; Create New Product; Create New Account (Approve Loan Process); Create New Payment Schedule; Do Disbursement (transaction); * PART C - CREATE ON EXISTING Create Transaction on Pre-Existing Client ; Create Transaction on New Client (repayment); Advance the date ; Repeat B & C above ; PART D - MODIFY * Modify Client Record ; Modify Client Payments ; Modify Group Details ; Modify Product (as allowed by rules) ; PART E - BATCH JOBS and REPORTS Do Batch Jobs GENERATE Reports PART F - SCALABILITY & PERFORMANCE TESTING * Multiple Users Signed on * Multiple Accounts being created and modified * Reports running in background * Transactions hitting across 10,000 accounts * Scale resources (processors, memory, I/O) > Automated Load Testing scenarios & tooling > -- > > Key: FINERACT-1170 > URL: https://issues.apache.org/jira/browse/FINERACT-1170 > Project: Apache Fineract > Issue Type: New Feature >Reporter: Michael Vorburger >Priority: Critical > Labels: scalability > > During [ApacheCon @Home Sep 29 - Oct 1, > 2020|https://apachecon.com/acah2020/index.html], in a number of [sessions on > the Fineract track|https://apachecon.com/acah2020/tracks/fineract.html], > including: > * the BOFs, > * the "[To Infinity and Beyond: Scaling Fineract for the > Enterprise|https://docs.google.com/document/d/18pdICOm8jEZN5VI7MuHJK_jLO2UCu_NJMYivm0QAQOo/edit]; > panel > * the "[Running > Fineract.dev|https://docs.google.com/presentation/d/1-VP4bNkc5kZ3B0yme_vYLiY1qpswnfz8ainnX5fp3l8/]; > presentation > We have spoken about Fineract scalability ideas, and possible next steps. > We have identified that what we require most as a community to progress on > Fineract scalability (see [our JIRA issues with 'scalability' > label|https://issues.apache.org/jira/issues/?jql=labels%20%3D%20scalability%20and%20project%20%3D%22Apache%20Fineract%22%20]) > is a Automated Load Testing scenarios & tooling. > Tools suitable to build this include [JMeter|https://jmeter.apache.org], > [Gatling.io|https://gatling.io], perhaps even simply > [Postman|https://www.postman.com/] with > [Newman|https://github.com/postmanlabs/newman]. > We would, ideally, like for this to eventually run in our CI. > FYI [~avikg] ([~avikganguly]? [~avikganguly010]?), [~vromero] > ([~Fintecheando]?), [~aleks], [~edcable], [~jdailey] ([~jamespdailey]), > Istvan not on JIRA? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-1125) Integrate Alternative Reporting tool for Fineract 1.x without Apache License violations
[ https://issues.apache.org/jira/browse/FINERACT-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206298#comment-17206298 ] James Dailey commented on FINERACT-1125: [~francisguchie]. Step 1 is to find the license that applies to the project you want to consider. Step 2. Lookup the licenses and how they map to the Apache Foundation requirements on this page --> [https://apache.org/legal/resolved.html]. That page explains (simplified): * Category A means "OK" * Cateorgy B means "Careful" ...possibly ok if you follow certain steps * Category X means NOT Allowed in an apache code release As I said, BIRT is category B . See EPL License on above page KNIME is not open source and could not be included in any apache project See [https://www.knime.com/download/license] Don't know about the other two you mentioned but just google them and read their licenses. Also, a better direction may be Kibana and the ELK stack as these are apache projects. Now, let's see Micheal's work on Pentaho over at FINERACT-1127 > Integrate Alternative Reporting tool for Fineract 1.x without Apache License > violations > --- > > Key: FINERACT-1125 > URL: https://issues.apache.org/jira/browse/FINERACT-1125 > Project: Apache Fineract > Issue Type: Improvement > Components: Build >Affects Versions: 1.4.0 >Reporter: Francis Guchie >Priority: Major > Labels: hard > > read here [https://github.com/apache/fineract/pull/1262] > and > [https://www.apache.org/legal/resolved.html#category-x] > and > [https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License] > We need a reporting support that will not have licensing violations > for example the following > h1. BIRT > [https://www.eclipse.org/birt/about/] their license details are > [https://en.wikipedia.org/wiki/Eclipse_Public_License] > h1. KNIME > [|https://www.knime.com/downloads/full-license] > [https://www.knime.com/knime-report-designer > |https://www.knime.com/knime-report-designer]their licence details are > [https://www.knime.com/downloads/full-license] > h1. METABASE > [https://www.metabase.com/] and their license is > [https://www.metabase.com/license/] > h1. SEAL REPORT > [https://sealreport.org/] and their License is > [https://sealreport.org/#lineRequirements] > [https://www.spagobi.org/] and their license is > [https://www.spagobi.org/communities/license/] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-1125) Integrate Alternative Reporting tool for Fineract 1.x without Apache License violations
[ https://issues.apache.org/jira/browse/FINERACT-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205836#comment-17205836 ] James Dailey commented on FINERACT-1125: BIRT, by the way is a Category B in Apache. [https://apache.org/legal/resolved.html]. Cat B needs to be included only as binary. I think we should avoid this at Apache Fineract. It would complicate matters. > Integrate Alternative Reporting tool for Fineract 1.x without Apache License > violations > --- > > Key: FINERACT-1125 > URL: https://issues.apache.org/jira/browse/FINERACT-1125 > Project: Apache Fineract > Issue Type: Improvement > Components: Build >Affects Versions: 1.4.0 >Reporter: Francis Guchie >Priority: Major > Labels: hard > > read here [https://github.com/apache/fineract/pull/1262] > and > [https://www.apache.org/legal/resolved.html#category-x] > and > [https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License] > We need a reporting support that will not have licensing violations > for example the following > h1. BIRT > [https://www.eclipse.org/birt/about/] their license details are > [https://en.wikipedia.org/wiki/Eclipse_Public_License] > h1. KNIME > [|https://www.knime.com/downloads/full-license] > [https://www.knime.com/knime-report-designer > |https://www.knime.com/knime-report-designer]their licence details are > [https://www.knime.com/downloads/full-license] > h1. METABASE > [https://www.metabase.com/] and their license is > [https://www.metabase.com/license/] > h1. SEAL REPORT > [https://sealreport.org/] and their License is > [https://sealreport.org/#lineRequirements] > [https://www.spagobi.org/] and their license is > [https://www.spagobi.org/communities/license/] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-1170) Automated Load Testing scenarios & tooling
[ https://issues.apache.org/jira/browse/FINERACT-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17205798#comment-17205798 ] James Dailey commented on FINERACT-1170: When looking at this, I want to also focus on maintainability. 1) It needs to be "integrated" in the build (CI) and be triggered at the appropriate times. If not, then I think we agree, it won't be used and if not used, then not maintained. 2) We should use a toolset with a future path. I have found something that can convert Postman collections to JMeter. [https://github.com/fangls/postman2jmx]. MIT License. (Which is a category A type license and so compatible) 3) We should start small with something very accessible to a group of devs that may be new to this. or If a group has already built something and can please contribute that code, then we could start with that. > Automated Load Testing scenarios & tooling > -- > > Key: FINERACT-1170 > URL: https://issues.apache.org/jira/browse/FINERACT-1170 > Project: Apache Fineract > Issue Type: New Feature >Reporter: Michael Vorburger >Priority: Blocker > Labels: scalability > > During [ApacheCon @Home Sep 29 - Oct 1, > 2020|https://apachecon.com/acah2020/index.html], in a number of [sessions on > the Fineract track|https://apachecon.com/acah2020/tracks/fineract.html], > including: > * the BOFs, > * the "[To Infinity and Beyond: Scaling Fineract for the > Enterprise|https://docs.google.com/document/d/18pdICOm8jEZN5VI7MuHJK_jLO2UCu_NJMYivm0QAQOo/edit]; > panel > * the "[Running > Fineract.dev|https://docs.google.com/presentation/d/1-VP4bNkc5kZ3B0yme_vYLiY1qpswnfz8ainnX5fp3l8/]; > presentation > We have spoken about Fineract scalability ideas, and possible next steps. > We have identified that what we require most as a community to progress on > Fineract scalability (see [our JIRA issues with 'scalability' > label|https://issues.apache.org/jira/issues/?jql=labels%20%3D%20scalability%20and%20project%20%3D%22Apache%20Fineract%22%20]) > is a Automated Load Testing scenarios & tooling. > Tools suitable to build this include [JMeter|https://jmeter.apache.org], > [Gatling.io|https://gatling.io], perhaps even simply > [Postman|https://www.postman.com/] with > [Newman|https://github.com/postmanlabs/newman]. > We would, ideally, like for this to eventually run in our CI. > FYI [~avikg] ([~avikganguly]? [~avikganguly010]?), [~vromero] > ([~Fintecheando]?), [~aleks], [~edcable], [~jdailey] ([~jamespdailey]), > Istvan not on JIRA? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-1125) Integrate Alternative Reporting tool for Fineract 1.x without Apache License violations
[ https://issues.apache.org/jira/browse/FINERACT-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17184149#comment-17184149 ] James Dailey commented on FINERACT-1125: [~francisguchie] - Good to have your ideas on this! Thank you. As background, when the Mifos Initiative contributed the code to Apache, we were surprised to find out that we could not port over the Pentaho Reports due to the licensing issues. I think a simple set of reporting interfaces, specifically a set of APIs or connectors (that expand from where the Pentaho approach leaves off), is a particularly useful area of work for release 1.5. These connectors could allow for a System Integrator (SI) to use the basic reporting infra but then to expand it. As with all open source, the idea is to create enough of a starting point - in the commons - to allow for others to build on top of it. By doing just the minimum, the project enables a virtuous cycle of contribution. That is the ideal. Could you take part of this on? First, your research is a great place to start. So... If you were to evaluate the above options: Metabase Seal Report BIRT KNIME How would each of these score (on a scale of 1 to 5) on the following:? * Component exists as a "plug in" with few required integration changes and is thus more easily maintained * Component can deployed to be highly scalable - e.g. doesn't impact I/O on the core deployment * Component allows for additional customization or can be "built on top of" for extensibility *Could you say?* Early on in the Mifos project we built a BIRT reporting engine. At the time it was the best open source option out there. It seems to have to staying power. ;) > Integrate Alternative Reporting tool for Fineract 1.x without Apache License > violations > --- > > Key: FINERACT-1125 > URL: https://issues.apache.org/jira/browse/FINERACT-1125 > Project: Apache Fineract > Issue Type: Improvement > Components: Build >Affects Versions: 1.4.0 >Reporter: Francis Guchie >Priority: Major > Labels: hard > > read here [https://github.com/apache/fineract/pull/1262] > and > [https://www.apache.org/legal/resolved.html#category-x] > and > [https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License] > We need a reporting support that will not have licensing violations > for example the following > h1. BIRT > [https://www.eclipse.org/birt/about/] their license details are > [https://en.wikipedia.org/wiki/Eclipse_Public_License] > h1. KNIME > [|https://www.knime.com/downloads/full-license] > [https://www.knime.com/knime-report-designer > |https://www.knime.com/knime-report-designer]their licence details are > [https://www.knime.com/downloads/full-license] > h1. METABASE > [https://www.metabase.com/] and their license is > [https://www.metabase.com/license/] > h1. SEAL REPORT > [https://sealreport.org/] and their License is > [https://sealreport.org/#lineRequirements] > [https://www.spagobi.org/] and their license is > [https://www.spagobi.org/communities/license/] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-1120) Two Factor Auth Filter Type Cast Error
[
https://issues.apache.org/jira/browse/FINERACT-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17184126#comment-17184126
]
James Dailey commented on FINERACT-1120:
Is the business requirement here to require Two Factor Authentication? Or is
it to enable the potential use of 2F?
> Two Factor Auth Filter Type Cast Error
> --
>
> Key: FINERACT-1120
> URL: https://issues.apache.org/jira/browse/FINERACT-1120
> Project: Apache Fineract
> Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Saransh Sharma
>Priority: Major
> Fix For: 1.5.0
>
>
> Error :
> java.lang.ClassCastException: class java.lang.String cannot be cast to class
> org.springframework.security.authentication.AnonymousAuthenticationToken
> {code:java}
> // AppUser user = (AppUser) authentication.getPrincipal();
> {code}
> This line has some type casting error exception when running the two factor
> mode.
> To enable two factor mode you need to run with -Psecurity=twofactor
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (FINERACT-949) Improve Java API style used for writing integration tests in Fineract
[
https://issues.apache.org/jira/browse/FINERACT-949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102979#comment-17102979
]
James Dailey commented on FINERACT-949:
---
I'm not going to be much use on this, but just reading the
([https://github.com/skyscreamer/JSONassert] suggests it has a good approach
and makes tests less brittle, which seams to be a main issue for fineract.
Down the paths you outlined, I also found
[https://springframework.guru/processing-json-jackson/] (and the debate of
Jackson vs GSON). It seems that the criteria for this effort is: less
brittle, more readable, easy to write. I hope someone with some experience in
this can chime in.
> Improve Java API style used for writing integration tests in Fineract
> -
>
> Key: FINERACT-949
> URL: https://issues.apache.org/jira/browse/FINERACT-949
> Project: Apache Fineract
> Issue Type: Improvement
>Reporter: Michael Vorburger
>Priority: Major
> Labels: integration-test, technical, testing
>
> The current (Java) "style" that integration tests are written in in Fineract
> is... really ugly!
> They are from a bygone era when Java had no generic. All those weird
> {{java.util.HashSet}}, with a lot of {{java.lang.Object}} etc. in tests
> are... so not 21st century style.
> I don't really have the answer here, yet - but perhaps others have ideas -
> how does one write Java (test) code in 2020 which deals with JSON in a nicer
> way?
> Does REST Assured (http://rest-assured.io) meanwhile offer a better way to do
> this kind of thing?
> Could https://github.com/skyscreamer/JSONassert be of use and interest for
> this purpose?
> BTW if using REST Assured better than we are is part of the answer here, then
> let's first do FINERACT-884.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (FINERACT-904) Post Interest on Account Activation Date for Fixed Deposit and Recurring Deposit Accounts
[ https://issues.apache.org/jira/browse/FINERACT-904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dailey updated FINERACT-904: -- Fix Version/s: (was: 1.6.0) (was: 1.5.0) (was: 1.4.0) > Post Interest on Account Activation Date for Fixed Deposit and Recurring > Deposit Accounts > - > > Key: FINERACT-904 > URL: https://issues.apache.org/jira/browse/FINERACT-904 > Project: Apache Fineract > Issue Type: New Feature > Components: Savings >Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0 >Reporter: Airsay >Priority: Minor > > Hello, > Presently for Savings Products (Savings/Fixed Deposit and Recurring Deposit) > Fineract posts Interest at month end. There is a need for this to change in > our use case (and I believe this may be widely applicable for multiple users). > Assuming a customer's Fixed Deposit or Recurring Deposit account is activated > on Jan 20, we post interest to the customer's account on Feb 20 and on the > 20th of every subsequent month until the duration of the account lapses. So > for a 6 month Fixed Deposit Account interest would be posted on Feb 20, Mar > 20, Apr 20, May 20, June 20 and July 20. > For "tricky" dates which don't occur across all months then interest is > posted at the end of the month. So For example an account activated on > January 30 will get Interest posted on Feb 28 (or Feb 29th for a leap year) > and then Mar 30, April 30 etc. One that was activated on say August 31st will > receive interest on Sep 30, Oct 31, Nov 30, Dec 31 etc. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-843) Mifos Calculation of reinstallment day
[ https://issues.apache.org/jira/browse/FINERACT-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17100270#comment-17100270 ] James Dailey commented on FINERACT-843: --- What is the status of this ticket? I believe you want to fix this in an upcoming version. > Mifos Calculation of reinstallment day > -- > > Key: FINERACT-843 > URL: https://issues.apache.org/jira/browse/FINERACT-843 > Project: Apache Fineract > Issue Type: New Feature > Components: Loan >Affects Versions: 1.3.0 >Reporter: Jose Alberto Hernandez Maldonado >Priority: Minor > Labels: easyfix, features > Fix For: 1.3.0 > > Attachments: 01__Terms_Settings.png, 02__Schedule.png > > > Problem > How to configure a Loan with 2 specific installments in a Month. > # The first one occurs every 15th oh the Month. > # The Second must occurs the last day of the Month. > Solution > We detect two cases: > If the date is before 15th day, then the next is (fixed) to the 15th day of > the current month, > Else If the date is after 15th day, then the next date will be end of month > (calculated) with the java LocalDate method class. > * In both cases, as Mifos X applies the Business rule for no working days. > > Finally we defined a new EnumType called SemiWeeks for that case -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-904) Post Interest on Account Activation Date for Fixed Deposit and Recurring Deposit Accounts
[ https://issues.apache.org/jira/browse/FINERACT-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17100268#comment-17100268 ] James Dailey commented on FINERACT-904: --- I don't see this as a Major Issue for the software project. If this is necessary by a specific institution, then by all means please raise a PR and contribute that improvement back. We would welcome it. For now, I'm changing this to Minor. Please respond if you think this belongs as a Major and why. Also, this came up on the list of tickets that were part of release 1.3. Since 1.3 was closed some time ago, I have removed this from consideration. > Post Interest on Account Activation Date for Fixed Deposit and Recurring > Deposit Accounts > - > > Key: FINERACT-904 > URL: https://issues.apache.org/jira/browse/FINERACT-904 > Project: Apache Fineract > Issue Type: New Feature > Components: Savings >Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0 >Reporter: Airsay >Priority: Minor > Fix For: 1.4.0, 1.5.0, 1.6.0 > > > Hello, > Presently for Savings Products (Savings/Fixed Deposit and Recurring Deposit) > Fineract posts Interest at month end. There is a need for this to change in > our use case (and I believe this may be widely applicable for multiple users). > Assuming a customer's Fixed Deposit or Recurring Deposit account is activated > on Jan 20, we post interest to the customer's account on Feb 20 and on the > 20th of every subsequent month until the duration of the account lapses. So > for a 6 month Fixed Deposit Account interest would be posted on Feb 20, Mar > 20, Apr 20, May 20, June 20 and July 20. > For "tricky" dates which don't occur across all months then interest is > posted at the end of the month. So For example an account activated on > January 30 will get Interest posted on Feb 28 (or Feb 29th for a leap year) > and then Mar 30, April 30 etc. One that was activated on say August 31st will > receive interest on Sep 30, Oct 31, Nov 30, Dec 31 etc. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FINERACT-904) Post Interest on Account Activation Date for Fixed Deposit and Recurring Deposit Accounts
[ https://issues.apache.org/jira/browse/FINERACT-904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dailey updated FINERACT-904: -- Fix Version/s: (was: 1.3.0) Priority: Minor (was: Major) > Post Interest on Account Activation Date for Fixed Deposit and Recurring > Deposit Accounts > - > > Key: FINERACT-904 > URL: https://issues.apache.org/jira/browse/FINERACT-904 > Project: Apache Fineract > Issue Type: New Feature > Components: Savings >Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0 >Reporter: Airsay >Priority: Minor > Fix For: 1.4.0, 1.5.0, 1.6.0 > > > Hello, > Presently for Savings Products (Savings/Fixed Deposit and Recurring Deposit) > Fineract posts Interest at month end. There is a need for this to change in > our use case (and I believe this may be widely applicable for multiple users). > Assuming a customer's Fixed Deposit or Recurring Deposit account is activated > on Jan 20, we post interest to the customer's account on Feb 20 and on the > 20th of every subsequent month until the duration of the account lapses. So > for a 6 month Fixed Deposit Account interest would be posted on Feb 20, Mar > 20, Apr 20, May 20, June 20 and July 20. > For "tricky" dates which don't occur across all months then interest is > posted at the end of the month. So For example an account activated on > January 30 will get Interest posted on Feb 28 (or Feb 29th for a leap year) > and then Mar 30, April 30 etc. One that was activated on say August 31st will > receive interest on Sep 30, Oct 31, Nov 30, Dec 31 etc. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-871) NUBAN Account Format is Required
[ https://issues.apache.org/jira/browse/FINERACT-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17098194#comment-17098194 ] James Dailey commented on FINERACT-871: --- Henry - So, I understand that what you are asking for. You need the overall solution to generate the proper NUBAN (account number with built in check sums) and that this number has reference to the static Bank number. I think you should reach out to the listserv with a request to help you with this. You may need to engage $$ someone to code this and then have that contributed back to the core. Or you may find a volunteer. Since this is a custom numbering scheme for account numbers, it has a couple of different pieces (I believe). Since I may be wrong, please comment and clarify. 1)Generating a new account number. This could be done partly via a front end which takes a known fixed BankID and then checks the storage of existing account for the next in sequence and then does the modulo calculations in the regulatory circular you attached above. 2) The backend storage of the number (trivial and already supported I believe, via custom fields) 3) Modifying the APIs to support this exchange of data - if necessary? I think it may be possible to use existing APIs in a sequence. If you can put the requirements more in a kind of developer requirement, that would help. > NUBAN Account Format is Required > > > Key: FINERACT-871 > URL: https://issues.apache.org/jira/browse/FINERACT-871 > Project: Apache Fineract > Issue Type: New Feature > Components: Accounting, Client >Affects Versions: 1.3.0 >Reporter: Henry >Priority: Blocker > Attachments: Exposure Circular for NUBAN.pdf > > > Hello mentors, > > We are starting an implementation for one of our MfB in Nigeria. While Mifos > is the preferred option we are stuck with a regulatory requirement account > client account format. > Nigeria operates a Unified client account format: Nigeria Unified Bank > Account Number (NUBAN) system which we have observed cannot be achieved in > Mifos at the moment. > I have attached the guide on how to generate the NUBAN compliant account > numbers for your review and assistance to proceed with our project. > We are available for further clarifications. > > Best regards, > Henry.[^Exposure Circular for NUBAN.pdf] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINERACT-738) Broken link for client Transaction (API docs)
[ https://issues.apache.org/jira/browse/FINERACT-738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801174#comment-16801174 ] James Dailey commented on FINERACT-738: --- I believe this belongs more directly in the Mifos issue tracking (ticket) system. [https://mifosforge.jira.com|https://mifosforge.jira.com/] , unless I am mistaken about what you are showing. > Broken link for client Transaction (API docs) > - > > Key: FINERACT-738 > URL: https://issues.apache.org/jira/browse/FINERACT-738 > Project: Apache Fineract > Issue Type: Bug >Affects Versions: 1.0.0, 1.4.0 > Environment: Mac OS, El captain 10.11, 8g RAM, 2.5Ghz >Reporter: Mua Ndzo Laurent >Priority: Blocker > Labels: beginner, newbie > Attachments: Screen Shot 2019-03-25 at 1.54.16 AM.png > > Original Estimate: 5m > Remaining Estimate: 5m > > Currently in the clients menu one cannot navigate to the client Transaction > section due to a broken link. > This displays an unpleasant string `td>` at the top the dropdown as shown in > the screenshot attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (FINERACT-706) Payments switch integration
[ https://issues.apache.org/jira/browse/FINERACT-706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dailey updated FINERACT-706: -- Description: This is a ticket to cover the new requirements from integration with a payment switching solution, using best practices in a push-payment real-time environment. [https://lists.apache.org/thread.html/fa8f745cd7228a8f8418561ddadc715a3388d01656bcbc28680f86f2@%3Cdev.fineract.apache.org%3E] Basically, there are a few minor changes are needed to fineract1.x to support integration with a payments hub. The payments hub will handle most of the functionality, so the changes to fineract1.x are to be minimal. A new package will be created with new API endpoints. The functional requirements will include: * Get a quote * Hold funds * Send funds (confirmed ) Assuming customers are authenticated and using a front end solution, in the payments flow, end users (payors) get a "Request for Payment" (RfP) from a Payee and after getting a quote for the cost of that payment, they do a Payment Initiation. When they initiate the payment their checking/savings account shows an entry which is debit-amount-on-hold. There is a further requirement around lookup values - where a new "secondary ID" is needed in the account table. That secondary ID is used for the routing address of the payee. To further explain the intent, imagine a payments switch between two instances of fineract, the switch or "interoperable service for transfers" (IST) talks over APIs to a thin "Payments Hub" on the fineract infrastructure. was: This is a ticket to cover the new requirements from integration with a payment switching solution, using best practices in a push-payment real-time environment. [https://lists.apache.org/thread.html/fa8f745cd7228a8f8418561ddadc715a3388d01656bcbc28680f86f2@%3Cdev.fineract.apache.org%3E] Basically, the changes are needed to fineract1.x to support integration with a payments hub. The payments hub will handle most of the functionality, so the changes to fineract1.x are to be minimal. A new package will be created with new API endpoints. The functional requirements will include: * Get a quote * Hold funds * Send funds (confirmed ) Assuming customers are authenticated and using a front end solution, in the payments flow, end users (customers) receive a "Request for Payment" (RfP) and after getting a quote for the cost of that payment, then do a Payment Initiation. When they initiate the payment their (current) account shows an entry which is debit-amount-on-hold. > Payments switch integration > > > Key: FINERACT-706 > URL: https://issues.apache.org/jira/browse/FINERACT-706 > Project: Apache Fineract > Issue Type: New Feature > Components: Accounting >Affects Versions: 1.3.0 >Reporter: James Dailey >Priority: Major > Labels: features > Fix For: 1.4.0 > > > This is a ticket to cover the new requirements from integration with a > payment switching solution, using best practices in a push-payment real-time > environment. > [https://lists.apache.org/thread.html/fa8f745cd7228a8f8418561ddadc715a3388d01656bcbc28680f86f2@%3Cdev.fineract.apache.org%3E] > > Basically, there are a few minor changes are needed to fineract1.x to support > integration with a payments hub. The payments hub will handle most of the > functionality, so the changes to fineract1.x are to be minimal. > A new package will be created with new API endpoints. > The functional requirements will include: > * Get a quote > * Hold funds > * Send funds (confirmed ) > Assuming customers are authenticated and using a front end solution, in the > payments flow, end users (payors) get a "Request for Payment" (RfP) from a > Payee and after getting a quote for the cost of that payment, they do a > Payment Initiation. When they initiate the payment their checking/savings > account shows an entry which is debit-amount-on-hold. > There is a further requirement around lookup values - where a new "secondary > ID" is needed in the account table. That secondary ID is used for the > routing address of the payee. > To further explain the intent, imagine a payments switch between two > instances of fineract, the switch or "interoperable service for transfers" > (IST) talks over APIs to a thin "Payments Hub" on the fineract > infrastructure. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FINCN-130) Payments hub integration
James Dailey created FINCN-130: -- Summary: Payments hub integration Key: FINCN-130 URL: https://issues.apache.org/jira/browse/FINCN-130 Project: Fineract Cloud Native Issue Type: New Feature Components: fineract-cn-accounting Reporter: James Dailey This is a ticket to express the required changes to fineract-CN for supporting integration with a payments hub, using modern push (credit transfer) real time approaches. It is anticipated that the solution involved will create a separate microservice with generalized API endpoints that support quote of cost, respond to request for payment, payment initiation, hold on funds, and confirmation of funds sent. There are also changes needed in the accounting and transaction microservices to support the proper hold of funds, confirmation of the funds movement (aka clearing) and other logic for error handling. please see also the listserv [https://lists.apache.org/thread.html/fa8f745cd7228a8f8418561ddadc715a3388d01656bcbc28680f86f2@%3Cdev.fineract.apache.org%3E] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (FINERACT-706) Payments switch integration
[ https://issues.apache.org/jira/browse/FINERACT-706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dailey updated FINERACT-706: -- Affects Version/s: 1.3.0 Description: This is a ticket to cover the new requirements from integration with a payment switching solution, using best practices in a push-payment real-time environment. [https://lists.apache.org/thread.html/fa8f745cd7228a8f8418561ddadc715a3388d01656bcbc28680f86f2@%3Cdev.fineract.apache.org%3E] Basically, the changes are needed to fineract1.x to support integration with a payments hub. The payments hub will handle most of the functionality, so the changes to fineract1.x are to be minimal. A new package will be created with new API endpoints. The functional requirements will include: * Get a quote * Hold funds * Send funds (confirmed ) Assuming customers are authenticated and using a front end solution, in the payments flow, end users (customers) receive a "Request for Payment" (RfP) and after getting a quote for the cost of that payment, then do a Payment Initiation. When they initiate the payment their (current) account shows an entry which is debit-amount-on-hold. was:This is a ticket to cover the new requirements from integration with a payment switching solution, using best practices in a push-payment real-time environment. [https://lists.apache.org/thread.html/fa8f745cd7228a8f8418561ddadc715a3388d01656bcbc28680f86f2@%3Cdev.fineract.apache.org%3E] Component/s: Accounting > Payments switch integration > > > Key: FINERACT-706 > URL: https://issues.apache.org/jira/browse/FINERACT-706 > Project: Apache Fineract > Issue Type: New Feature > Components: Accounting >Affects Versions: 1.3.0 >Reporter: James Dailey >Priority: Major > Labels: features > > This is a ticket to cover the new requirements from integration with a > payment switching solution, using best practices in a push-payment real-time > environment. > [https://lists.apache.org/thread.html/fa8f745cd7228a8f8418561ddadc715a3388d01656bcbc28680f86f2@%3Cdev.fineract.apache.org%3E] > > Basically, the changes are needed to fineract1.x to support integration with > a payments hub. The payments hub will handle most of the functionality, so > the changes to fineract1.x are to be minimal. > A new package will be created with new API endpoints. > The functional requirements will include: > * Get a quote > * Hold funds > * Send funds (confirmed ) > Assuming customers are authenticated and using a front end solution, in the > payments flow, end users (customers) receive a "Request for Payment" (RfP) > and after getting a quote for the cost of that payment, then do a Payment > Initiation. When they initiate the payment their (current) account shows an > entry which is debit-amount-on-hold. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (FINERACT-706) Payments switch integration
James Dailey created FINERACT-706: - Summary: Payments switch integration Key: FINERACT-706 URL: https://issues.apache.org/jira/browse/FINERACT-706 Project: Apache Fineract Issue Type: New Feature Reporter: James Dailey This is a ticket to cover the new requirements from integration with a payment switching solution, using best practices in a push-payment real-time environment. [https://lists.apache.org/thread.html/fa8f745cd7228a8f8418561ddadc715a3388d01656bcbc28680f86f2@%3Cdev.fineract.apache.org%3E] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FINCN-26) Replace MariaDB driver with drizzle as JDBC driver
[ https://issues.apache.org/jira/browse/FINCN-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638958#comment-16638958 ] James Dailey commented on FINCN-26: --- A little research on this seemed in order, and this blog entry on performance is as good a place as any to start: [https://mariadb.org/on-performance-of-jdbc-drivers/] This is from a 2013 benchmark of Maria, ConnectorJ, and Drizzle Connectors. The preference on a Maria site is clearly Maria, but if that is eliminated, then Drizzle rises to top on the basis of performance after a bug was found and corrected. Which points to two other elements of this decision: how stable are these connectors and will support be available longer term? Also, are there any other type 4 ODBC drivers that are compatible with Apache licensing. Note that Maria is based on Drizzle. Drizzle is BSD licensed which is a permissive license compatible with Apache. [https://mvnrepository.com/artifact/org.drizzle.jdbc/drizzle-jdbc]. The git is [https://github.com/krummas/DrizzleJDBC] and there are four to five active devs but very little activity as of late. It may be that this is a sign of stabilty as downloads are now above 12M. Oracle's Connector J [https://github.com/mysql/mysql-connector-j] has four active devs, two of whom are responsible for most of the PRs. I hope this is useful. Reference also: [https://www.geeksforgeeks.org/jdbc-drivers/] (Type 1 through 4 explained) [https://mariadb.com/kb/en/library/about-mariadb-connector-j/] > Replace MariaDB driver with drizzle as JDBC driver > -- > > Key: FINCN-26 > URL: https://issues.apache.org/jira/browse/FINCN-26 > Project: Fineract Cloud Native > Issue Type: Task > Components: fineract-cn-mariadb >Reporter: Myrle Krantz >Priority: Blocker > > Fineract CN currently depends on 'org.mariadb.jdbc:mariadb-java-client:1.4.3' > as our JDBC driver. It's for our connection to an SQL database, and can be > used for MySQL as well as MariaDB. This component is licensed as LGPL, and > therefore, needs to be replaced before we release. The current suggestion is > to replace it with drizzle. Other suggestions are also welcome. > Why can't we have dependencies to LGPL software? This sequence of events > would be bad: > 1.) We include LGPL software in our release. > 2.) Our code, including the LGPL dependency is included in proprietary code > of CompanyOmega > 3.) Some judge somewhere decides that the "firewall" separating our code from > the LGPL isn't strong enough to call prevent the viral aspects of LGPL from > taking effect. > 4.) CompanyOmega's proprietary code is now all open source and they go out of > business. > It's not a likely sequence, but because of the size of the negative outcome, > we avoid it by not including LGPL (or any other Category X software) in our > releases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
