[jira] [Assigned] (FINERACT-2031) Holiday not working as expected with setting "reschedule to next repayment date"
[
https://issues.apache.org/jira/browse/FINERACT-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ed Cable reassigned FINERACT-2031:
--
Assignee: Vinodh Kumar Katukota
> Holiday not working as expected with setting "reschedule to next repayment
> date"
>
>
> Key: FINERACT-2031
> URL: https://issues.apache.org/jira/browse/FINERACT-2031
> Project: Apache Fineract
> Issue Type: Bug
>Reporter: Bharath Gowda
>Assignee: Vinodh Kumar Katukota
>Priority: Major
> Fix For: 1.10.0
>
>
> Holiday not working as expected with setting "reschedule to next repayment
> date"
>
> To Reproduce
> # Create a 15 days frequency repayment schedule loan account with repayments
> starting from 1st January.
> # Create a holiday with "{*}from date{*}" & "{*}to date{*}" as 1st January
> and "{*}repayment schedule type{*}" as "reschedule to next repayment date"
> # Run the scheduler job and check the loan account repayment schedule
> # check the loan account repayment schedule
> The schedule is not getting changed
> *Expected Result*
> Schedule should shift all the remaining installments to next repayment date
> as per the loan frequency
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (FINERACT-2025) SQL Query Improvement
Ed Cable created FINERACT-2025: -- Summary: SQL Query Improvement Key: FINERACT-2025 URL: https://issues.apache.org/jira/browse/FINERACT-2025 Project: Apache Fineract Issue Type: Bug Affects Versions: 1.8.4 Reporter: Ed Cable Assignee: Mihaly Dallos Fix For: 1.9.0 Multiple areas within fineract-provider to be improved. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Deleted] (FINERACT-2024) Error- based SQL Injection vulnerabilities in 3 endpoints
[ https://issues.apache.org/jira/browse/FINERACT-2024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable deleted FINERACT-2024: --- > Error- based SQL Injection vulnerabilities in 3 endpoints > - > > Key: FINERACT-2024 > URL: https://issues.apache.org/jira/browse/FINERACT-2024 > Project: Apache Fineract > Issue Type: Bug >Reporter: Mihaly Dallos >Assignee: Mihaly Dallos >Priority: Blocker > > *SQL Injection at /fineract-provider/api/v1/loans* > The sqlSearch parameter appears to be vulnerable to SQL injection attacks. > The payload ' was submitted in the sqlSearch parameter, and a database error > message was returned. > *SQL Injection at /fineract-provider/api/v1/datatables/cdvfbn* > The URL path filename appears to be vulnerable to SQL injection attack. A > single quote was submitted in the URL path filename, and a database error > message was returned. Two single quotes were then submitted and the error > message disappeared. > *SQL Injection at /fineract-provider/api/v1/datatables/dfgh* > The URL path filename appears to be vulnerable to SQL injection attacks. (276 > kB) > https://festive-quiet-137.notion.site/SQL-Injection-at-fineract-provider-api-v1-datatables-dfgh-6c6649a66b2446999e74a060db0a4c32 > *SQL Injection at /fineract-provider/api/v1/clients* > The sqlSearch parameter appears to be vulnerable to SQL injection attacks. > The payload ' was submitted in the sqlSearch parameter, and a database error > message was returned. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-594) Recent Transactions Only Displays Charges, It should show savings and loan transitions too
[ https://issues.apache.org/jira/browse/FINERACT-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-594: -- Fix Version/s: 3.0.0 (was: 1.9.0) > Recent Transactions Only Displays Charges, It should show savings and loan > transitions too > --- > > Key: FINERACT-594 > URL: https://issues.apache.org/jira/browse/FINERACT-594 > Project: Apache Fineract > Issue Type: Bug > Components: Accounting, Charges, Loan, Savings >Affects Versions: 1.8.0 >Reporter: Rajan Maurya >Priority: Major > Labels: GSOC, Volunteer, easyfix, enha, patch > Fix For: 3.0.0 > > Original Estimate: 96h > Remaining Estimate: 96h > > Recent Transactions of the self-service user Only Displays Charges but It > should show savings and loan transitions too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-594) Recent Transactions Only Displays Charges, It should show savings and loan transitions too
[ https://issues.apache.org/jira/browse/FINERACT-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-594: -- Labels: GSOC Volunteer easyfix enha patch (was: 2019-mifos-gsoc GSOC Volunteer easyfix enha patch) > Recent Transactions Only Displays Charges, It should show savings and loan > transitions too > --- > > Key: FINERACT-594 > URL: https://issues.apache.org/jira/browse/FINERACT-594 > Project: Apache Fineract > Issue Type: Bug > Components: Accounting, Charges, Loan, Savings >Affects Versions: 1.8.0 >Reporter: Rajan Maurya >Priority: Major > Labels: GSOC, Volunteer, easyfix, enha, patch > Fix For: 1.9.0 > > Original Estimate: 96h > Remaining Estimate: 96h > > Recent Transactions of the self-service user Only Displays Charges but It > should show savings and loan transitions too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-580) Dashboard summary
[ https://issues.apache.org/jira/browse/FINERACT-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-580: -- Fix Version/s: 3.0.0 (was: 1.9.0) > Dashboard summary > - > > Key: FINERACT-580 > URL: https://issues.apache.org/jira/browse/FINERACT-580 > Project: Apache Fineract > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: sangamesh >Priority: Major > Labels: GSOC, appears-unactionable, p1 > Fix For: 3.0.0 > > > Dashboard summary- Dashboard is not working as expected it doesn't show's up > the values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-580) Dashboard summary
[ https://issues.apache.org/jira/browse/FINERACT-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762211#comment-17762211 ] Ed Cable commented on FINERACT-580: --- [~bgowda] Will Pushpendra's work around Apache Superset negate the need for this enhancement? > Dashboard summary > - > > Key: FINERACT-580 > URL: https://issues.apache.org/jira/browse/FINERACT-580 > Project: Apache Fineract > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: sangamesh >Priority: Major > Labels: GSOC, appears-unactionable, p1 > Fix For: 3.0.0 > > > Dashboard summary- Dashboard is not working as expected it doesn't show's up > the values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-535) Allow the same name of teller if its from different branchs
[ https://issues.apache.org/jira/browse/FINERACT-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-535: -- Labels: features gci gsoc p1 (was: GCI-2019 features gci gsoc p1) > Allow the same name of teller if its from different branchs > --- > > Key: FINERACT-535 > URL: https://issues.apache.org/jira/browse/FINERACT-535 > Project: Apache Fineract > Issue Type: Improvement > Components: Organization >Affects Versions: 1.8.0 >Reporter: Mexina Daniel >Priority: Major > Labels: features, gci, gsoc, p1 > Fix For: 3.0.0 > > > For now when you create a teller with the name which already exist even from > another branch it gives an error of duplicate name > Think of the institution which have the same format of naming its tellers > like Teller1, Teller2, etc > and it has two branches. > The system should allow to create Teller1 of branch1 and Teller1 of branch2. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-535) Allow the same name of teller if its from different branchs
[ https://issues.apache.org/jira/browse/FINERACT-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-535: -- Fix Version/s: 3.0.0 (was: 1.9.0) > Allow the same name of teller if its from different branchs > --- > > Key: FINERACT-535 > URL: https://issues.apache.org/jira/browse/FINERACT-535 > Project: Apache Fineract > Issue Type: Improvement > Components: Organization >Affects Versions: 1.8.0 >Reporter: Mexina Daniel >Priority: Major > Labels: GCI-2019, features, gci, gsoc, p1 > Fix For: 3.0.0 > > > For now when you create a teller with the name which already exist even from > another branch it gives an error of duplicate name > Think of the institution which have the same format of naming its tellers > like Teller1, Teller2, etc > and it has two branches. > The system should allow to create Teller1 of branch1 and Teller1 of branch2. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-513) Reverse Overdue Charges Application
[ https://issues.apache.org/jira/browse/FINERACT-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-513: -- Labels: Triage external gsoc p1 (was: external gsoc p1) > Reverse Overdue Charges Application > --- > > Key: FINERACT-513 > URL: https://issues.apache.org/jira/browse/FINERACT-513 > Project: Apache Fineract > Issue Type: Improvement > Components: Charges, Loan, System >Affects Versions: 1.8.0 >Reporter: Adriana Pinto >Priority: Major > Labels: Triage, external, gsoc, p1 > Fix For: 3.0.0 > > Attachments: FINERACT-513.pdf > > > We've been working on having a complete functionality of our approach, but we > got an issue at the moment of applying overdue charges when running the job: > Is there any workaround to reverse the overdue charges application? > This is necessary, because the overdue charges are being applied daily, but > if the repayment is made before applying the charges, but it is not > registered at the system, we need to reverse the calculation and "remove" > this charges from the final outstanding. > +*Current Business behaviour*+: When the client makes a repayment, it might > not be registered in the system until some days or weeks later, then the > overdue charges if are applied daily, have to be reversed from de current > date until the date the repayment was done. > Then, it is the approach we are looking for. > We had already figured out the "Waiving charges" process, but it would work > better if there was a job doing the contrary process of applying overdue > charges, like "Reverse overdue charges" by date or any moment in a specified > time. > **The attachment (FINERACT-513.pdf) shows the funtionality in a more specific > way. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-513) Reverse Overdue Charges Application
[ https://issues.apache.org/jira/browse/FINERACT-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762210#comment-17762210 ] Ed Cable commented on FINERACT-513: --- [~bgowda] Is this still a needed enhancement? > Reverse Overdue Charges Application > --- > > Key: FINERACT-513 > URL: https://issues.apache.org/jira/browse/FINERACT-513 > Project: Apache Fineract > Issue Type: Improvement > Components: Charges, Loan, System >Affects Versions: 1.8.0 >Reporter: Adriana Pinto >Priority: Major > Labels: external, gsoc, p1 > Fix For: 3.0.0 > > Attachments: FINERACT-513.pdf > > > We've been working on having a complete functionality of our approach, but we > got an issue at the moment of applying overdue charges when running the job: > Is there any workaround to reverse the overdue charges application? > This is necessary, because the overdue charges are being applied daily, but > if the repayment is made before applying the charges, but it is not > registered at the system, we need to reverse the calculation and "remove" > this charges from the final outstanding. > +*Current Business behaviour*+: When the client makes a repayment, it might > not be registered in the system until some days or weeks later, then the > overdue charges if are applied daily, have to be reversed from de current > date until the date the repayment was done. > Then, it is the approach we are looking for. > We had already figured out the "Waiving charges" process, but it would work > better if there was a job doing the contrary process of applying overdue > charges, like "Reverse overdue charges" by date or any moment in a specified > time. > **The attachment (FINERACT-513.pdf) shows the funtionality in a more specific > way. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-513) Reverse Overdue Charges Application
[ https://issues.apache.org/jira/browse/FINERACT-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-513: -- Fix Version/s: 3.0.0 (was: 1.9.0) > Reverse Overdue Charges Application > --- > > Key: FINERACT-513 > URL: https://issues.apache.org/jira/browse/FINERACT-513 > Project: Apache Fineract > Issue Type: Improvement > Components: Charges, Loan, System >Affects Versions: 1.8.0 >Reporter: Adriana Pinto >Priority: Major > Labels: external, gsoc, p1 > Fix For: 3.0.0 > > Attachments: FINERACT-513.pdf > > > We've been working on having a complete functionality of our approach, but we > got an issue at the moment of applying overdue charges when running the job: > Is there any workaround to reverse the overdue charges application? > This is necessary, because the overdue charges are being applied daily, but > if the repayment is made before applying the charges, but it is not > registered at the system, we need to reverse the calculation and "remove" > this charges from the final outstanding. > +*Current Business behaviour*+: When the client makes a repayment, it might > not be registered in the system until some days or weeks later, then the > overdue charges if are applied daily, have to be reversed from de current > date until the date the repayment was done. > Then, it is the approach we are looking for. > We had already figured out the "Waiving charges" process, but it would work > better if there was a job doing the contrary process of applying overdue > charges, like "Reverse overdue charges" by date or any moment in a specified > time. > **The attachment (FINERACT-513.pdf) shows the funtionality in a more specific > way. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-520) The field for "is staff" in the client creation does not store data
[ https://issues.apache.org/jira/browse/FINERACT-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-520: -- Labels: Triage Volunteer client gsoc p2 (was: 2019-mifos-gsoc Volunteer client gsoc p2) > The field for "is staff" in the client creation does not store data > > > Key: FINERACT-520 > URL: https://issues.apache.org/jira/browse/FINERACT-520 > Project: Apache Fineract > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Mexina Daniel >Priority: Major > Labels: Triage, Volunteer, client, gsoc, p2 > Fix For: 3.0.0 > > > When you create a client and select the field "is staff", it is selected but > after submission and come again to edit, you find the field not selected, > which shows the value was not stored. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-520) The field for "is staff" in the client creation does not store data
[ https://issues.apache.org/jira/browse/FINERACT-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762209#comment-17762209 ] Ed Cable commented on FINERACT-520: --- [~bgowda] Is this still a reproducible issue? I added the Triage lable and changed the fix version to 3.0.0. > The field for "is staff" in the client creation does not store data > > > Key: FINERACT-520 > URL: https://issues.apache.org/jira/browse/FINERACT-520 > Project: Apache Fineract > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Mexina Daniel >Priority: Major > Labels: 2019-mifos-gsoc, Volunteer, client, gsoc, p2 > Fix For: 1.9.0 > > > When you create a client and select the field "is staff", it is selected but > after submission and come again to edit, you find the field not selected, > which shows the value was not stored. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-520) The field for "is staff" in the client creation does not store data
[ https://issues.apache.org/jira/browse/FINERACT-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-520: -- Fix Version/s: 3.0.0 (was: 1.9.0) > The field for "is staff" in the client creation does not store data > > > Key: FINERACT-520 > URL: https://issues.apache.org/jira/browse/FINERACT-520 > Project: Apache Fineract > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: Mexina Daniel >Priority: Major > Labels: 2019-mifos-gsoc, Volunteer, client, gsoc, p2 > Fix For: 3.0.0 > > > When you create a client and select the field "is staff", it is selected but > after submission and come again to edit, you find the field not selected, > which shows the value was not stored. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-528) After taking survey for a client, Survey is displaying score of each question in stead of total score of each survey
[ https://issues.apache.org/jira/browse/FINERACT-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-528: -- Labels: Volunteer beginner p1 (was: 2019-mifos-gsoc Volunteer beginner p1) > After taking survey for a client, Survey is displaying score of each question > in stead of total score of each survey > > > Key: FINERACT-528 > URL: https://issues.apache.org/jira/browse/FINERACT-528 > Project: Apache Fineract > Issue Type: Improvement > Components: Client, Surveys >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Major > Labels: Volunteer, beginner, p1 > Fix For: 1.9.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-528) After taking survey for a client, Survey is displaying score of each question in stead of total score of each survey
[ https://issues.apache.org/jira/browse/FINERACT-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-528: -- Fix Version/s: 3.0.0 (was: 1.9.0) > After taking survey for a client, Survey is displaying score of each question > in stead of total score of each survey > > > Key: FINERACT-528 > URL: https://issues.apache.org/jira/browse/FINERACT-528 > Project: Apache Fineract > Issue Type: Improvement > Components: Client, Surveys >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Major > Labels: Volunteer, beginner, p1 > Fix For: 3.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-302) Principal Threshold (%) for Last Installment is not working as expected
[ https://issues.apache.org/jira/browse/FINERACT-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762208#comment-17762208 ] Ed Cable commented on FINERACT-302: --- [~bgowda] Are you able to verify that this is still a reproducible issue? > Principal Threshold (%) for Last Installment is not working as expected > --- > > Key: FINERACT-302 > URL: https://issues.apache.org/jira/browse/FINERACT-302 > Project: Apache Fineract > Issue Type: Bug > Components: Loan >Reporter: Santosh Math >Assignee: Nayan Ambali >Priority: Major > Labels: Triage, Volunteer, fineract-gci, gsoc, p1 > Fix For: 3.0.0 > > Attachments: Scr-664.png, Screenshot from 2018-12-23 22-13-02.png, > Screenshot from 2018-12-23 22-14-34.png > > > Reported by Subramanya at https://mifosforge.jira.com/browse/MIFOSX-2031 > Original Desription: > 1. Create loan product with out mentioning any thing in the "Principal > Threshold (%) for Last Instalment" - by default it is getting set to zero > Instead it should get set to 50% > 2, Create a client and submit new loan application wit the above mentioned > loan product on 01 Jan 2015 with interest recalculation -> Approve and > disburse on same date. > 3. The last installment is getting collected more amount than EMI. > If the "Principal Threshold (%) for Last Instalment" is set to zero then then > the last installment should never be combined with the previous installment > even if the last installment amount is of a very small value. > But here it is displaying the amount>last installment amount -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-302) Principal Threshold (%) for Last Installment is not working as expected
[ https://issues.apache.org/jira/browse/FINERACT-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-302: -- Labels: Triage Volunteer fineract-gci gsoc p1 (was: Volunteer fineract-gci gsoc p1) > Principal Threshold (%) for Last Installment is not working as expected > --- > > Key: FINERACT-302 > URL: https://issues.apache.org/jira/browse/FINERACT-302 > Project: Apache Fineract > Issue Type: Bug > Components: Loan >Reporter: Santosh Math >Assignee: Nayan Ambali >Priority: Major > Labels: Triage, Volunteer, fineract-gci, gsoc, p1 > Fix For: 1.9.0 > > Attachments: Scr-664.png, Screenshot from 2018-12-23 22-13-02.png, > Screenshot from 2018-12-23 22-14-34.png > > > Reported by Subramanya at https://mifosforge.jira.com/browse/MIFOSX-2031 > Original Desription: > 1. Create loan product with out mentioning any thing in the "Principal > Threshold (%) for Last Instalment" - by default it is getting set to zero > Instead it should get set to 50% > 2, Create a client and submit new loan application wit the above mentioned > loan product on 01 Jan 2015 with interest recalculation -> Approve and > disburse on same date. > 3. The last installment is getting collected more amount than EMI. > If the "Principal Threshold (%) for Last Instalment" is set to zero then then > the last installment should never be combined with the previous installment > even if the last installment amount is of a very small value. > But here it is displaying the amount>last installment amount -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-302) Principal Threshold (%) for Last Installment is not working as expected
[ https://issues.apache.org/jira/browse/FINERACT-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-302: -- Fix Version/s: 3.0.0 (was: 1.9.0) > Principal Threshold (%) for Last Installment is not working as expected > --- > > Key: FINERACT-302 > URL: https://issues.apache.org/jira/browse/FINERACT-302 > Project: Apache Fineract > Issue Type: Bug > Components: Loan >Reporter: Santosh Math >Assignee: Nayan Ambali >Priority: Major > Labels: Triage, Volunteer, fineract-gci, gsoc, p1 > Fix For: 3.0.0 > > Attachments: Scr-664.png, Screenshot from 2018-12-23 22-13-02.png, > Screenshot from 2018-12-23 22-14-34.png > > > Reported by Subramanya at https://mifosforge.jira.com/browse/MIFOSX-2031 > Original Desription: > 1. Create loan product with out mentioning any thing in the "Principal > Threshold (%) for Last Instalment" - by default it is getting set to zero > Instead it should get set to 50% > 2, Create a client and submit new loan application wit the above mentioned > loan product on 01 Jan 2015 with interest recalculation -> Approve and > disburse on same date. > 3. The last installment is getting collected more amount than EMI. > If the "Principal Threshold (%) for Last Instalment" is set to zero then then > the last installment should never be combined with the previous installment > even if the last installment amount is of a very small value. > But here it is displaying the amount>last installment amount -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-440) Include runningBalance, appUser in m_share_account_transactions table.
[ https://issues.apache.org/jira/browse/FINERACT-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-440: -- Fix Version/s: 3.0.0 (was: 1.9.0) > Include runningBalance, appUser in m_share_account_transactions table. > -- > > Key: FINERACT-440 > URL: https://issues.apache.org/jira/browse/FINERACT-440 > Project: Apache Fineract > Issue Type: Improvement > Components: Shares >Affects Versions: 1.8.0 >Reporter: Ippez Roberts >Priority: Major > Labels: Volunteer, gci, gsoc, p2 > Fix For: 3.0.0 > > > Include the two parameters runningBalance, appUser in > m_share_account_transactions to be used to generate Share Transaction > Statement. Currently its not posible to generate standard statement since > runningBalance is missing and kind of hard to determine it from current Share > Transaction table -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-274) Not able to create the same datatable which was rejected by the maker checker before
[ https://issues.apache.org/jira/browse/FINERACT-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-274: -- Fix Version/s: (was: 1.9.0) > Not able to create the same datatable which was rejected by the maker checker > before > > > Key: FINERACT-274 > URL: https://issues.apache.org/jira/browse/FINERACT-274 > Project: Apache Fineract > Issue Type: Bug > Components: Data Tables >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Minor > Labels: 2019-mifos-gsoc, GCI-2019, Triage, gsoc, p2 > Attachments: JIRA-274.JPG > > > Posted by Subramanya at [https://mifosforge.jira.com/browse/MIFOSX-1246] > Original Description: > 1. Click on Admin ->System - enable maker-checker. > 2. Click on Admin ->System - Configure maker-checker tasks -> Select > Configurations ->select check box for create, update and delete data tables. > 3. Click on the Admin -> System -> Manage data tables -> Create data table - > and create data table for client. > 4. The navigated page displays "Waiting For Checker Approval" -> Click on > details -> Click on reject button in "View Checker Inbox" -> click on confirm > in confirmation page. > With the above action in UI the data table will not appear, but in the > database the table is still exist. > > Again try to create datable with the same name as above, which displays > error message as the data table already exists, -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-440) Include runningBalance, appUser in m_share_account_transactions table.
[ https://issues.apache.org/jira/browse/FINERACT-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-440: -- Labels: Volunteer gci gsoc p2 (was: 2019-mifos-gsoc Volunteer gci gsoc p2) > Include runningBalance, appUser in m_share_account_transactions table. > -- > > Key: FINERACT-440 > URL: https://issues.apache.org/jira/browse/FINERACT-440 > Project: Apache Fineract > Issue Type: Improvement > Components: Shares >Affects Versions: 1.8.0 >Reporter: Ippez Roberts >Priority: Major > Labels: Volunteer, gci, gsoc, p2 > Fix For: 1.9.0 > > > Include the two parameters runningBalance, appUser in > m_share_account_transactions to be used to generate Share Transaction > Statement. Currently its not posible to generate standard statement since > runningBalance is missing and kind of hard to determine it from current Share > Transaction table -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-274) Not able to create the same datatable which was rejected by the maker checker before
[ https://issues.apache.org/jira/browse/FINERACT-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-274: -- Labels: Beginner Triage Volunteer gsoc p2 (was: 2019-mifos-gsoc GCI-2019 Triage gsoc p2) > Not able to create the same datatable which was rejected by the maker checker > before > > > Key: FINERACT-274 > URL: https://issues.apache.org/jira/browse/FINERACT-274 > Project: Apache Fineract > Issue Type: Bug > Components: Data Tables >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Minor > Labels: Beginner, Triage, Volunteer, gsoc, p2 > Attachments: JIRA-274.JPG > > > Posted by Subramanya at [https://mifosforge.jira.com/browse/MIFOSX-1246] > Original Description: > 1. Click on Admin ->System - enable maker-checker. > 2. Click on Admin ->System - Configure maker-checker tasks -> Select > Configurations ->select check box for create, update and delete data tables. > 3. Click on the Admin -> System -> Manage data tables -> Create data table - > and create data table for client. > 4. The navigated page displays "Waiting For Checker Approval" -> Click on > details -> Click on reject button in "View Checker Inbox" -> click on confirm > in confirmation page. > With the above action in UI the data table will not appear, but in the > database the table is still exist. > > Again try to create datable with the same name as above, which displays > error message as the data table already exists, -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-274) Not able to create the same datatable which was rejected by the maker checker before
[ https://issues.apache.org/jira/browse/FINERACT-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-274: -- Fix Version/s: 3.0.0 > Not able to create the same datatable which was rejected by the maker checker > before > > > Key: FINERACT-274 > URL: https://issues.apache.org/jira/browse/FINERACT-274 > Project: Apache Fineract > Issue Type: Bug > Components: Data Tables >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Minor > Labels: Beginner, Triage, Volunteer, gsoc, p2 > Fix For: 3.0.0 > > Attachments: JIRA-274.JPG > > > Posted by Subramanya at [https://mifosforge.jira.com/browse/MIFOSX-1246] > Original Description: > 1. Click on Admin ->System - enable maker-checker. > 2. Click on Admin ->System - Configure maker-checker tasks -> Select > Configurations ->select check box for create, update and delete data tables. > 3. Click on the Admin -> System -> Manage data tables -> Create data table - > and create data table for client. > 4. The navigated page displays "Waiting For Checker Approval" -> Click on > details -> Click on reject button in "View Checker Inbox" -> click on confirm > in confirmation page. > With the above action in UI the data table will not appear, but in the > database the table is still exist. > > Again try to create datable with the same name as above, which displays > error message as the data table already exists, -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-274) Not able to create the same datatable which was rejected by the maker checker before
[ https://issues.apache.org/jira/browse/FINERACT-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-274: -- Labels: 2019-mifos-gsoc GCI-2019 Triage gsoc p2 (was: 2019-mifos-gsoc GCI-2019 gsoc p2 verify) > Not able to create the same datatable which was rejected by the maker checker > before > > > Key: FINERACT-274 > URL: https://issues.apache.org/jira/browse/FINERACT-274 > Project: Apache Fineract > Issue Type: Bug > Components: Data Tables >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Minor > Labels: 2019-mifos-gsoc, GCI-2019, Triage, gsoc, p2 > Fix For: 1.9.0 > > Attachments: JIRA-274.JPG > > > Posted by Subramanya at [https://mifosforge.jira.com/browse/MIFOSX-1246] > Original Description: > 1. Click on Admin ->System - enable maker-checker. > 2. Click on Admin ->System - Configure maker-checker tasks -> Select > Configurations ->select check box for create, update and delete data tables. > 3. Click on the Admin -> System -> Manage data tables -> Create data table - > and create data table for client. > 4. The navigated page displays "Waiting For Checker Approval" -> Click on > details -> Click on reject button in "View Checker Inbox" -> click on confirm > in confirmation page. > With the above action in UI the data table will not appear, but in the > database the table is still exist. > > Again try to create datable with the same name as above, which displays > error message as the data table already exists, -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-263) "Add Notes" for Centers permission is missing
[
https://issues.apache.org/jira/browse/FINERACT-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ed Cable updated FINERACT-263:
--
Fix Version/s: 3.0.0
(was: 1.9.0)
> "Add Notes" for Centers permission is missing
> -
>
> Key: FINERACT-263
> URL: https://issues.apache.org/jira/browse/FINERACT-263
> Project: Apache Fineract
> Issue Type: Bug
>Affects Versions: 1.8.0
>Reporter: Ed Cable
>Priority: Minor
> Labels: 2019-mifos-gsoc, GCI-2019, Volunteer, fineract-gci,
> gsoc, p2
> Fix For: 3.0.0
>
>
> Migrated over from https://mifosforge.jira.com/browse/MIFOSX-1080
> Original Description:
> Now user can add notes to centers with out permissions. Permission should be
> assigned separately for Read, Create, Edit and Delete options. See
> permissions for group for example.
> Comments
> Shashvat Tripathi Documentation for the notes API can be found at
> https://demo.openmf.org/api-docs/apiLive.htm#notes
> From a microfinance perspective, clients can be aggregated for applying Joint
> liability principles. Such a collection of clients is called a Group. Some
> organizations would want to further extend this aggregation, so you have
> collections of Groups which are called Centers etc.
> In Mifosx, Centers were originally modeled as specializations of Groups
> (centers are also stored in m_group table with level_id set to 1, the
> level_id for groups is 2), for easier use through the API though, separate
> API's were created for Centers
> https://demo.openmf.org/api-docs/apiLive.htm#centers, which are mostly
> abstraction over the Group API with new center specific permissions.
> subramanya Talks about now extending notes API to have a center specific
> abstractions (with its own permissions), so we need a new notes api which
> would look like
> centers/{centerId}/notes/{noteId}
> , also the existing group notes API i.e
> groups/{groupId}/notes
> should no longer work for centers
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (FINERACT-425) Jobs configurable by loans / savings product and office.
[ https://issues.apache.org/jira/browse/FINERACT-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-425: -- Fix Version/s: 3.0.0 (was: 1.9.0) > Jobs configurable by loans / savings product and office. > > > Key: FINERACT-425 > URL: https://issues.apache.org/jira/browse/FINERACT-425 > Project: Apache Fineract > Issue Type: Improvement > Components: Job Scheduler, Organization >Affects Versions: 1.8.0 >Reporter: Avik Ganguly >Priority: Major > Labels: Triage, features, gsoc, p2, scalability > Fix For: 3.0.0 > > > Allow saving key-value pairs against each job. Key populated in front-end can > be a free text field or an enum consisting of Loan Product / Savings Product > / Office. If pre-defined key is selected, populate corresponding list of > existing loan product / savings product / office in value field's dropdown. > The jobs can receive this key-value pair as a function parameter by setting > arguments on the jobDetailFactoryBean created in the function > createJobDetail(ScheduledJobDetail) in the class JobRegisterServiceImpl. > If the following jobs has above parameters passed to it, it should add > corresponding office/product filter where clause to its read query. > Add Accrual Transactions > Add Periodic Accrual Transactions > Add Accrual Transactions For Loans With Income Posted As Transactions > Generate Loan Loss Provisioning > Post Interest for Savings > Update Loan Summary > This feature can be made more useful with node-aware scheduler as different > nodes can be configured to perform the job for different products/offices > resulting in distribution of load. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-425) Jobs configurable by loans / savings product and office.
[ https://issues.apache.org/jira/browse/FINERACT-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762204#comment-17762204 ] Ed Cable commented on FINERACT-425: --- [~arnoldgalovics] [~bgowda] Is this still a valid enhancement request given the improvements to scheduler jobs? > Jobs configurable by loans / savings product and office. > > > Key: FINERACT-425 > URL: https://issues.apache.org/jira/browse/FINERACT-425 > Project: Apache Fineract > Issue Type: Improvement > Components: Job Scheduler, Organization >Affects Versions: 1.8.0 >Reporter: Avik Ganguly >Priority: Major > Labels: Triage, features, gsoc, p2, scalability > Fix For: 3.0.0 > > > Allow saving key-value pairs against each job. Key populated in front-end can > be a free text field or an enum consisting of Loan Product / Savings Product > / Office. If pre-defined key is selected, populate corresponding list of > existing loan product / savings product / office in value field's dropdown. > The jobs can receive this key-value pair as a function parameter by setting > arguments on the jobDetailFactoryBean created in the function > createJobDetail(ScheduledJobDetail) in the class JobRegisterServiceImpl. > If the following jobs has above parameters passed to it, it should add > corresponding office/product filter where clause to its read query. > Add Accrual Transactions > Add Periodic Accrual Transactions > Add Accrual Transactions For Loans With Income Posted As Transactions > Generate Loan Loss Provisioning > Post Interest for Savings > Update Loan Summary > This feature can be made more useful with node-aware scheduler as different > nodes can be configured to perform the job for different products/offices > resulting in distribution of load. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-425) Jobs configurable by loans / savings product and office.
[ https://issues.apache.org/jira/browse/FINERACT-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-425: -- Labels: Triage features gsoc p2 scalability (was: features gsoc p2 scalability) > Jobs configurable by loans / savings product and office. > > > Key: FINERACT-425 > URL: https://issues.apache.org/jira/browse/FINERACT-425 > Project: Apache Fineract > Issue Type: Improvement > Components: Organization >Affects Versions: 1.8.0 >Reporter: Avik Ganguly >Priority: Major > Labels: Triage, features, gsoc, p2, scalability > Fix For: 1.9.0 > > > Allow saving key-value pairs against each job. Key populated in front-end can > be a free text field or an enum consisting of Loan Product / Savings Product > / Office. If pre-defined key is selected, populate corresponding list of > existing loan product / savings product / office in value field's dropdown. > The jobs can receive this key-value pair as a function parameter by setting > arguments on the jobDetailFactoryBean created in the function > createJobDetail(ScheduledJobDetail) in the class JobRegisterServiceImpl. > If the following jobs has above parameters passed to it, it should add > corresponding office/product filter where clause to its read query. > Add Accrual Transactions > Add Periodic Accrual Transactions > Add Accrual Transactions For Loans With Income Posted As Transactions > Generate Loan Loss Provisioning > Post Interest for Savings > Update Loan Summary > This feature can be made more useful with node-aware scheduler as different > nodes can be configured to perform the job for different products/offices > resulting in distribution of load. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-425) Jobs configurable by loans / savings product and office.
[ https://issues.apache.org/jira/browse/FINERACT-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-425: -- Component/s: Job Scheduler > Jobs configurable by loans / savings product and office. > > > Key: FINERACT-425 > URL: https://issues.apache.org/jira/browse/FINERACT-425 > Project: Apache Fineract > Issue Type: Improvement > Components: Job Scheduler, Organization >Affects Versions: 1.8.0 >Reporter: Avik Ganguly >Priority: Major > Labels: Triage, features, gsoc, p2, scalability > Fix For: 1.9.0 > > > Allow saving key-value pairs against each job. Key populated in front-end can > be a free text field or an enum consisting of Loan Product / Savings Product > / Office. If pre-defined key is selected, populate corresponding list of > existing loan product / savings product / office in value field's dropdown. > The jobs can receive this key-value pair as a function parameter by setting > arguments on the jobDetailFactoryBean created in the function > createJobDetail(ScheduledJobDetail) in the class JobRegisterServiceImpl. > If the following jobs has above parameters passed to it, it should add > corresponding office/product filter where clause to its read query. > Add Accrual Transactions > Add Periodic Accrual Transactions > Add Accrual Transactions For Loans With Income Posted As Transactions > Generate Loan Loss Provisioning > Post Interest for Savings > Update Loan Summary > This feature can be made more useful with node-aware scheduler as different > nodes can be configured to perform the job for different products/offices > resulting in distribution of load. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-392) Ability to edit a self guarantor
[ https://issues.apache.org/jira/browse/FINERACT-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-392: -- Fix Version/s: 3.0.0 (was: 1.9.0) > Ability to edit a self guarantor > > > Key: FINERACT-392 > URL: https://issues.apache.org/jira/browse/FINERACT-392 > Project: Apache Fineract > Issue Type: Improvement > Components: Loan >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Minor > Labels: 2019-mifos-gsoc, Beginner, Volunteer, gsoc, verify > Fix For: 3.0.0 > > > Reported by Mexina Daniel at https://mifosforge.jira.com/browse/MIFOSX-2814 > Original Description: > When a self guarantor has been created there is a chance for a user to attach > a wrong saving account or to allocate a wrong amount. For now when that > happens you have to delete a guarantor and create again. It will be helpful > if a user can edit details of a self guarantor and be able to change deposit > account and amount. > You can see this by applying new loan then in the profile of the loan > navigate to more -> create guarantor, then create a guarantor (same client) > attach the saving account and allocate the amount and submit. Then navigate > to more -> view guarantor, there you will be able to see the guarantor with > "view" icon, "View transaction", "delete" icon . > It could be better if there was "Edit" icon too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-391) Fund Management-Delete Enhancement
[ https://issues.apache.org/jira/browse/FINERACT-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-391: -- Fix Version/s: 3.0.0 (was: 1.9.0) > Fund Management-Delete Enhancement > -- > > Key: FINERACT-391 > URL: https://issues.apache.org/jira/browse/FINERACT-391 > Project: Apache Fineract > Issue Type: Improvement > Components: Organization >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Minor > Labels: 2019-mifos-gsoc, Beginner, Volunteer, gsoc, p3 > Fix For: 3.0.0 > > > Reported by Agness Meena at https://mifosforge.jira.com/browse/MIFOSX-2822 > Go to Admin > Organization > Manage Fund > Once you create a new fund you can only edit it but not deleting it. > Need a Delete button to delete existing fund. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-392) Ability to edit a self guarantor
[ https://issues.apache.org/jira/browse/FINERACT-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-392: -- Labels: 2019-mifos-gsoc Beginner Volunteer gsoc verify (was: 2019-mifos-gsoc Volunteer gsoc verify) > Ability to edit a self guarantor > > > Key: FINERACT-392 > URL: https://issues.apache.org/jira/browse/FINERACT-392 > Project: Apache Fineract > Issue Type: Improvement > Components: Loan >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Minor > Labels: 2019-mifos-gsoc, Beginner, Volunteer, gsoc, verify > Fix For: 1.9.0 > > > Reported by Mexina Daniel at https://mifosforge.jira.com/browse/MIFOSX-2814 > Original Description: > When a self guarantor has been created there is a chance for a user to attach > a wrong saving account or to allocate a wrong amount. For now when that > happens you have to delete a guarantor and create again. It will be helpful > if a user can edit details of a self guarantor and be able to change deposit > account and amount. > You can see this by applying new loan then in the profile of the loan > navigate to more -> create guarantor, then create a guarantor (same client) > attach the saving account and allocate the amount and submit. Then navigate > to more -> view guarantor, there you will be able to see the guarantor with > "view" icon, "View transaction", "delete" icon . > It could be better if there was "Edit" icon too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-405) Client/Staff SMS phone number back-end validation, incl. default country code
[ https://issues.apache.org/jira/browse/FINERACT-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-405: -- Fix Version/s: 3.0.0 (was: 1.9.0) > Client/Staff SMS phone number back-end validation, incl. default country code > - > > Key: FINERACT-405 > URL: https://issues.apache.org/jira/browse/FINERACT-405 > Project: Apache Fineract > Issue Type: New Feature >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Trivial > Labels: gsoc, p2 > Fix For: 3.0.0 > > > Reported by [~vorburger] at https://mifosforge.jira.com/browse/MIFOSX-779 > Original Description: > We'll likely start with just using String / VARCHAR as type for SMS phone > numbers in client/staff, but in order get serious about SMS support, the > "data quality" of those will quickly be fairly import. > Therefore, it would probably be very useful if the platform technically > enforced that such phone numbers are always represented and stored in the > database including country code prefix (using the +91 ... notation). > The should also have some validation logic in the UI enforcing this > (FrontlineSMS says: "This number is not in international format. This may > cause problems matching messages to contacts."). > The UI could assist in making it easier to capture phone numbers and propose > a default country code saved in some System Administration configuration > somewhere when entering new phone numbers. > The Java back-end could use some proper strongly typed self validating > PhoneNumber value object type, instead of just passing around String? May be > something like this exists already? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-348) Issues when doing a "Close-As-Rescheduled" on a loan
[ https://issues.apache.org/jira/browse/FINERACT-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762203#comment-17762203 ] Ed Cable commented on FINERACT-348: --- [~bgowda] Do you think this is still a needed feature from the community? > Issues when doing a "Close-As-Rescheduled" on a loan > - > > Key: FINERACT-348 > URL: https://issues.apache.org/jira/browse/FINERACT-348 > Project: Apache Fineract > Issue Type: Improvement > Components: Loan >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Critical > Labels: gsoc, p2 > Fix For: 3.0.0 > > > Reported by Binny at https://mifosforge.jira.com/browse/MIFOSX-1205 > Original Description: > When closing a loan using the "Close (as Rescheduled)" button, the loan > account is closed, but there are no transactions or accounting entries made > for this closure. This not correct. > The following should be done: > 1) A new transaction should be visible to user under transactions to show > that the loan was closed as rescheduled rather than leaving the loan as is > without any changes. This means that Mifos X should mkae a new entry > m_loan_transaction table - with transaction_type_enum = 7 and amount as the > total outstanding amount (principal + interest + fees). > 2) Ensure that the right accounting entries are made when closing the loan as > "closed (as rescheduled)". This involves: > For loan products: capturing another General Ledger account head under > “Rescheduled in Suspense” – for example: “Rescheduled Loans Suspense Account” > When closing as loan as rescheduled, passing the following entries: > a) For Cash Accounting: > Debit: Rescheduled Loan Suspense Account (with only principal outstanding > amount) > Credit: Loan portfolio > b) For Accrual (upfront): > Debit: Rescheduled Loan Suspense Account (sum of outstanding principal + > interest + fees + penalties) > Credit: Loan portfolio (with principal outstanding amount) > Credit: Interest Receivable (with interest outstanding amount) > Credit: Fees Receivable (with fees outstanding amount) > Credit: Penalties Receivable (with penalties outstanding amount) > c) For Accrual (periodic): > Debit: Rescheduled Loan Suspense Account (sum of outstanding principal + > interest receivable accounted + fees receivable accounted + penalties > receivable accounted) > Credit: Loan portfolio (with principal outstanding amount) > Credit: Interest Receivable (with interest receivable accounted) > Credit: Fees Receivable (with fees receivable accounted) > Credit: Penalties Receivable (with penalties receivable accounted) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-348) Issues when doing a "Close-As-Rescheduled" on a loan
[ https://issues.apache.org/jira/browse/FINERACT-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-348: -- Labels: Triage gsoc p2 (was: gsoc p2) > Issues when doing a "Close-As-Rescheduled" on a loan > - > > Key: FINERACT-348 > URL: https://issues.apache.org/jira/browse/FINERACT-348 > Project: Apache Fineract > Issue Type: Improvement > Components: Loan >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Critical > Labels: Triage, gsoc, p2 > Fix For: 3.0.0 > > > Reported by Binny at https://mifosforge.jira.com/browse/MIFOSX-1205 > Original Description: > When closing a loan using the "Close (as Rescheduled)" button, the loan > account is closed, but there are no transactions or accounting entries made > for this closure. This not correct. > The following should be done: > 1) A new transaction should be visible to user under transactions to show > that the loan was closed as rescheduled rather than leaving the loan as is > without any changes. This means that Mifos X should mkae a new entry > m_loan_transaction table - with transaction_type_enum = 7 and amount as the > total outstanding amount (principal + interest + fees). > 2) Ensure that the right accounting entries are made when closing the loan as > "closed (as rescheduled)". This involves: > For loan products: capturing another General Ledger account head under > “Rescheduled in Suspense” – for example: “Rescheduled Loans Suspense Account” > When closing as loan as rescheduled, passing the following entries: > a) For Cash Accounting: > Debit: Rescheduled Loan Suspense Account (with only principal outstanding > amount) > Credit: Loan portfolio > b) For Accrual (upfront): > Debit: Rescheduled Loan Suspense Account (sum of outstanding principal + > interest + fees + penalties) > Credit: Loan portfolio (with principal outstanding amount) > Credit: Interest Receivable (with interest outstanding amount) > Credit: Fees Receivable (with fees outstanding amount) > Credit: Penalties Receivable (with penalties outstanding amount) > c) For Accrual (periodic): > Debit: Rescheduled Loan Suspense Account (sum of outstanding principal + > interest receivable accounted + fees receivable accounted + penalties > receivable accounted) > Credit: Loan portfolio (with principal outstanding amount) > Credit: Interest Receivable (with interest receivable accounted) > Credit: Fees Receivable (with fees receivable accounted) > Credit: Penalties Receivable (with penalties receivable accounted) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-391) Fund Management-Delete Enhancement
[ https://issues.apache.org/jira/browse/FINERACT-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-391: -- Labels: 2019-mifos-gsoc Beginner Volunteer gsoc p3 (was: 2019-mifos-gsoc Volunteer gsoc p3) > Fund Management-Delete Enhancement > -- > > Key: FINERACT-391 > URL: https://issues.apache.org/jira/browse/FINERACT-391 > Project: Apache Fineract > Issue Type: Improvement > Components: Organization >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Minor > Labels: 2019-mifos-gsoc, Beginner, Volunteer, gsoc, p3 > Fix For: 1.9.0 > > > Reported by Agness Meena at https://mifosforge.jira.com/browse/MIFOSX-2822 > Go to Admin > Organization > Manage Fund > Once you create a new fund you can only edit it but not deleting it. > Need a Delete button to delete existing fund. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-348) Issues when doing a "Close-As-Rescheduled" on a loan
[ https://issues.apache.org/jira/browse/FINERACT-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-348: -- Fix Version/s: 3.0.0 (was: 1.9.0) > Issues when doing a "Close-As-Rescheduled" on a loan > - > > Key: FINERACT-348 > URL: https://issues.apache.org/jira/browse/FINERACT-348 > Project: Apache Fineract > Issue Type: Improvement > Components: Loan >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Critical > Labels: gsoc, p2 > Fix For: 3.0.0 > > > Reported by Binny at https://mifosforge.jira.com/browse/MIFOSX-1205 > Original Description: > When closing a loan using the "Close (as Rescheduled)" button, the loan > account is closed, but there are no transactions or accounting entries made > for this closure. This not correct. > The following should be done: > 1) A new transaction should be visible to user under transactions to show > that the loan was closed as rescheduled rather than leaving the loan as is > without any changes. This means that Mifos X should mkae a new entry > m_loan_transaction table - with transaction_type_enum = 7 and amount as the > total outstanding amount (principal + interest + fees). > 2) Ensure that the right accounting entries are made when closing the loan as > "closed (as rescheduled)". This involves: > For loan products: capturing another General Ledger account head under > “Rescheduled in Suspense” – for example: “Rescheduled Loans Suspense Account” > When closing as loan as rescheduled, passing the following entries: > a) For Cash Accounting: > Debit: Rescheduled Loan Suspense Account (with only principal outstanding > amount) > Credit: Loan portfolio > b) For Accrual (upfront): > Debit: Rescheduled Loan Suspense Account (sum of outstanding principal + > interest + fees + penalties) > Credit: Loan portfolio (with principal outstanding amount) > Credit: Interest Receivable (with interest outstanding amount) > Credit: Fees Receivable (with fees outstanding amount) > Credit: Penalties Receivable (with penalties outstanding amount) > c) For Accrual (periodic): > Debit: Rescheduled Loan Suspense Account (sum of outstanding principal + > interest receivable accounted + fees receivable accounted + penalties > receivable accounted) > Credit: Loan portfolio (with principal outstanding amount) > Credit: Interest Receivable (with interest receivable accounted) > Credit: Fees Receivable (with fees receivable accounted) > Credit: Penalties Receivable (with penalties receivable accounted) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-336) Fund Mapping page Points to Advanced Search page
[ https://issues.apache.org/jira/browse/FINERACT-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-336: -- Fix Version/s: 3.0.0 (was: 1.9.0) > Fund Mapping page Points to Advanced Search page > > > Key: FINERACT-336 > URL: https://issues.apache.org/jira/browse/FINERACT-336 > Project: Apache Fineract > Issue Type: Improvement > Components: Organization >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Critical > Labels: gsoc, large, p1 > Fix For: 3.0.0 > > Attachments: fundmapping.png > > > Reported by Ed Cable at https://mifosforge.jira.com/browse/MIFOSX-2795 > Original Description: > Hi all, > I think this bug has been existent for several months now as we actually > documented it as intended functionality at > https://mifosforge.jira.com/wiki/display/docs/Fund+Mapping > If you got to Admin >> Organization >> Fund Mapping, clicking the link takes > you to > https://demo4.openmf.org/#/advsearch > rather than the intended page on fund mapping (i'm not sure which it is). > On a similar note, I don't think this advance search link is accessible from > the search menu although it should be there or in the quick links. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-336) Fund Mapping page Points to Advanced Search page
[ https://issues.apache.org/jira/browse/FINERACT-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762202#comment-17762202 ] Ed Cable commented on FINERACT-336: --- [~bgowda] Is this a front-end or back-end issue? > Fund Mapping page Points to Advanced Search page > > > Key: FINERACT-336 > URL: https://issues.apache.org/jira/browse/FINERACT-336 > Project: Apache Fineract > Issue Type: Improvement > Components: Organization >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Critical > Labels: gsoc, large, p1 > Fix For: 3.0.0 > > Attachments: fundmapping.png > > > Reported by Ed Cable at https://mifosforge.jira.com/browse/MIFOSX-2795 > Original Description: > Hi all, > I think this bug has been existent for several months now as we actually > documented it as intended functionality at > https://mifosforge.jira.com/wiki/display/docs/Fund+Mapping > If you got to Admin >> Organization >> Fund Mapping, clicking the link takes > you to > https://demo4.openmf.org/#/advsearch > rather than the intended page on fund mapping (i'm not sure which it is). > On a similar note, I don't think this advance search link is accessible from > the search menu although it should be there or in the quick links. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-314) If Tranche disbursement charge payment mode is Account transfer then after first disbursement the charge collection is improper
[ https://issues.apache.org/jira/browse/FINERACT-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-314: -- Labels: Triage gsoc p2 (was: gsoc p2) > If Tranche disbursement charge payment mode is Account transfer then after > first disbursement the charge collection is improper > --- > > Key: FINERACT-314 > URL: https://issues.apache.org/jira/browse/FINERACT-314 > Project: Apache Fineract > Issue Type: Bug > Components: Charges >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Minor > Labels: Triage, gsoc, p2 > Fix For: 1.9.0 > > Attachments: 91.png, 93.png > > > Reported by Subramanya at https://mifosforge.jira.com/browse/MIFOSX-2194 > Original Description: > 1. Create Tranche disbursement charge with Charge Payment Mode as Account > transfer. > 2. Create Tranche loan product with 2 tranches and above created charge > attached > 3. Create Savings product and create a client with active savings product > above created. > 4. For the same above client submit new loan application with the above > savings account and Tranche disbursement charge attached while submitting the > application, tranche attached on 01 August 2015 and amount is 5000, 2nd > tranche on 01 September 2015 and amount is 5000 -> Approve and disburse the > first tranche on 01 August 2015. > > In Summary page displaying as both tranche disbursement charges as due > > In Repayment schedule is displaying properly > > In Transactions page and In Charges page both Tranche disbursement charges > > are displaying as collected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-314) If Tranche disbursement charge payment mode is Account transfer then after first disbursement the charge collection is improper
[ https://issues.apache.org/jira/browse/FINERACT-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762201#comment-17762201 ] Ed Cable commented on FINERACT-314: --- [~bgowda] Is this issue still reproducible? I changed fix version to 3.0.0 and added the Triage label. > If Tranche disbursement charge payment mode is Account transfer then after > first disbursement the charge collection is improper > --- > > Key: FINERACT-314 > URL: https://issues.apache.org/jira/browse/FINERACT-314 > Project: Apache Fineract > Issue Type: Bug > Components: Charges >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Minor > Labels: Triage, gsoc, p2 > Fix For: 3.0.0 > > Attachments: 91.png, 93.png > > > Reported by Subramanya at https://mifosforge.jira.com/browse/MIFOSX-2194 > Original Description: > 1. Create Tranche disbursement charge with Charge Payment Mode as Account > transfer. > 2. Create Tranche loan product with 2 tranches and above created charge > attached > 3. Create Savings product and create a client with active savings product > above created. > 4. For the same above client submit new loan application with the above > savings account and Tranche disbursement charge attached while submitting the > application, tranche attached on 01 August 2015 and amount is 5000, 2nd > tranche on 01 September 2015 and amount is 5000 -> Approve and disburse the > first tranche on 01 August 2015. > > In Summary page displaying as both tranche disbursement charges as due > > In Repayment schedule is displaying properly > > In Transactions page and In Charges page both Tranche disbursement charges > > are displaying as collected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-307) Accruals accounting does not accrue income on loans closed prematurely
[ https://issues.apache.org/jira/browse/FINERACT-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762200#comment-17762200 ] Ed Cable commented on FINERACT-307: --- [~bgowda] Is this issue still reproducible? I changed fix version to 3.0.0 and added the Triage label. > Accruals accounting does not accrue income on loans closed prematurely > -- > > Key: FINERACT-307 > URL: https://issues.apache.org/jira/browse/FINERACT-307 > Project: Apache Fineract > Issue Type: Bug > Components: Loan >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Major > Labels: Triage, p2 > Fix For: 3.0.0 > > > Reported by Sander at https://mifosforge.jira.com/browse/MIFOSX-2093 > Original Description: > If a customer makes the final payment before the end of the loan schedule the > loan status changes to closed, and the balance reports 0, which is correct. > These loans are non-recalculating and accrue interest in line with their > schedules (periodic). As such all interest portions are booked into the > Interest Receivable account. > However because of the closed status the accruals batch job no longer > generates the periodic accruals for this loan (query excludes any status > which is not active). As a result a part of this income will remain in the > Interest receivable account indefinitely, which is not the expected > behaviour. We would either expect the accruals to continue in line with the > schedule, or for the accrual to be generated alongside the final (closing) > transaction of the loan. > The quick-fix for this is to adjust the batch job to look not just look at > loan status but also at any loan where the interest accrual date is smaller > than the expected maturity date. > As a permanent fix we should investigate whether new accounting types/rules > need to be defined for this scenario to also book this prepaid income as a > liability instead of an asset account, such as Prepaid Interest received. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-314) If Tranche disbursement charge payment mode is Account transfer then after first disbursement the charge collection is improper
[ https://issues.apache.org/jira/browse/FINERACT-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-314: -- Fix Version/s: 3.0.0 (was: 1.9.0) > If Tranche disbursement charge payment mode is Account transfer then after > first disbursement the charge collection is improper > --- > > Key: FINERACT-314 > URL: https://issues.apache.org/jira/browse/FINERACT-314 > Project: Apache Fineract > Issue Type: Bug > Components: Charges >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Minor > Labels: Triage, gsoc, p2 > Fix For: 3.0.0 > > Attachments: 91.png, 93.png > > > Reported by Subramanya at https://mifosforge.jira.com/browse/MIFOSX-2194 > Original Description: > 1. Create Tranche disbursement charge with Charge Payment Mode as Account > transfer. > 2. Create Tranche loan product with 2 tranches and above created charge > attached > 3. Create Savings product and create a client with active savings product > above created. > 4. For the same above client submit new loan application with the above > savings account and Tranche disbursement charge attached while submitting the > application, tranche attached on 01 August 2015 and amount is 5000, 2nd > tranche on 01 September 2015 and amount is 5000 -> Approve and disburse the > first tranche on 01 August 2015. > > In Summary page displaying as both tranche disbursement charges as due > > In Repayment schedule is displaying properly > > In Transactions page and In Charges page both Tranche disbursement charges > > are displaying as collected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-307) Accruals accounting does not accrue income on loans closed prematurely
[ https://issues.apache.org/jira/browse/FINERACT-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-307: -- Labels: Triage p2 (was: p2) > Accruals accounting does not accrue income on loans closed prematurely > -- > > Key: FINERACT-307 > URL: https://issues.apache.org/jira/browse/FINERACT-307 > Project: Apache Fineract > Issue Type: Bug > Components: Loan >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Major > Labels: Triage, p2 > Fix For: 1.9.0 > > > Reported by Sander at https://mifosforge.jira.com/browse/MIFOSX-2093 > Original Description: > If a customer makes the final payment before the end of the loan schedule the > loan status changes to closed, and the balance reports 0, which is correct. > These loans are non-recalculating and accrue interest in line with their > schedules (periodic). As such all interest portions are booked into the > Interest Receivable account. > However because of the closed status the accruals batch job no longer > generates the periodic accruals for this loan (query excludes any status > which is not active). As a result a part of this income will remain in the > Interest receivable account indefinitely, which is not the expected > behaviour. We would either expect the accruals to continue in line with the > schedule, or for the accrual to be generated alongside the final (closing) > transaction of the loan. > The quick-fix for this is to adjust the batch job to look not just look at > loan status but also at any loan where the interest accrual date is smaller > than the expected maturity date. > As a permanent fix we should investigate whether new accounting types/rules > need to be defined for this scenario to also book this prepaid income as a > liability instead of an asset account, such as Prepaid Interest received. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-307) Accruals accounting does not accrue income on loans closed prematurely
[ https://issues.apache.org/jira/browse/FINERACT-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-307: -- Fix Version/s: 3.0.0 (was: 1.9.0) > Accruals accounting does not accrue income on loans closed prematurely > -- > > Key: FINERACT-307 > URL: https://issues.apache.org/jira/browse/FINERACT-307 > Project: Apache Fineract > Issue Type: Bug > Components: Loan >Affects Versions: 1.8.0 >Reporter: Santosh Math >Priority: Major > Labels: Triage, p2 > Fix For: 3.0.0 > > > Reported by Sander at https://mifosforge.jira.com/browse/MIFOSX-2093 > Original Description: > If a customer makes the final payment before the end of the loan schedule the > loan status changes to closed, and the balance reports 0, which is correct. > These loans are non-recalculating and accrue interest in line with their > schedules (periodic). As such all interest portions are booked into the > Interest Receivable account. > However because of the closed status the accruals batch job no longer > generates the periodic accruals for this loan (query excludes any status > which is not active). As a result a part of this income will remain in the > Interest receivable account indefinitely, which is not the expected > behaviour. We would either expect the accruals to continue in line with the > schedule, or for the accrual to be generated alongside the final (closing) > transaction of the loan. > The quick-fix for this is to adjust the batch job to look not just look at > loan status but also at any loan where the interest accrual date is smaller > than the expected maturity date. > As a permanent fix we should investigate whether new accounting types/rules > need to be defined for this scenario to also book this prepaid income as a > liability instead of an asset account, such as Prepaid Interest received. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-26) Allow a Logo (for Organization) to be set, which will be displayed on the header
[ https://issues.apache.org/jira/browse/FINERACT-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-26: - Fix Version/s: 3.0.0 (was: 1.9.0) > Allow a Logo (for Organization) to be set, which will be displayed on the > header > > > Key: FINERACT-26 > URL: https://issues.apache.org/jira/browse/FINERACT-26 > Project: Apache Fineract > Issue Type: New Feature >Affects Versions: 1.8.0 >Reporter: Dayna Harp >Priority: Minor > Labels: 2019-mifos-gsoc, Volunteer, gsoc, p1 > Fix For: 3.0.0 > > > https://mifosforge.jira.com/browse/MIFOSX-2511 > As a Implementation Specialist, I wish to setup a logo (for the organization) > which will be displayed before the Mifos logo > As a first step : there is no user interface needed for uploading the logo. > As a second step : we can provide user interface for logo-upload > Logo can be different for different tenants (in a multi-tenant setup). > Logo should be same size as Mifos X logo - to maintain aesthetics of the > header band. > Part 2 ] While we are at it, we should probably also allow themes to be > picked on on a per tenant basis -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-26) Allow a Logo (for Organization) to be set, which will be displayed on the header
[ https://issues.apache.org/jira/browse/FINERACT-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-26: - Labels: 2019-mifos-gsoc Volunteer gsoc p1 (was: 2019-mifos-gsoc gsoc p1) > Allow a Logo (for Organization) to be set, which will be displayed on the > header > > > Key: FINERACT-26 > URL: https://issues.apache.org/jira/browse/FINERACT-26 > Project: Apache Fineract > Issue Type: New Feature >Affects Versions: 1.8.0 >Reporter: Dayna Harp >Priority: Minor > Labels: 2019-mifos-gsoc, Volunteer, gsoc, p1 > Fix For: 1.9.0 > > > https://mifosforge.jira.com/browse/MIFOSX-2511 > As a Implementation Specialist, I wish to setup a logo (for the organization) > which will be displayed before the Mifos logo > As a first step : there is no user interface needed for uploading the logo. > As a second step : we can provide user interface for logo-upload > Logo can be different for different tenants (in a multi-tenant setup). > Logo should be same size as Mifos X logo - to maintain aesthetics of the > header band. > Part 2 ] While we are at it, we should probably also allow themes to be > picked on on a per tenant basis -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-176) During allocation and settle cash for a cashier if valid inputs are not given then error message displayed as Unknown data integrity issue
[ https://issues.apache.org/jira/browse/FINERACT-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-176: -- Labels: 2019-mifos-gsoc Beginner Volunteer gsoc p3 (was: 2019-mifos-gsoc Volunteer gsoc p3) > During allocation and settle cash for a cashier if valid inputs are not given > then error message displayed as Unknown data integrity issue > -- > > Key: FINERACT-176 > URL: https://issues.apache.org/jira/browse/FINERACT-176 > Project: Apache Fineract > Issue Type: Bug > Components: Teller Module >Affects Versions: 1.8.0 >Reporter: subramanyasn >Priority: Major > Labels: 2019-mifos-gsoc, Beginner, Volunteer, gsoc, p3 > Fix For: 1.9.0 > > Attachments: AllocationorSettle cash.png > > > 1. Create teller and create a cashier for that teller. > 2. Click on allocate/settle cash > > Do not enter any values and click on submit button - > > "error.msg.teller.unknown.data.integrity.issue" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-176) During allocation and settle cash for a cashier if valid inputs are not given then error message displayed as Unknown data integrity issue
[ https://issues.apache.org/jira/browse/FINERACT-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-176: -- Component/s: Teller Module > During allocation and settle cash for a cashier if valid inputs are not given > then error message displayed as Unknown data integrity issue > -- > > Key: FINERACT-176 > URL: https://issues.apache.org/jira/browse/FINERACT-176 > Project: Apache Fineract > Issue Type: Bug > Components: Teller Module >Affects Versions: 1.8.0 >Reporter: subramanyasn >Priority: Major > Labels: 2019-mifos-gsoc, Volunteer, gsoc, p3 > Fix For: 1.9.0 > > Attachments: AllocationorSettle cash.png > > > 1. Create teller and create a cashier for that teller. > 2. Click on allocate/settle cash > > Do not enter any values and click on submit button - > > "error.msg.teller.unknown.data.integrity.issue" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-176) During allocation and settle cash for a cashier if valid inputs are not given then error message displayed as Unknown data integrity issue
[ https://issues.apache.org/jira/browse/FINERACT-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-176: -- Fix Version/s: 3.0.0 (was: 1.9.0) > During allocation and settle cash for a cashier if valid inputs are not given > then error message displayed as Unknown data integrity issue > -- > > Key: FINERACT-176 > URL: https://issues.apache.org/jira/browse/FINERACT-176 > Project: Apache Fineract > Issue Type: Bug > Components: Teller Module >Affects Versions: 1.8.0 >Reporter: subramanyasn >Priority: Major > Labels: 2019-mifos-gsoc, Beginner, Volunteer, gsoc, p3 > Fix For: 3.0.0 > > Attachments: AllocationorSettle cash.png > > > 1. Create teller and create a cashier for that teller. > 2. Click on allocate/settle cash > > Do not enter any values and click on submit button - > > "error.msg.teller.unknown.data.integrity.issue" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-225) If Loan rescheduling page is submitted with out checking any checkboxes then error message displayed is not proper
[ https://issues.apache.org/jira/browse/FINERACT-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761885#comment-17761885 ] Ed Cable commented on FINERACT-225: --- [~bgowda] we should see if this is still reproducible. > If Loan rescheduling page is submitted with out checking any checkboxes then > error message displayed is not proper > -- > > Key: FINERACT-225 > URL: https://issues.apache.org/jira/browse/FINERACT-225 > Project: Apache Fineract > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: subramanyasn >Priority: Minor > Labels: 2019-mifos-gsoc, GCI-2019, Triage, Volunteer, gsoc, p2 > Fix For: 3.0.0 > > Attachments: Reschedule loan.png > > > Error message displayed as > "validation.msg.rescheduleloan.graceOnPrincipal.cannot.be.blank" if no check > box is checked. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-225) If Loan rescheduling page is submitted with out checking any checkboxes then error message displayed is not proper
[ https://issues.apache.org/jira/browse/FINERACT-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-225: -- Labels: 2019-mifos-gsoc GCI-2019 Triage Volunteer gsoc p2 (was: 2019-mifos-gsoc GCI-2019 Volunteer gsoc p2) > If Loan rescheduling page is submitted with out checking any checkboxes then > error message displayed is not proper > -- > > Key: FINERACT-225 > URL: https://issues.apache.org/jira/browse/FINERACT-225 > Project: Apache Fineract > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: subramanyasn >Priority: Minor > Labels: 2019-mifos-gsoc, GCI-2019, Triage, Volunteer, gsoc, p2 > Fix For: 1.9.0 > > Attachments: Reschedule loan.png > > > Error message displayed as > "validation.msg.rescheduleloan.graceOnPrincipal.cannot.be.blank" if no check > box is checked. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-225) If Loan rescheduling page is submitted with out checking any checkboxes then error message displayed is not proper
[ https://issues.apache.org/jira/browse/FINERACT-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-225: -- Fix Version/s: 3.0.0 (was: 1.9.0) > If Loan rescheduling page is submitted with out checking any checkboxes then > error message displayed is not proper > -- > > Key: FINERACT-225 > URL: https://issues.apache.org/jira/browse/FINERACT-225 > Project: Apache Fineract > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: subramanyasn >Priority: Minor > Labels: 2019-mifos-gsoc, GCI-2019, Triage, Volunteer, gsoc, p2 > Fix For: 3.0.0 > > Attachments: Reschedule loan.png > > > Error message displayed as > "validation.msg.rescheduleloan.graceOnPrincipal.cannot.be.blank" if no check > box is checked. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-231) Error message displayed is not proper if the valid Center/Group is not selected for generation of collection sheet
[ https://issues.apache.org/jira/browse/FINERACT-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-231: -- Labels: 2019-mifos-gsoc Triage Volunteer gsoc p2 (was: 2019-mifos-gsoc Volunteer gsoc p2) > Error message displayed is not proper if the valid Center/Group is not > selected for generation of collection sheet > -- > > Key: FINERACT-231 > URL: https://issues.apache.org/jira/browse/FINERACT-231 > Project: Apache Fineract > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: subramanyasn >Priority: Minor > Labels: 2019-mifos-gsoc, Triage, Volunteer, gsoc, p2 > Fix For: 1.9.0 > > > 1. Create a loan product, Create a Center and attache Group to it, Attache > weekly meeting from 01 June 2016 on friday. > 2. Create a client under above group and attache JLG loan on 01 June 2016 > with synk repayment with meeting. > 3. Approve and disburse the loan > 4. Click on the collection sheet and enter meeting calendar as 10 June 2016 > and click on generate collection sheet, > error message displayed as "Collection sheet cannot be generated for > center/group without attach meeting define" though the meting date is valid. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-231) Error message displayed is not proper if the valid Center/Group is not selected for generation of collection sheet
[ https://issues.apache.org/jira/browse/FINERACT-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-231: -- Fix Version/s: 3.0.0 (was: 1.9.0) > Error message displayed is not proper if the valid Center/Group is not > selected for generation of collection sheet > -- > > Key: FINERACT-231 > URL: https://issues.apache.org/jira/browse/FINERACT-231 > Project: Apache Fineract > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: subramanyasn >Priority: Minor > Labels: 2019-mifos-gsoc, Triage, Volunteer, gsoc, p2 > Fix For: 3.0.0 > > > 1. Create a loan product, Create a Center and attache Group to it, Attache > weekly meeting from 01 June 2016 on friday. > 2. Create a client under above group and attache JLG loan on 01 June 2016 > with synk repayment with meeting. > 3. Approve and disburse the loan > 4. Click on the collection sheet and enter meeting calendar as 10 June 2016 > and click on generate collection sheet, > error message displayed as "Collection sheet cannot be generated for > center/group without attach meeting define" though the meting date is valid. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-231) Error message displayed is not proper if the valid Center/Group is not selected for generation of collection sheet
[ https://issues.apache.org/jira/browse/FINERACT-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761883#comment-17761883 ] Ed Cable commented on FINERACT-231: --- [~bgowda] Do we know if this issue is still reproducible? > Error message displayed is not proper if the valid Center/Group is not > selected for generation of collection sheet > -- > > Key: FINERACT-231 > URL: https://issues.apache.org/jira/browse/FINERACT-231 > Project: Apache Fineract > Issue Type: Bug >Affects Versions: 1.8.0 >Reporter: subramanyasn >Priority: Minor > Labels: 2019-mifos-gsoc, Volunteer, gsoc, p2 > Fix For: 1.9.0 > > > 1. Create a loan product, Create a Center and attache Group to it, Attache > weekly meeting from 01 June 2016 on friday. > 2. Create a client under above group and attache JLG loan on 01 June 2016 > with synk repayment with meeting. > 3. Approve and disburse the loan > 4. Click on the collection sheet and enter meeting calendar as 10 June 2016 > and click on generate collection sheet, > error message displayed as "Collection sheet cannot be generated for > center/group without attach meeting define" though the meting date is valid. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-254) Add the Ability to Customize the Password Email Notice
[ https://issues.apache.org/jira/browse/FINERACT-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-254: -- Fix Version/s: 3.0.0 (was: 1.9.0) > Add the Ability to Customize the Password Email Notice > -- > > Key: FINERACT-254 > URL: https://issues.apache.org/jira/browse/FINERACT-254 > Project: Apache Fineract > Issue Type: Improvement >Affects Versions: 1.8.0 >Reporter: Dayna Harp >Priority: Major > Labels: Volunteer, gsoc, p2 > Fix For: 3.0.0 > > > While requesting documentation be written to describe how an organization can > customize the outgoing message to the user that provides their password, it > was discovered that this is hard coded. > https://mifosforge.jira.com/browse/MXD-107 > The expected result is that an organization can enter their own subject line, > and edit the message. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-248) Two or more SMS Campaigns should not have the same Name.
[ https://issues.apache.org/jira/browse/FINERACT-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-248: -- Fix Version/s: 3.0.0 (was: 1.9.0) > Two or more SMS Campaigns should not have the same Name. > - > > Key: FINERACT-248 > URL: https://issues.apache.org/jira/browse/FINERACT-248 > Project: Apache Fineract > Issue Type: Bug > Components: Organization >Affects Versions: 1.8.0 > Environment: Creating SMS campaign >Reporter: Santosh Math >Priority: Minor > Labels: 2019-mifos-gsoc, Volunteer, beginner, gsoc, p2, technical > Fix For: 3.0.0 > > > When we create new SMS campaign and if we give same name of existing SMS > campaign, it accepts the name. SMS Campaigns should not accept the same name. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-13) Multi-tranche Loan repayment on 2nd tranche incorrect
[ https://issues.apache.org/jira/browse/FINERACT-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-13: - Fix Version/s: 3.0.0 (was: 1.9.0) > Multi-tranche Loan repayment on 2nd tranche incorrect > - > > Key: FINERACT-13 > URL: https://issues.apache.org/jira/browse/FINERACT-13 > Project: Apache Fineract > Issue Type: Bug > Components: Loan >Affects Versions: 1.8.0 >Reporter: Dayna Harp >Priority: Major > Labels: Volunteer, gsoc, p1, triage > Fix For: 3.0.0 > > Original Estimate: 10h > Remaining Estimate: 10h > > https://mifosforge.jira.com/browse/MIFOSX-2398 - See for attachments > 1. Create a loan product with following data sets, > Principal:10,000 ( Min: , Max : ) > Number of Repayments: 12 ( Min: , Max) > Repay Every: 1 Months > Nominal Interest Rate:1 ( Min: , Max) Per month > Amortization Equal installments > Interest Method Declining Balance > Interest Calculation Period Daily > Repayment StrategyPenalties, Fees, Interest, Principal order > Days in year Actual > Days in month Actual > Principal Threshold (%) for Last Instalment 0 > 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-Sep-15 > Enable Multiple DisbursalsTRUE > Maximum Tranche count 2 > Maximum allowed outstanding balance 1 > 2. Create specified due date charge 1% of amount and attache to the above > loan product, > 3. Submit new loan application for a client on 01 September 2015 with first > tranche of 5000 on same date and second tranche on 01 November 2015 and > amount 5000. Add specified due date charge date as 15 September 2015. > 4. Make repayment on 01 October 2015 in which charge applied on 15 September > 2015 got collected and amount as 50 (1% of disbursed amount). > 5. Disburse 2nd tranche as 5000 on 01 November 2015. > > In the repayment schedule 50 is displaying as balance in 01 October 2015 > > repayment. > > Application Should not allowed to modify or apply charge for the repayment > > which is already paid -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FINERACT-13) Multi-tranche Loan repayment on 2nd tranche incorrect
[ https://issues.apache.org/jira/browse/FINERACT-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-13: - Labels: Volunteer gsoc p1 triage (was: Volunteer gsoc p1) > Multi-tranche Loan repayment on 2nd tranche incorrect > - > > Key: FINERACT-13 > URL: https://issues.apache.org/jira/browse/FINERACT-13 > Project: Apache Fineract > Issue Type: Bug > Components: Loan >Affects Versions: 1.8.0 >Reporter: Dayna Harp >Priority: Major > Labels: Volunteer, gsoc, p1, triage > Fix For: 1.9.0 > > Original Estimate: 10h > Remaining Estimate: 10h > > https://mifosforge.jira.com/browse/MIFOSX-2398 - See for attachments > 1. Create a loan product with following data sets, > Principal:10,000 ( Min: , Max : ) > Number of Repayments: 12 ( Min: , Max) > Repay Every: 1 Months > Nominal Interest Rate:1 ( Min: , Max) Per month > Amortization Equal installments > Interest Method Declining Balance > Interest Calculation Period Daily > Repayment StrategyPenalties, Fees, Interest, Principal order > Days in year Actual > Days in month Actual > Principal Threshold (%) for Last Instalment 0 > 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-Sep-15 > Enable Multiple DisbursalsTRUE > Maximum Tranche count 2 > Maximum allowed outstanding balance 1 > 2. Create specified due date charge 1% of amount and attache to the above > loan product, > 3. Submit new loan application for a client on 01 September 2015 with first > tranche of 5000 on same date and second tranche on 01 November 2015 and > amount 5000. Add specified due date charge date as 15 September 2015. > 4. Make repayment on 01 October 2015 in which charge applied on 15 September > 2015 got collected and amount as 50 (1% of disbursed amount). > 5. Disburse 2nd tranche as 5000 on 01 November 2015. > > In the repayment schedule 50 is displaying as balance in 01 October 2015 > > repayment. > > Application Should not allowed to modify or apply charge for the repayment > > which is already paid -- 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 ] Ed Cable updated FINERACT-12: - Fix Version/s: 3.0.0 (was: 1.9.0) > 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, triage > Fix For: 3.0.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] [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 ] Ed Cable updated FINERACT-12: - Labels: Volunteer cleanup22 gci gsoc p1 triage (was: Volunteer cleanup22 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, triage > 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=17761882#comment-17761882 ] Ed Cable commented on FINERACT-12: -- [~bgowda] Do we know if this issue is still valid? > 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] [Updated] (FINERACT-1960) Periodic Accrual Accounting for Savings product
[ https://issues.apache.org/jira/browse/FINERACT-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-1960: --- Fix Version/s: 1.9.0 > Periodic Accrual Accounting for Savings product > --- > > Key: FINERACT-1960 > URL: https://issues.apache.org/jira/browse/FINERACT-1960 > Project: Apache Fineract > Issue Type: Improvement > Components: Savings >Reporter: Bharath Gowda >Assignee: Ed Cable >Priority: Major > Fix For: 1.9.0 > > > *As a* user > *I want to* _configure periodic accural accounting for Savings products_ > *in order to* _have accural accounting journal entries for Savings accounts_ > h4. *Background and details:* > Fineract supports only cash-based accounting entries for deposit products > there is a need for accrual accounting for products > *Acceptance criteria* > # user should be able to confiugre periodic accural accounting for Savings > products > # Monetory transactions should post accrual jounral entries for savings > accounts > # Refer below wiki for complete requirement > # user should be able to configure this from the Webapp UI as well. > [https://cwiki.apache.org/confluence/display/FINERACT/Periodic+Accrual+Accounting+option+for+Deposit+Products] > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FINERACT-1908) Modular Security Architecture
[
https://issues.apache.org/jira/browse/FINERACT-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17713661#comment-17713661
]
Ed Cable commented on FINERACT-1908:
Comments from Avik:
Greetings everyone,
Please find Manoj and my thoughts on this.
{quote}BCrypt Support Module for Keycloak{quote}Good insight.
{quote}Auth-z/ RBAC / OPA{quote}
This should be the top priority after auth-n.
JWT typically is not meant to go to IAM/Keycloak for verifying the token.
Should it go to IAM just for the auth-z part?
In FINCN, permissions were published to user attributes which in turn reflected
inside the JWT making it huge.
We ran into debate on the best way to handle / publish permissions while
fitting it into user / architectural contexts (ex:- keep permissions in the
module, publish from config to Keycloak, identity/separate SDK, sidecars / fit
into k8s lifecycle events, reference OPA based implementation, bundle with
provisioner events, is Postman collection starting point acceptable for MVP,
etc. These approach points mentioned are not mutually exclusive and can be
complementary or non-complementary to each other)
{quote}Auth-n{quote}
A single auth-n mode should suffice. OIDC with JWT will nicely interoperate
with FINCN and PHEE architectures but JWT isn't a must if a better design can
be achieved.
The first two main milestones I would like to vote for is auth-n external
security module MVP and auth-z external security module MVP.
{quote}keep backwards compatibility for a couple of major releases{quote}
Should have (2nd phase or after RBAC) vote.
Suggestion to then move the old Fineract IAM code to a separate repo or remove
it from fineract to reduce Fineract technical debt?
{quote}automated tools for migration{quote}
{quote}we can migrate existing user accounts out of Fineract’s database tables
{quote}Nice to have vote.
{quote}but the tool that will be used as a third party security provider should
cover the use cases previously listed.{quote}
Food for thought on which other Keycloak (or IAM) modules can support the
security certification features mentioned by Victor without a lot of custom
code generating technical debt for Fineract. Regarding the 14 additional
points, I agree that they are must have for certifications but if we are
evaluating those considerations now, the evaluation process might take much
longer to look into Cognito, Okta, etc.
Possibly omitted items thoughts :-
* Account level permissions of who can read and write to an account (Fineract
has some loan officer related permissions and group / center related
permissions which ideally shouldn't be part of external auth-z MVP).
* Office and other entity related data visibility should be evaluated for
descoping from implementation and design or scoped for inclusion at a later
stage.
* Size of OIDC/JWT token / latency during login if it's part of the design -
some documentation on the tradeoffs thought process that went in.
> 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
[jira] [Updated] (FINERACT-1586) Reduce Boilerplate Code by Introducing lombok to Reduce getters/setters and Mapstruct to map REST DTO to Entity Objects
[ https://issues.apache.org/jira/browse/FINERACT-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-1586: --- Labels: full-time gsoc2023 mentor (was: full-time gsoc2022 mentor) > Reduce Boilerplate Code by Introducing lombok to Reduce getters/setters and > Mapstruct to map REST DTO to Entity Objects > --- > > Key: FINERACT-1586 > URL: https://issues.apache.org/jira/browse/FINERACT-1586 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Rahul Goel >Priority: Minor > Labels: full-time, gsoc2023, mentor > Fix For: 1.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] [Updated] (FINERACT-1908) Modular Security Architecture
[
https://issues.apache.org/jira/browse/FINERACT-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ed Cable updated FINERACT-1908:
---
Description:
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 name
* authorities/roles
* service name and function name that is being executed
* optional: parameters that are passed to the function
It should be possible to intercept these calls with minimal coding effort via
annotations and aspect oriented programming.
h2. Risks
TBD
h2. ETA
TBD
h2. Diagrams
!image (9).png|width=975,height=1168!
was:
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
[jira] [Updated] (FINERACT-1908) Modular Security Architecture
[
https://issues.apache.org/jira/browse/FINERACT-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ed Cable updated FINERACT-1908:
---
Attachment: image (9).png
> 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
>
>
> h2. 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 name
> * authorities/roles
> * service name and function name that is being executed
> * optional: parameters that are passed to the function
> It should be possible to intercept these calls with minimal coding effort via
>
[jira] [Updated] (FINERACT-1908) Modular Security Architecture
[
https://issues.apache.org/jira/browse/FINERACT-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ed Cable updated FINERACT-1908:
---
Description:
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 name
* authorities/roles
* service name and function name that is being executed
* optional: parameters that are passed to the function
It should be possible to intercept these calls with minimal coding effort via
annotations and aspect oriented programming.
h2. Risks
TBD
h2. ETA
TBD
h2. Diagrams
!image (9).png!
was:
h2. 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
[jira] [Updated] (FINERACT-1908) Modular Security Architecture
[
https://issues.apache.org/jira/browse/FINERACT-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ed Cable updated FINERACT-1908:
---
Description:
h2. 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 name
* authorities/roles
* service name and function name that is being executed
* optional: parameters that are passed to the function
It should be possible to intercept these calls with minimal coding effort via
annotations and aspect oriented programming.
h2. Risks
TBD
h2. ETA
TBD
h3. Diagrams
was:
h2. 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
[jira] [Created] (FINERACT-1589) Missing description across multiple API endpoints in Swagger Doc
Ed Cable created FINERACT-1589: -- Summary: Missing description across multiple API endpoints in Swagger Doc Key: FINERACT-1589 URL: https://issues.apache.org/jira/browse/FINERACT-1589 Project: Apache Fineract Issue Type: Bug Components: Docs, SDK Affects Versions: 1.6.0, 1.5.0 Reporter: Hemant Gupta Attachments: Screen Shot 2022-04-18 at 9.00.20 AM.png, Screen Shot 2022-04-18 at 9.00.29 AM.png, Screen Shot 2022-04-18 at 9.00.36 AM.png There are multiple API endpoints (refer to Table (A) below) spread across various sections, where the description of the endpoint is missing. It will look much better and more understandable if each API endpoint has its own description. As we know, the API documentation hosted at readme.io ([https://mifos.readme.io/reference/overview-1]) is fetching the endpoints from Swagger only. So, in order to fill up the missing description(s) on readme.io, correction in Swagger is very necessary. This will also help in building more easily understandable & user-friendly documentation. |*Section*|*API Endpoint Title*|*Link*| |Loan Collateral|Update a Collateral|[https://demo.fineract.dev/fineract-provider/swagger-ui/index.html#/Loan%20Collateral/updateCollateral]| |Mapping Financial Activities to Accounts|Delete a Financial Activity to Account Mapping|[https://demo.fineract.dev/fineract-provider/swagger-ui/index.html#/Mapping%20Financial%20Activities%20to%20Accounts/deleteGLAccount]| |Provisioning Entries|List all Provisioning Entries|[https://demo.fineract.dev/fineract-provider/swagger-ui/index.html#/Provisioning%20Entries/retrieveAllProvisioningEntries]| |Offices|Update Office|[https://demo.fineract.dev/fineract-provider/swagger-ui/index.html#/Offices/updateOffice]| |default|Update a Campaign|[https://demo.fineract.dev/fineract-provider/swagger-ui/index.html#/default/updateCampaign_1]| |User Generated Documents|Update a UGD|[https://demo.fineract.dev/fineract-provider/swagger-ui/index.html#/User%20Generated%20Documents/saveTemplate]| |User Generated Documents|Delete a UGD|[https://demo.fineract.dev/fineract-provider/swagger-ui/index.html#/User%20Generated%20Documents/deleteTemplate]| |Teller Cash Management|Retrieve a cashier|[https://demo.fineract.dev/fineract-provider/swagger-ui/index.html#/Teller%20Cash%20Management/findCashierData]| |Teller Cash Management|Update teller|[https://demo.fineract.dev/fineract-provider/swagger-ui/index.html#/Teller%20Cash%20Management/updateTeller]| |Teller Cash Management|Retrieve tellers|[https://demo.fineract.dev/fineract-provider/swagger-ui/index.html#/Teller%20Cash%20Management/findTeller]| |Teller Cash Management|Find Cashiers|[https://demo.fineract.dev/fineract-provider/swagger-ui/index.html#/Teller%20Cash%20Management/getCashierTemplate]| |Teller Cash Management|List Cashiers|[https://demo.fineract.dev/fineract-provider/swagger-ui/index.html#/Teller%20Cash%20Management/getCashierData_1]| |Maker Checker (or 4-eye) functionality|Delete Maker Checker Entry|[https://demo.fineract.dev/fineract-provider/swagger-ui/index.html#/Maker%20Checker%20(or%204-eye)%20functionality/deleteMakerCheckerEntry]| |Roles|Update a Role|[https://demo.fineract.dev/fineract-provider/swagger-ui/index.html#/Roles/updateRole]| |Roles|Update a Role’s Permissions|[https://demo.fineract.dev/fineract-provider/swagger-ui/index.html#/Roles/updateRolePermissions]| |Code Values|Create a Code description|[https://demo.fineract.dev/fineract-provider/swagger-ui/index.html#/Code%20Values/createCodeValue]| |Account number format|Update an Account number format|[https://demo.fineract.dev/fineract-provider/swagger-ui/index.html#/Account%20number%20format/update_1]| |Permissions|Enable/Disable Permissions for Maker Checker|[https://demo.fineract.dev/fineract-provider/swagger-ui/index.html#/Permissions/updatePermissionsDetails]| |Password preferences|Update password preferences|[https://demo.fineract.dev/fineract-provider/swagger-ui/index.html#/Password%20preferences/update_23]| |Documents|Remove a Document|[https://demo.fineract.dev/fineract-provider/swagger-ui/index.html#/Documents/deleteDocument]| |Reports|Create a Report|[https://demo.fineract.dev/fineract-provider/swagger-ui/index.html#/Reports/createReport]| |Report Mailing Jobs|Update a Report Mailing Job|[https://demo.fineract.dev/fineract-provider/swagger-ui/index.html#/Report%20Mailing%20Jobs/updateReportMailingJob]| |Spm-Surveys|Retrieve a Survey|[https://demo.fineract.dev/fineract-provider/swagger-ui/index.html#/Spm-Surveys/findSurvey]| |Spm-Surveys|List all Surveys|[https://demo.fineract.dev/fineract-provider/swagger-ui/index.html#/Spm-Surveys/fetchAllSurveys_1]| !Screen Shot 2022-04-18 at 9.00.20 AM.png! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (FINERACT-1588) Multiple POST Request(s) in Client section [Activate a Client, Reject a Client, etc.] shown under single API interface
Ed Cable created FINERACT-1588: -- Summary: Multiple POST Request(s) in Client section [Activate a Client, Reject a Client, etc.] shown under single API interface Key: FINERACT-1588 URL: https://issues.apache.org/jira/browse/FINERACT-1588 Project: Apache Fineract Issue Type: Bug Components: SDK Affects Versions: 1.6.0, 1.5.0 Reporter: Ed Cable Attachments: Screen Shot 2022-04-18 at 8.55.26 AM.png, Screen Shot 2022-04-18 at 8.55.35 AM.png As reported by [~guptahemant65] * Link to the API interface - [https://demo.fineract.dev/fineract-provider/swagger-ui/index.html#/Client/activate_1] * As you can check from the above link, there are multiple POST Requests in the Client Section that are meant for different functionalities but yet shown as a single API interface. It will look much better and more understandable if each API endpoint is shown as a different API interface. * This will also help in building more user-friendly documentation on readme.io (Link - https://dash.readme.com/project/mifos/v2.0/refs/activate_1) !Screen Shot 2022-04-18 at 8.55.26 AM.png! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (FINERACT-1572) Create a Fineract team for 1password to share common secrets
[ https://issues.apache.org/jira/browse/FINERACT-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520855#comment-17520855 ] Ed Cable commented on FINERACT-1572: I have followed the four steps noted by 1password team and invited maintainers to the account. I'll close this ticket out once we're approved and granted the license. > Create a Fineract team for 1password to share common secrets > > > Key: FINERACT-1572 > URL: https://issues.apache.org/jira/browse/FINERACT-1572 > Project: Apache Fineract > Issue Type: Task >Reporter: Aleksandar Vidakovic >Assignee: Ed Cable >Priority: Major > Fix For: 1.7.0 > > > https://github.com/1Password/1password-teams-open-source -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (FINERACT-1561) Add new tagging fields to Data Tables
Ed Cable created FINERACT-1561:
--
Summary: Add new tagging fields to Data Tables
Key: FINERACT-1561
URL: https://issues.apache.org/jira/browse/FINERACT-1561
Project: Apache Fineract
Issue Type: Improvement
Components: Data Tables
Affects Versions: 1.6.0
Reporter: Ed Cable
Fix For: 1.7.0
For retrieiving loan information for clients, we need to add additional
response parameters to the below API:
GET:
[_https://DomainName/fineract-provider/api/v1/datatables/\{datatableName}/\{loanId}?genericResultSet=true_|https://domainname/fineract-provider/api/v1/datatables/%7BdatatableName%7D/%7BloanId%7D?genericResultSet=true]
|New Parameter|Value/Amount|
|tag_added_time|column value added time stamp|
|tag_removed_time|column value modified time stamp|
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (FINERACT-1560) Enhance Retrieve loan information by Client ID API for new required response parameters
[ https://issues.apache.org/jira/browse/FINERACT-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-1560: --- Component/s: Loan > Enhance Retrieve loan information by Client ID API for new required response > parameters > --- > > Key: FINERACT-1560 > URL: https://issues.apache.org/jira/browse/FINERACT-1560 > Project: Apache Fineract > Issue Type: Improvement > Components: Loan >Affects Versions: 1.6.0 >Reporter: Ed Cable >Priority: Major > Fix For: 1.7.0 > > > For retrieving the loan information for a client, we need to enhance the > following API with additonal parameters outlined below. > +GET:+ > _https://DomainName/api/v1/loans/template?templateType=individual=1=1_ > > |New Parameter|Value/Amount| > |available_disbursement_amount|It is the difference of approved amount and > disbursed amount| > |past_due_days|No of days the loan is overdue,current date - duedate| > |next_payment_due_date|Based on the current date, need to populate the next > payment due date| > |delinquent_days|No of days the loan is in arrears, current date - > duedate-grace period| > |delinquent_date|Date the loan is in arrears, current date - duedate-grace > period| > |delinquent_amount|amount overdue after the grace period| > |last_payment_date|last repayment made date on the loan| > |last_payment_amount|last repayment amount made date on the loan| > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (FINERACT-1560) Enhance Retrieve loan information by Client ID API for new required response parameters
[
https://issues.apache.org/jira/browse/FINERACT-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ed Cable updated FINERACT-1560:
---
Description:
For retrieving the loan information for a client, we need to enhance the
following API with additonal parameters outlined below.
+GET:+
_https://DomainName/api/v1/loans/template?templateType=individual=1=1_
|New Parameter|Value/Amount|
|available_disbursement_amount|It is the difference of approved amount and
disbursed amount|
|past_due_days|No of days the loan is overdue,current date - duedate|
|next_payment_due_date|Based on the current date, need to populate the next
payment due date|
|delinquent_days|No of days the loan is in arrears, current date -
duedate-grace period|
|delinquent_date|Date the loan is in arrears, current date - duedate-grace
period|
|delinquent_amount|amount overdue after the grace period|
|last_payment_date|last repayment made date on the loan|
|last_payment_amount|last repayment amount made date on the loan|
was:
For the following API,
GET:
_[https://DomainName/fineract-provider/api/v1/loans/\|https://domainname/fineract-provider/api/v1/loans/]{loanId}?associations=all=guarantors,futureSchedule_
The loan creation response and retrieve loan information requires the following
additional parameters to be returned:
|New Parameter|Value/Amount|
|available_disbursement_amount|It is the difference of approved amount and
disbursed amount|
|past_due_days|No of days the loan is overdue,current date - duedate|
|next_payment_due_date|Based on the current date, need to populate the next
payment due date|
|delinquent_days|No of days the loan is in arrears, current date -
duedate-grace period|
|delinquent_date|Date the loan is in arrears, current date - duedate-grace
period|
|delinquent_amount|amount overdue after the grace period|
|last_payment_date|last repayment made date on the loan|
|last_payment_amount|last repayment amount made date on the loan|
> Enhance Retrieve loan information by Client ID API for new required response
> parameters
> ---
>
> Key: FINERACT-1560
> URL: https://issues.apache.org/jira/browse/FINERACT-1560
> Project: Apache Fineract
> Issue Type: Improvement
>Affects Versions: 1.6.0
>Reporter: Ed Cable
>Priority: Major
> Fix For: 1.7.0
>
>
> For retrieving the loan information for a client, we need to enhance the
> following API with additonal parameters outlined below.
> +GET:+
> _https://DomainName/api/v1/loans/template?templateType=individual=1=1_
>
> |New Parameter|Value/Amount|
> |available_disbursement_amount|It is the difference of approved amount and
> disbursed amount|
> |past_due_days|No of days the loan is overdue,current date - duedate|
> |next_payment_due_date|Based on the current date, need to populate the next
> payment due date|
> |delinquent_days|No of days the loan is in arrears, current date -
> duedate-grace period|
> |delinquent_date|Date the loan is in arrears, current date - duedate-grace
> period|
> |delinquent_amount|amount overdue after the grace period|
> |last_payment_date|last repayment made date on the loan|
> |last_payment_amount|last repayment amount made date on the loan|
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (FINERACT-1560) Enhance Retrieve loan information by Client ID API for new required response parameters
[
https://issues.apache.org/jira/browse/FINERACT-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ed Cable updated FINERACT-1560:
---
Summary: Enhance Retrieve loan information by Client ID API for new
required response parameters (was: New response parameters required for
Enhancing Retrieve loan information by Client ID API)
> Enhance Retrieve loan information by Client ID API for new required response
> parameters
> ---
>
> Key: FINERACT-1560
> URL: https://issues.apache.org/jira/browse/FINERACT-1560
> Project: Apache Fineract
> Issue Type: Improvement
>Affects Versions: 1.6.0
>Reporter: Ed Cable
>Priority: Major
> Fix For: 1.7.0
>
>
> For the following API,
> GET:
> _[https://DomainName/fineract-provider/api/v1/loans/\|https://domainname/fineract-provider/api/v1/loans/]{loanId}?associations=all=guarantors,futureSchedule_
> The loan creation response and retrieve loan information requires the
> following additional parameters to be returned:
>
> |New Parameter|Value/Amount|
> |available_disbursement_amount|It is the difference of approved amount and
> disbursed amount|
> |past_due_days|No of days the loan is overdue,current date - duedate|
> |next_payment_due_date|Based on the current date, need to populate the next
> payment due date|
> |delinquent_days|No of days the loan is in arrears, current date -
> duedate-grace period|
> |delinquent_date|Date the loan is in arrears, current date - duedate-grace
> period|
> |delinquent_amount|amount overdue after the grace period|
> |last_payment_date|last repayment made date on the loan|
> |last_payment_amount|last repayment amount made date on the loan|
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (FINERACT-1560) New response parameters required for Enhancing Retrieve loan information by Client ID API
Ed Cable created FINERACT-1560:
--
Summary: New response parameters required for Enhancing Retrieve
loan information by Client ID API
Key: FINERACT-1560
URL: https://issues.apache.org/jira/browse/FINERACT-1560
Project: Apache Fineract
Issue Type: Improvement
Affects Versions: 1.6.0
Reporter: Ed Cable
Fix For: 1.7.0
For the following API,
GET:
_[https://DomainName/fineract-provider/api/v1/loans/\|https://domainname/fineract-provider/api/v1/loans/]{loanId}?associations=all=guarantors,futureSchedule_
The loan creation response and retrieve loan information requires the following
additional parameters to be returned:
|New Parameter|Value/Amount|
|available_disbursement_amount|It is the difference of approved amount and
disbursed amount|
|past_due_days|No of days the loan is overdue,current date - duedate|
|next_payment_due_date|Based on the current date, need to populate the next
payment due date|
|delinquent_days|No of days the loan is in arrears, current date -
duedate-grace period|
|delinquent_date|Date the loan is in arrears, current date - duedate-grace
period|
|delinquent_amount|amount overdue after the grace period|
|last_payment_date|last repayment made date on the loan|
|last_payment_amount|last repayment amount made date on the loan|
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (FINERACT-1559) New response parameters required for Loan creation response/retrieve loan information API
[
https://issues.apache.org/jira/browse/FINERACT-1559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ed Cable updated FINERACT-1559:
---
Description:
For the following API,
GET:
_[https://DomainName/fineract-provider/api/v1/loans/\|https://domainname/fineract-provider/api/v1/loans/]{loanId}?associations=all=guarantors,futureSchedule_
The loan creation response and retrieve loan information requires the following
additional parameters to be returned:
|New Parameter|Value/Amount|
|available_disbursement_amount|It is the difference of approved amount and
disbursed amount|
|past_due_days|No of days the loan is overdue,current date - duedate|
|next_payment_due_date|Based on the current date, need to populate the next
payment due date|
|delinquent_days|No of days the loan is in arrears, current date -
duedate-grace period|
|delinquent_date|Date the loan is in arrears, current date - duedate-grace
period|
|delinquent_amount|amount overdue after the grace period|
|last_payment_date|last repayment made date on the loan|
|last_payment_amount|last repayment amount made date on the loan|
was:
For the following API,
GET:
_https://DomainName/fineract-provider/api/v1/loans/\{loanId}?associations=all=guarantors,futureSchedule_
The loan creation response and retrieve loan information requires the following
additional parameters to be returned:
|New Parameter|Value/Amount|
|available_disbursement_amount|It is the difference of approved amount and
disbursed amount|
|past_due_days|No of days the loan is overdue,current date - duedate|
|next_payment_due_date|Based on the current date, need to populate the next
payment due date|
|delinquent_days|No of days the loan is in arrears, current date -
duedate-grace period|
|delinquent_date|Date the loan is in arrears, current date - duedate-grace
period|
|delinquent_amount|amount overdue after the grace period|
|last_payment_date|last repayment made date on the loan|
|last_payment_amount|last repayment amount made date on the loan|
> New response parameters required for Loan creation response/retrieve loan
> information API
> --
>
> Key: FINERACT-1559
> URL: https://issues.apache.org/jira/browse/FINERACT-1559
> Project: Apache Fineract
> Issue Type: Improvement
>Affects Versions: 1.6.0
>Reporter: Ed Cable
>Priority: Major
> Fix For: 1.7.0
>
>
> For the following API,
> GET:
> _[https://DomainName/fineract-provider/api/v1/loans/\|https://domainname/fineract-provider/api/v1/loans/]{loanId}?associations=all=guarantors,futureSchedule_
> The loan creation response and retrieve loan information requires the
> following additional parameters to be returned:
>
> |New Parameter|Value/Amount|
> |available_disbursement_amount|It is the difference of approved amount and
> disbursed amount|
> |past_due_days|No of days the loan is overdue,current date - duedate|
> |next_payment_due_date|Based on the current date, need to populate the next
> payment due date|
> |delinquent_days|No of days the loan is in arrears, current date -
> duedate-grace period|
> |delinquent_date|Date the loan is in arrears, current date - duedate-grace
> period|
> |delinquent_amount|amount overdue after the grace period|
> |last_payment_date|last repayment made date on the loan|
> |last_payment_amount|last repayment amount made date on the loan|
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (FINERACT-1559) New response parameters required for Loan creation response/retrieve loan information API
Ed Cable created FINERACT-1559:
--
Summary: New response parameters required for Loan creation
response/retrieve loan information API
Key: FINERACT-1559
URL: https://issues.apache.org/jira/browse/FINERACT-1559
Project: Apache Fineract
Issue Type: Improvement
Affects Versions: 1.6.0
Reporter: Ed Cable
Fix For: 1.7.0
For the following API,
GET:
_https://DomainName/fineract-provider/api/v1/loans/\{loanId}?associations=all=guarantors,futureSchedule_
The loan creation response and retrieve loan information requires the following
additional parameters to be returned:
|New Parameter|Value/Amount|
|available_disbursement_amount|It is the difference of approved amount and
disbursed amount|
|past_due_days|No of days the loan is overdue,current date - duedate|
|next_payment_due_date|Based on the current date, need to populate the next
payment due date|
|delinquent_days|No of days the loan is in arrears, current date -
duedate-grace period|
|delinquent_date|Date the loan is in arrears, current date - duedate-grace
period|
|delinquent_amount|amount overdue after the grace period|
|last_payment_date|last repayment made date on the loan|
|last_payment_amount|last repayment amount made date on the loan|
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (FINERACT-1391) Customizable Account Number Preferences
[ https://issues.apache.org/jira/browse/FINERACT-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable reassigned FINERACT-1391: -- Assignee: Prashant Rahulkar > Customizable Account Number Preferences > --- > > Key: FINERACT-1391 > URL: https://issues.apache.org/jira/browse/FINERACT-1391 > Project: Apache Fineract > Issue Type: Improvement > Components: Savings >Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0 >Reporter: Francis Guchie >Assignee: Prashant Rahulkar >Priority: Major > Attachments: image-2021-08-26-20-20-24-111.png, > image-2021-08-26-20-23-36-531.png > > > As a user i would like to set an account prefix that is neither > SAVINGS_PRODUCT_SHORT_NAME > nor OFFICE_NAME, These 2 are limited to the fact the short name can not be > the same. > Secondly, this prefix, I would like it to be a part of the number of digits > that make the account number not an addition to the existing length of the > account number length > Image one the Setting of the preference should be like below > !image-2021-08-26-20-20-24-111.png! > > And after this is set i want to see something like this below > !image-2021-08-26-20-23-36-531.png! > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINCN-252) Machine Learning Scorecard for Credit Risk Assessment Phase 4
[ https://issues.apache.org/jira/browse/FINCN-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17394356#comment-17394356 ] Ed Cable commented on FINCN-252: Repo is now available at https://github.com/apache/fineract-credit-scorecard/ > Machine Learning Scorecard for Credit Risk Assessment Phase 4 > - > > Key: FINCN-252 > URL: https://issues.apache.org/jira/browse/FINCN-252 > Project: Fineract Cloud Native > Issue Type: Improvement >Reporter: Ed Cable >Assignee: Yemdjih Kaze Nasser >Priority: Major > Labels: gsoc2021, mentor > > h2. Mentors > * Lalit Mohan S > * [~Fintecheando] > h2. Overview & Objectives > Financial Organizations using Mifos/Fineract are depending on external > agencies or their past experiences for evaluating credit scoring and > identification of potential NPAs. Though information from external agencies > is required, financial organizations can have an internal scorecard for > evaluating loans so that preventive/proactive actions can be done along with > external agencies reports. In industry, organizations are using rule based, > Statistical and Machine learning methods for credit scoring, predicting > potential NPAs, fraud detection and other activities. This project aims to > implement a scorecard based on statistical and ML methods for credit scoring > and identification of potential NPAs. > h2. Description > The approach should factor and improve last year's GSOC work > ([https://gist.github.com/SupreethSudhakaranMenon/a20251271adb341f949dbfeb035191f7]) > on Features/Characteristics, Criteria and evaluation (link). The design and > implementation of the screens should follow Mifos Application standards. > Should implement statistical and ML methods with explainability on decision > making. Should also be extensible for adding other functionalities such as > fraud detection, cross-sell and up-sell, etc. > h2. Helpful Skills > JAVA, Integrating Backend Service, MIFOS X, Apache Fineract, AngularJS, ORM, > ML, Statistical Methods, Django > h2. Impact > Streamlined Operations, Better RISK Management, Automated Response Mechanism > h2. Other Resources > 2019 Progress: > [https://gist.github.com/SupreethSudhakaranMenon/a20251271adb341f949dbfeb035191f7] > [https://gist.github.com/lalitsanagavarapu] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (FINERACT-854) Use prepared statements instead of string concatenated SQL everywhere
[
https://issues.apache.org/jira/browse/FINERACT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ed Cable reassigned FINERACT-854:
-
Assignee: Joseph Makara
> Use prepared statements instead of string concatenated SQL everywhere
> -
>
> Key: FINERACT-854
> URL: https://issues.apache.org/jira/browse/FINERACT-854
> Project: Apache Fineract
> Issue Type: Improvement
> Components: Security
>Reporter: Michael Vorburger
>Assignee: Joseph Makara
>Priority: Major
> Labels: beginner, scalability, security, technical
> Fix For: 1.5.0
>
>
> The Fineract code base in many places creates SQL statements through String
> concatenation. This is prone to SQL injection. This is mitigated by the use
> of helpers utilities such as
> {{org.apache.fineract.infrastructure.core.api.ApiParameterHelper.sqlEncodeString(String)}}
> and
> {{org.apache.fineract.infrastructure.security.utils.SQLInjectionValidator.validateSQLInput(String)}}
> but I opine that those are workarounds... the better solution, both for
> security and likely also helping with performance (at least a little bit,
> knowing how much would require measuring it...), would be to use JDBC
> prepared statements with '?' placeholders and passing all raw arguments,
> instead of embedding them in the query String.
> FINERACT-808 root cause analysis brought this up, and I'm about to raise a PR
> for FINERACT-808 which makes a start; the goal of this issue is to use the
> new {{org.apache.fineract.infrastructure.security.utils.SQLBuilder}}
> everywhere, and eventually be able to get completely rid of
> {{ApiParameterHelper}} and {{SQLInjectionValidator}}.
> This issue should also include work to scan the code base for places where
> SQL Strings are concatenated without even using the existing helpers.
> FINERACT-853 could potentially help with that.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (FINERACT-1340) Add client IDs for self-service user in auth credentials
[
https://issues.apache.org/jira/browse/FINERACT-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ed Cable reassigned FINERACT-1340:
--
Assignee: Joseph Makara
> Add client IDs for self-service user in auth credentials
>
>
> Key: FINERACT-1340
> URL: https://issues.apache.org/jira/browse/FINERACT-1340
> Project: Apache Fineract
> Issue Type: Improvement
> Components: Client, User Management
>Affects Versions: 1.5.0
>Reporter: Joseph Makara
>Assignee: Joseph Makara
>Priority: Major
> Fix For: 1.6.0
>
> Attachments: Screenshot from 2021-04-06 13-35-31.png
>
>
> -X POST /self/authentication doesn't return a list of {{clients}} IDs
> associated with userId as documented in swagger
> !Screenshot from 2021-04-06 13-35-31.png!
>
> Request URL:
> https://mobile.mifos.io/fineract-provider/api/v1/self/authentication
> {code:java}
> curl \
> --header "Content-Type: application/json" \
> --header "Authorization: Basic c2VsZnNlcnZpY2VfaW1vYmlsZTpwYXNzd29yZA==" \
> --header "Fineract-Platform-TenantId: mobile" \
> --request POST \
> --data '{"username":"selfservice_imobile", "password":"password"}' \
> https://mobile.mifos.io/fineract-provider/api/v1/self/authentication
> --insecure
> {code}
> Returns
> {code:java}
> {
>"username":"selfservice_imobile",
>"userId":9,
>
> "base64EncodedAuthenticationKey":"c2VsZnNlcnZpY2VfaW1vYmlsZTpwYXNzd29yZA\u003d\u003d",
>"authenticated":true,
>"officeId":1,
>"officeName":"FOVISSSTE",
>"roles":[
> {
> "id":2,
> "name":"Self Service User",
> "description":"self service user role",
> "disabled":false
> }
>],
>"permissions":[
> "REPORTING_SUPER_USER",
> "ALL_FUNCTIONS_READ",
> "BYPASS_TWOFACTOR",
> "CHECKER_SUPER_USER",
> "ALL_FUNCTIONS"
>],
>"shouldRenewPassword":false,
>"isTwoFactorAuthenticationRequired":false
> }
> {code}
> Expected result
> Test:
> {code:java}
> curl \
> --header "Content-Type: application/json" \
> --header "Authorization: Basic bWFrYXJhOnBhc3N3b3Jk" \
> --header "Fineract-Platform-TenantId: default" \
> --request POST \
> --data '{"username":"makara", "password":"password"}' \
> https://xx.com.au:9443/fineract-provider/api/v1/self/authentication
> --insecure
> {code}
> Returns -
> "clients":[1] as shown in json below
> {code:java}
> {
>"username":"makara",
>"userId":6,
>"base64EncodedAuthenticationKey":"bWFrYXJhOnBhc3N3b3Jk",
>"authenticated":true,
>"officeId":1,
>"officeName":"Head Office",
>"roles":[
> {
> "id":2,
> "name":"Self Service User",
> "description":"self service user role",
> "disabled":false
> }
>],
>"permissions":[
> "ALL_FUNCTIONS"
>],
>"clients":[
> 1
>],
>"shouldRenewPassword":false,
>"isTwoFactorAuthenticationRequired":false
> }
> {code}
> Use case: I would like to
> # authenticate customer (self service user), and extract clientId from
> clients[0] SelfAuthenticationApiResourceSwagger#clients
> # use the clientId to call -> /self/clients/\{clientId}/accounts
> instead of
> a. authenticate
> b. Call -X GET /self/clients List Clients associated to the user
> c. use the clientId to call -> /self/clients/\{clientId}/accounts
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (FINERACT-969) Run OWASP zaproxy.org against Fineract (e.g. fineract.dev)
[ https://issues.apache.org/jira/browse/FINERACT-969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable reassigned FINERACT-969: - Assignee: Joseph Makara > Run OWASP zaproxy.org against Fineract (e.g. fineract.dev) > -- > > Key: FINERACT-969 > URL: https://issues.apache.org/jira/browse/FINERACT-969 > Project: Apache Fineract > Issue Type: Improvement > Components: Security >Reporter: Michael Vorburger >Assignee: Joseph Makara >Priority: Major > Attachments: fineract-api-SQLi-scan.html, fineract-url-clicked.txt, > wuifineract.html, wuifineract2.html > > > [~giorgio] in FINERACT-853 suggested to run > [https://www.zaproxy.org|https://www.zaproxy.org] against Fineract. > That sounds like a Great Idea - and may yield some interesting results and > holes worth plugging. > I this is easier to do against a public server instead of locally, then I > hereby offer https://www.fineract.dev for this purpose. As its FAQ says, > quote: _"Try to crash our demo - and if you manage, then work with us in the > open source project to make the Fineract code more scaleable and reliable!"_ > :D -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FINERACT-1334) Fineract Credit Bureau Integration Phase 4
[ https://issues.apache.org/jira/browse/FINERACT-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-1334: --- Summary: Fineract Credit Bureau Integration Phase 4 (was: Fineract Credit Bureau Integration Phase 3) > Fineract Credit Bureau Integration Phase 4 > -- > > Key: FINERACT-1334 > URL: https://issues.apache.org/jira/browse/FINERACT-1334 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Ed Cable >Priority: Major > Labels: gsoc2021, mentor > > h2. Mentors > * [~nikhilpa...@yahoo.in] > * [~rrpawar] > Nayan Ambali, Ed Cable > h2. Overview & Objectives > Because of regulatory reasons or to do background check of a client (risk > management), MFIs depend on credit bureaus. As part of it, MFI must submit > client details to credit bureau and also need to pull client information from > credit bureau before approving any new loans to a client. Apache Fineract can > be integrated with a popular CBs in India and from other regions (based on > the demand). > h2. Description > Building off the work that was kicked off in 2016, during the 2020 Google > Summer of Code, Rahul Pawar, completed the credit bureau integration module > with integrations for the credit bureau in Myanmar, MCIX. This project will > continue extending the functionality of the module and work on integrations > with the major credit bureaus in Latin America and Sub-Saharan Africa. > The major functionality will be sending the data to CBs on regular intervals > in the format CB expects. And option to pull the client’s information from CB > whenever loan officer/branch manager/ user wants to view the information for > a particular client. > h2.Helpful Skills > SQL, Java, Javascript, Git, Web Services, Big Data (Hadoop, Hive) > h2. Impact > The credit report shows account information such as repayment record, > defaults, type of loan, amount of loan, etc. of the customer. This > information facilitates prudent decision-making when the credit underwriter > processes the loan application. This help MFI to reduce the risk of bad loans > and reduces the multiple lendings to same person from different MFIs. > h2. Other Resources > Documentation: > https://cwiki.apache.org/confluence/display/FINERACT/Documentation+to+use+Integrated+Credit+Bureau > For the scope of this project , see > https://jira.apache.org/jira/browse/FINERACT-734 > Detailed requirements: https://goo.gl/aZWMZa > Source Code: > https://github.com/apache/fineract/pulls?q=is%3Apr+is%3Aclosed+credit+bureau -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FINERACT-1334) Fineract Credit Bureau Integration Phase 3
Ed Cable created FINERACT-1334: -- Summary: Fineract Credit Bureau Integration Phase 3 Key: FINERACT-1334 URL: https://issues.apache.org/jira/browse/FINERACT-1334 Project: Apache Fineract Issue Type: Improvement Reporter: Ed Cable h2. Mentors * [~nikhilpa...@yahoo.in] * [~rrpawar] Nayan Ambali, Ed Cable h2. Overview & Objectives Because of regulatory reasons or to do background check of a client (risk management), MFIs depend on credit bureaus. As part of it, MFI must submit client details to credit bureau and also need to pull client information from credit bureau before approving any new loans to a client. Apache Fineract can be integrated with a popular CBs in India and from other regions (based on the demand). h2. Description Building off the work that was kicked off in 2016, during the 2020 Google Summer of Code, Rahul Pawar, completed the credit bureau integration module with integrations for the credit bureau in Myanmar, MCIX. This project will continue extending the functionality of the module and work on integrations with the major credit bureaus in Latin America and Sub-Saharan Africa. The major functionality will be sending the data to CBs on regular intervals in the format CB expects. And option to pull the client’s information from CB whenever loan officer/branch manager/ user wants to view the information for a particular client. h2.Helpful Skills SQL, Java, Javascript, Git, Web Services, Big Data (Hadoop, Hive) h2. Impact The credit report shows account information such as repayment record, defaults, type of loan, amount of loan, etc. of the customer. This information facilitates prudent decision-making when the credit underwriter processes the loan application. This help MFI to reduce the risk of bad loans and reduces the multiple lendings to same person from different MFIs. h2. Other Resources Documentation: https://cwiki.apache.org/confluence/display/FINERACT/Documentation+to+use+Integrated+Credit+Bureau For the scope of this project , see https://jira.apache.org/jira/browse/FINERACT-734 Detailed requirements: https://goo.gl/aZWMZa Source Code: https://github.com/apache/fineract/pulls?q=is%3Apr+is%3Aclosed+credit+bureau -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FINERACT-1333) Reference Open Banking Fintech App on Fineract
Ed Cable created FINERACT-1333: -- Summary: Reference Open Banking Fintech App on Fineract Key: FINERACT-1333 URL: https://issues.apache.org/jira/browse/FINERACT-1333 Project: Apache Fineract Issue Type: Improvement Reporter: Ed Cable h2. Mentors * [~jawidMuhammadi] * Naman Dwivedi * Shivansh Tiwari h2. Overview & Objectives Across our ecosystem we're seeing more and more adoption and innovation from fintechs. A huge democratizing force across the financial services sector is the Open Banking movement providing Open Banking APIs to enable third parties to directly interact with customers of financial institutions. We have recently started providing an Open Banking API layer that will allow financial institutions using Mifos and Fineract to offer third parties access to requesting account information and initiating payments via these APIs. Most recently the Mojaloop community, led by Google, has led the development of a centralized PISP API To demonstrate these Open Banking APIs and use cases that third parties and fintechs can provide we have developed a cross-platform reference mobile app on Kotlin to showcase a number of these features. It currently connects with the Open Bank Project that adheres to the UK Open Banking API standard. The API Gateway to connect to is still being chosen (WS02, Gravitee, etc.) The breadth and variety of apps that could be built leveraging these APIs from region to region is endless. We would like this app to be built in an extensible and modular fashion such that core libraries and components could be re-used across different use cases with this framework as the foundation and multiple reference apps on top. Applications include personal financial management apps aggregating information from multiple bank accounts in one place, wallet apps allowing payments to be made from different banks, lending apps, leveraging data and insight from multiple accounts, savings apps, etc. h2. Description Intern would work on refining the initial architecture of the framework, the UI and user experience, core use cases including customer authentication and onboarding that was implemented in 2020 and integrating with the Fineract Open Banking APIs and Mojaloop PISP APIs to demonstrate use cases around account information request and payment initiation. * Aggregating account information across multiple banks/financial institution * Initiating payments across multiple financial institutions * Integrate with additional Fineract Open Banking APIs * Integrate with Mojaloop PISP APIs. h2. Helpful Skills Android development, SQL, Java, Javascript, Git, Spring, OpenJPA, Rest, Kotlin h2. Impact By providing an extensible open banking fintech app framework, allow partners a complete stack of Open Banking APIs and reference front-end application to rapidly build innovation via Open Banking APIs. h2. Other Resources 2020 Progress: https://gist.github.com/ankurs287/4ef7c3de462073bf36bd5247479cb176 Google Whitepaper on 3PPI: https://static.googleusercontent.com/media/nextbillionusers.google/en//tools/3PPI-2021-whitepaper.pdf UK Open Banking API Standard: https://standards.openbanking.org.uk/ Open Banking Developer Zone: https://openbanking.atlassian.net/wiki/spaces/DZ/overview Examples of Open Banking Apps: https://www.ft.com/content/a5f0af78-133e-11e9-a581-4ff78404524e -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FINCN-251) Functional Enhancements to Fineract CN Mobile
[ https://issues.apache.org/jira/browse/FINCN-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17299803#comment-17299803 ] Ed Cable commented on FINCN-251: [~EGOR-IND] and [~VarSVat] Yes this project is going to be a part of GSOC 2021 under the Apache Software Foundation. You can find details about the application process here: https://community.apache.org/gsoc.html Ed > Functional Enhancements to Fineract CN Mobile > - > > Key: FINCN-251 > URL: https://issues.apache.org/jira/browse/FINCN-251 > Project: Fineract Cloud Native > Issue Type: Improvement >Reporter: Ed Cable >Priority: Major > Labels: gsoc2021, mentor > > h2. Mentors > * [~therajanmaurya] > * [~jawidMuhammadi] > h2. Overview & Objectives > Just as we have a mobile field operations app on Apache Fineract 1.x, we have > recently built out on top of the brand new Apache Fineract CN micro-services > architecture, an initial version of a mobile field operations app with an MVP > architecture and material design. Given the flexibility of the new > architecture and its ability to support different methodologies - MFIs, > credit unions, cooperatives, savings groups, agent banking, etc - this mobile > app will have different flavors and workflows and functionalities. > h2. Description > In 2020, our Google Summer of Code intern worked on additional functionality > in the Fineract CN mobile app. In 2021, the student will work on the > following tasks: > * Integrate with Payment Hub to enable disbursement via Mobile Money API > * Improve Task management features into the app. > * Create UI for creating new account and displaying account details > * Create UI for creating tellers and displaying tellers details > * Improve GIS features like location tracking, dropping of pin into the app > * Improve offline mode via Couchbase support > * Write Unit Test, Integration Test and UI tests > h2. Helpful Skills > Android Development, Kotlin, Java, Git, OpenJPA, Rest API > h2. Impact > Allows staff to go directly into the field to connect to the client. Reduces > cost of operations by enabling organizations to go paperless and be more > efficient. > h2. Other Resources > # Repo on Github: > https://github.com/apache/fineract-cn-mobile > # Fineract CN API documentation: > https://izakey.github.io/fineract-cn-api-docs-site/ > # https://github.com/aasaru/fineract-cn-api-docs > https://cwiki.apache.org/confluence/display/FINERACT/Fineract+CN > # How to install and run Couchbase: > https://gist.github.com/jawidMuhammadi/af6cd34058cacf20b100d335639b3ad8 > # GSMA mobile money API: > https://developer.mobilemoneyapi.io/1.1/oas3/22466 > # Payment Hub: > https://github.com/search?q=openMF%2Fph-eeref=opensearch > # Some UI designs: > https://www.figma.com/file/KHXtZPdIpC3TqvdIVZu8CW/fineract-cn-mobile?node-id=0%3A1 > # 2020 GSoC progress report: > https://gist.github.com/jawidMuhammadi/9fa91d37b1cbe43d9cdfe165ad8f2102 > # JIRA Task > https://issues.apache.org/jira/browse/FINCN-241?filter=-2=project%20%3D%20FINCN%20order%20by%20created%20DESC -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FINCN-252) Machine Learning Scorecard for Credit Risk Assessment Phase 4
Ed Cable created FINCN-252: -- Summary: Machine Learning Scorecard for Credit Risk Assessment Phase 4 Key: FINCN-252 URL: https://issues.apache.org/jira/browse/FINCN-252 Project: Fineract Cloud Native Issue Type: Improvement Reporter: Ed Cable h2. Mentors * Lalit Mohan S * [~Fintecheando] h2. Overview & Objectives Financial Organizations using Mifos/Fineract are depending on external agencies or their past experiences for evaluating credit scoring and identification of potential NPAs. Though information from external agencies is required, financial organizations can have an internal scorecard for evaluating loans so that preventive/proactive actions can be done along with external agencies reports. In industry, organizations are using rule based, Statistical and Machine learning methods for credit scoring, predicting potential NPAs, fraud detection and other activities. This project aims to implement a scorecard based on statistical and ML methods for credit scoring and identification of potential NPAs. h2. Description The approach should factor and improve last year's GSOC work (https://gist.github.com/SupreethSudhakaranMenon/a20251271adb341f949dbfeb035191f7) on Features/Characteristics, Criteria and evaluation (link). The design and implementation of the screens should follow Mifos Application standards. Should implement statistical and ML methods with explainability on decision making. Should also be extensible for adding other functionalities such as fraud detection, cross-sell and up-sell, etc. h2. Helpful Skills JAVA, Integrating Backend Service, MIFOS X, Apache Fineract, AngularJS, ORM, ML, Statistical Methods, Django h2. Impact Streamlined Operations, Better RISK Management, Automated Response Mechanism h2. Other Resources 2019 Progress: https://gist.github.com/SupreethSudhakaranMenon/a20251271adb341f949dbfeb035191f7 https://gist.github.com/lalitsanagavarapu -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FINCN-251) Functional Enhancements to Fineract CN Mobile
Ed Cable created FINCN-251: -- Summary: Functional Enhancements to Fineract CN Mobile Key: FINCN-251 URL: https://issues.apache.org/jira/browse/FINCN-251 Project: Fineract Cloud Native Issue Type: Improvement Reporter: Ed Cable h2. Mentors * [~therajanmaurya] * [~jawidMuhammadi] h2. Overview & Objectives Just as we have a mobile field operations app on Apache Fineract 1.x, we have recently built out on top of the brand new Apache Fineract CN micro-services architecture, an initial version of a mobile field operations app with an MVP architecture and material design. Given the flexibility of the new architecture and its ability to support different methodologies - MFIs, credit unions, cooperatives, savings groups, agent banking, etc - this mobile app will have different flavors and workflows and functionalities. h2. Description In 2020, our Google Summer of Code intern worked on additional functionality in the Fineract CN mobile app. In 2021, the student will work on the following tasks: * Integrate with Payment Hub to enable disbursement via Mobile Money API * Improve Task management features into the app. * Create UI for creating new account and displaying account details * Create UI for creating tellers and displaying tellers details * Improve GIS features like location tracking, dropping of pin into the app * Improve offline mode via Couchbase support * Write Unit Test, Integration Test and UI tests h2. Helpful Skills Android Development, Kotlin, Java, Git, OpenJPA, Rest API h2. Impact Allows staff to go directly into the field to connect to the client. Reduces cost of operations by enabling organizations to go paperless and be more efficient. h2. Other Resources # Repo on Github: https://github.com/apache/fineract-cn-mobile # Fineract CN API documentation: https://izakey.github.io/fineract-cn-api-docs-site/ # https://github.com/aasaru/fineract-cn-api-docs https://cwiki.apache.org/confluence/display/FINERACT/Fineract+CN # How to install and run Couchbase: https://gist.github.com/jawidMuhammadi/af6cd34058cacf20b100d335639b3ad8 # GSMA mobile money API: https://developer.mobilemoneyapi.io/1.1/oas3/22466 # Payment Hub: https://github.com/search?q=openMF%2Fph-eeref=opensearch # Some UI designs: https://www.figma.com/file/KHXtZPdIpC3TqvdIVZu8CW/fineract-cn-mobile?node-id=0%3A1 # 2020 GSoC progress report: https://gist.github.com/jawidMuhammadi/9fa91d37b1cbe43d9cdfe165ad8f2102 # JIRA Task https://issues.apache.org/jira/browse/FINCN-241?filter=-2=project%20%3D%20FINCN%20order%20by%20created%20DESC -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FINCN-250) Create Open Banking Layer for Fineract CN Self-Service App
Ed Cable created FINCN-250: -- Summary: Create Open Banking Layer for Fineract CN Self-Service App Key: FINCN-250 URL: https://issues.apache.org/jira/browse/FINCN-250 Project: Fineract Cloud Native Issue Type: Improvement Reporter: Ed Cable h2. Mentors * [~avikg] * [~dgstar] h2. Overview & Objectives Across our ecosystem we're seeing more and more adoption and innovation from fintechs. A huge democratizing force across the financial services sector is the Open Banking movement providing Open Banking APIs to enable third parties to directly interact with customers of financial institutions. We have recently started providing an Open Banking API layer that will allow financial institutions using Mifos and Fineract to offer third parties access to requesting account information and initiating payments via these APIs. Most recently the Mojaloop community, led by Google, has led the development of a centralized PISP API. We have chosen to the follow the comprehensive UK Open Banking API standard which is being followed and adopted by a number of countries through Sub-Saharan Africa and Latin America. Tremendous impact can be had at the Base of the Pyramid by enabling third parties to establish consent with customers to authorize transactions to be initiated or information to be accessed from accounts at their financial institution. This Open Banking API layer would enable any institution using Mifos or Fineract to provide a UK Open Banking API layer to third parties and fintechs. The API Gateway to connect to is still being chosen (WS02, Gravitee, etc.) h2. Description The APIS that are consumed by the the reference Fineract 1.x mobile banking application have been documented in the spreadsheet below. The APIs have also been categorized according to whether they are an existing self-service API or back-office API and if they have an equivalent Open Banking API and if so, a link to the corresponding Open Banking API. For each API with an equivalent Open Banking API, the interns must: Take rest api, upload swagger definition, do transformation in OpenBanking Adapter, and publish on API gateway. For back-office and/or self-service APIs with no equivalent Open Banking API, the process is: Take rest api, upload swagger definition, and publish on API gateway. For example: * Submit Loan Application (Self-ServiceAPIwith EquivalentOpenBankingAPI) * https://demo.mifos.io/api-docs/apiLive.htm#loans_create * Used by Fineract 1.x Self-Service App * ImagesAPI(Back-OfficeAPIwith No EquivalentOpenBankingAPI) * https://demo.mifos.io/api-docs/apiLive.htm#client_images * Used by Mifos Mobile and Mobile Wallet * Fetch Identification CardAPI(Fineract CNAPIwith no equivalentOpenBankingAPI) * https://docs.google.com/document/d/15LbxVoQQRoa4uU7QiV7FpJFVjkyyNb9_HJwFvS47O4I/edit?pli=1#heading=h.xfl6jxdpcpy1 h2. Sample APIs to be Documented --- Mifos Mobile CN API Matrix (completed by Garvit) https://docs.google.com/spreadsheets/d/1-HrfPKhh1kO7ojK15Ylf6uzejQmaz72eXf5MzCBCE3M/edit#gid=0 https://docs.google.com/document/d/15LbxVoQQRoa4uU7QiV7FpJFVjkyyNb9_HJwFvS47O4I/edit?pli=1# Mobile Wallet API Matrix (completed by Devansh) https://docs.google.com/spreadsheets/d/1VgpIwN2JsljWWytk_Qb49kKzmWvwh6xa1oRgMNIAv3g/edit#gid=0 h2. Helpful Skills Android development, SQL, Java, Javascript, Git, Spring, OpenJPA, Rest, Kotlin, Gravitee, WSO2 h2. Impact By providing a standard UK Open Banking API layer we can provide both a secure way for our trusted first party apps to allow customers to authenticate and access their accounts as well as an API layer for third party fintechs to securely access Fineract and request information or initiate transactions with the consent of customers. h2. Other Resources CGAP Research on Open Banking: https://www.cgap.org/research/publication/open-banking-how-design-financial-inclusion Docs: https://mifos.gitbook.io/docs/wso2-1/setup-openbanking-apis Self-Service APIs: https://demo.mifos.io/api-docs/apiLive.htm#selfbasicauth * https://cwiki.apache.org/confluence/display/FINERACT/Customer+Self-Service+Phase+2 Open Banking Adapter: https://github.com/openMF/openbanking-adapter * Transforms Open Banking API to Fineract API * Works with both Fineract 1.x and Fineract CN * Can connect to different API gateways and can transform against different API standards. Reference Open Banking Fintech App: * Backend: https://github.com/openMF/openbanking-tpp-server * GUI: https://github.com/openMF/openbanking-tpp-client Google Whitepaper on 3PPI: https://static.googleusercontent.com/media/nextbillionusers.google/en//tools/3PPI-2021-whitepaper.pdf UK Open Banking API Standard: https://standards.openbanking.org.uk/ Open Banking Developer Zone:
[jira] [Updated] (FINERACT-1332) Create Open Banking Layer for Mobile Wallet Apps
[ https://issues.apache.org/jira/browse/FINERACT-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-1332: --- Description: h2. Mentors * [~avikg] * Devansh Aggarwal h2. Overview & Objectives Across our ecosystem we're seeing more and more adoption and innovation from fintechs. A huge democratizing force across the financial services sector is the Open Banking movement providing Open Banking APIs to enable third parties to directly interact with customers of financial institutions. We have recently started providing an Open Banking API layer that will allow financial institutions using Mifos and Fineract to offer third parties access to requesting account information and initiating payments via these APIs. Most recently the Mojaloop community, led by Google, has led the development of a centralized PISP API. We have chosen to the follow the comprehensive UK Open Banking API standard which is being followed and adopted by a number of countries through Sub-Saharan Africa and Latin America. Tremendous impact can be had at the Base of the Pyramid by enabling third parties to establish consent with customers to authorize transactions to be initiated or information to be accessed from accounts at their financial institution. This Open Banking API layer would enable any institution using Mifos or Fineract to provide a UK Open Banking API layer to third parties and fintechs. The API Gateway to connect to is still being chosen (WS02, Gravitee, etc.) h2. Description The APIS that are consumed by the the reference Fineract 1.x mobile banking application have been documented in the spreadsheet below. The APIs have also been categorized according to whether they are an existing self-service API or back-office API and if they have an equivalent Open Banking API and if so, a link to the corresponding Open Banking API. For each API with an equivalent Open Banking API, the interns must: Take rest api, upload swagger definition, do transformation in OpenBanking Adapter, and publish on API gateway. For back-office and/or self-service APIs with no equivalent Open Banking API, the process is: Take rest api, upload swagger definition, and publish on API gateway. For example: * Submit Loan Application (Self-ServiceAPIwith EquivalentOpenBankingAPI) * https://demo.mifos.io/api-docs/apiLive.htm#loans_create * Used by Fineract 1.x Self-Service App * ImagesAPI(Back-OfficeAPIwith No EquivalentOpenBankingAPI) * https://demo.mifos.io/api-docs/apiLive.htm#client_images * Used by Mifos Mobile and Mobile Wallet * Fetch Identification CardAPI(Fineract CNAPIwith no equivalentOpenBankingAPI) * https://docs.google.com/document/d/15LbxVoQQRoa4uU7QiV7FpJFVjkyyNb9_HJwFvS47O4I/edit?pli=1#heading=h.xfl6jxdpcpy1 h2. Sample APIs to be Documented --- Mobile Wallet API Matrix (completed by Devansh) https://docs.google.com/spreadsheets/d/1VgpIwN2JsljWWytk_Qb49kKzmWvwh6xa1oRgMNIAv3g/edit#gid=0 h2. Helpful Skills Android development, SQL, Java, Javascript, Git, Spring, OpenJPA, Rest, Kotlin, Gravitee, WSO2 h2. Impact By providing a standard UK Open Banking API layer we can provide both a secure way for our trusted first party apps to allow customers to authenticate and access their accounts as well as an API layer for third party fintechs to securely access Fineract and request information or initiate transactions with the consent of customers. h2. Other Resources CGAP Research on Open Banking: https://www.cgap.org/research/publication/open-banking-how-design-financial-inclusion Docs: https://mifos.gitbook.io/docs/wso2-1/setup-openbanking-apis Self-Service APIs: https://demo.mifos.io/api-docs/apiLive.htm#selfbasicauth * https://cwiki.apache.org/confluence/display/FINERACT/Customer+Self-Service+Phase+2 Open Banking Adapter: https://github.com/openMF/openbanking-adapter * Transforms Open Banking API to Fineract API * Works with both Fineract 1.x and Fineract CN * Can connect to different API gateways and can transform against different API standards. Reference Open Banking Fintech App: * Backend: https://github.com/openMF/openbanking-tpp-server * GUI: https://github.com/openMF/openbanking-tpp-client Google Whitepaper on 3PPI: https://static.googleusercontent.com/media/nextbillionusers.google/en//tools/3PPI-2021-whitepaper.pdf UK Open Banking API Standard: https://standards.openbanking.org.uk/ Open Banking Developer Zone: https://openbanking.atlassian.net/wiki/spaces/DZ/overview Examples of Open Banking Apps: https://www.ft.com/content/a5f0af78-133e-11e9-a581-4ff78404524e See https://openmf.github.io/mobileapps.github.io/ was: h2. Mentors * [~avikg] * Naman Dwivedi h2. Overview & Objectives Across our ecosystem we're seeing more and more adoption and innovation from fintechs. A huge democratizing force across the
[jira] [Updated] (FINERACT-1332) Create Open Banking Layer for Mobile Wallet Apps
[ https://issues.apache.org/jira/browse/FINERACT-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Cable updated FINERACT-1332: --- Summary: Create Open Banking Layer for Mobile Wallet Apps (was: Create Open Banking Layer for Fineract CN Self-Service App) > Create Open Banking Layer for Mobile Wallet Apps > > > Key: FINERACT-1332 > URL: https://issues.apache.org/jira/browse/FINERACT-1332 > Project: Apache Fineract > Issue Type: Improvement >Reporter: Ed Cable >Priority: Major > Labels: gsoc2021, mentor > > h2. Mentors > * [~avikg] > * Naman Dwivedi > h2. Overview & Objectives > Across our ecosystem we're seeing more and more adoption and innovation from > fintechs. A huge democratizing force across the financial services sector is > the Open Banking movement providing Open Banking APIs to enable third parties > to directly interact with customers of financial institutions. We have > recently started providing an Open Banking API layer that will allow > financial institutions using Mifos and Fineract to offer third parties access > to requesting account information and initiating payments via these APIs. > Most recently the Mojaloop community, led by Google, has led the development > of a centralized PISP API. We have chosen to the follow the comprehensive UK > Open Banking API standard which is being followed and adopted by a number of > countries through Sub-Saharan Africa and Latin America. > Tremendous impact can be had at the Base of the Pyramid by enabling third > parties to establish consent with customers to authorize transactions to be > initiated or information to be accessed from accounts at their financial > institution. This Open Banking API layer would enable any institution using > Mifos or Fineract to provide a UK Open Banking API layer to third parties and > fintechs. > The API Gateway to connect to is still being chosen (WS02, Gravitee, etc.) > h2. Description > The APIS that are consumed by the the reference Fineract 1.x mobile banking > application have been documented in the spreadsheet below. The APIs have also > been categorized according to whether they are an existing self-service API > or back-office API and if they have an equivalent Open Banking API and if so, > a link to the corresponding Open Banking API. > For each API with an equivalent Open Banking API, the interns must: Take rest > api, upload swagger definition, do transformation in OpenBanking Adapter, and > publish on API gateway. > For back-office and/or self-service APIs with no equivalent Open Banking API, > the process is: Take rest api, upload swagger definition, and publish on API > gateway. > For example: > * Submit Loan Application (Self-ServiceAPIwith EquivalentOpenBankingAPI) > * https://demo.mifos.io/api-docs/apiLive.htm#loans_create > * Used by Fineract 1.x Self-Service App > * ImagesAPI(Back-OfficeAPIwith No EquivalentOpenBankingAPI) > * https://demo.mifos.io/api-docs/apiLive.htm#client_images > * Used by Mifos Mobile and Mobile Wallet > * Fetch Identification CardAPI(Fineract CNAPIwith no > equivalentOpenBankingAPI) > * > https://docs.google.com/document/d/15LbxVoQQRoa4uU7QiV7FpJFVjkyyNb9_HJwFvS47O4I/edit?pli=1#heading=h.xfl6jxdpcpy1 > h2. Sample APIs to be Documented > --- > Fineract 1.x Self Service App (Mifos Mobile) API Matrix (completed by Ashwin) > https://docs.google.com/spreadsheets/d/1gR84jZzLF-mM0iRw5JyeMAsHMK6RQPK0vyDmNAY9VhE/edit#gid=0 > Fineract 1.x Self-Service App (Mifos Mobile) API Matrix (completed by > Shivangi) > https://docs.google.com/spreadsheets/d/1exTv68v1IW_ygS7mSj0_ySFWGTj06NcxPZeNLjNIy6Y/edit?pli=1#gid=0 > h2. Helpful Skills > Android development, SQL, Java, Javascript, Git, Spring, OpenJPA, Rest, > Kotlin, Gravitee, WSO2 > h2. Impact > By providing a standard UK Open Banking API layer we can provide both a > secure way for our trusted first party apps to allow customers to > authenticate and access their accounts as well as an API layer for third > party fintechs to securely access Fineract and request information or > initiate transactions with the consent of customers. > h2. Other Resources > CGAP Research on Open Banking: > https://www.cgap.org/research/publication/open-banking-how-design-financial-inclusion > Docs: https://mifos.gitbook.io/docs/wso2-1/setup-openbanking-apis > Self-Service APIs: https://demo.mifos.io/api-docs/apiLive.htm#selfbasicauth > * > https://cwiki.apache.org/confluence/display/FINERACT/Customer+Self-Service+Phase+2 > Open Banking Adapter: https://github.com/openMF/openbanking-adapter > * Transforms Open Banking API to Fineract API > * Works with both Fineract 1.x and Fineract CN > * Can connect to different API gateways and can
[jira] [Created] (FINERACT-1332) Create Open Banking Layer for Fineract CN Self-Service App
Ed Cable created FINERACT-1332: -- Summary: Create Open Banking Layer for Fineract CN Self-Service App Key: FINERACT-1332 URL: https://issues.apache.org/jira/browse/FINERACT-1332 Project: Apache Fineract Issue Type: Improvement Reporter: Ed Cable h2. Mentors * [~avikg] * Naman Dwivedi h2. Overview & Objectives Across our ecosystem we're seeing more and more adoption and innovation from fintechs. A huge democratizing force across the financial services sector is the Open Banking movement providing Open Banking APIs to enable third parties to directly interact with customers of financial institutions. We have recently started providing an Open Banking API layer that will allow financial institutions using Mifos and Fineract to offer third parties access to requesting account information and initiating payments via these APIs. Most recently the Mojaloop community, led by Google, has led the development of a centralized PISP API. We have chosen to the follow the comprehensive UK Open Banking API standard which is being followed and adopted by a number of countries through Sub-Saharan Africa and Latin America. Tremendous impact can be had at the Base of the Pyramid by enabling third parties to establish consent with customers to authorize transactions to be initiated or information to be accessed from accounts at their financial institution. This Open Banking API layer would enable any institution using Mifos or Fineract to provide a UK Open Banking API layer to third parties and fintechs. The API Gateway to connect to is still being chosen (WS02, Gravitee, etc.) h2. Description The APIS that are consumed by the the reference Fineract 1.x mobile banking application have been documented in the spreadsheet below. The APIs have also been categorized according to whether they are an existing self-service API or back-office API and if they have an equivalent Open Banking API and if so, a link to the corresponding Open Banking API. For each API with an equivalent Open Banking API, the interns must: Take rest api, upload swagger definition, do transformation in OpenBanking Adapter, and publish on API gateway. For back-office and/or self-service APIs with no equivalent Open Banking API, the process is: Take rest api, upload swagger definition, and publish on API gateway. For example: * Submit Loan Application (Self-ServiceAPIwith EquivalentOpenBankingAPI) * https://demo.mifos.io/api-docs/apiLive.htm#loans_create * Used by Fineract 1.x Self-Service App * ImagesAPI(Back-OfficeAPIwith No EquivalentOpenBankingAPI) * https://demo.mifos.io/api-docs/apiLive.htm#client_images * Used by Mifos Mobile and Mobile Wallet * Fetch Identification CardAPI(Fineract CNAPIwith no equivalentOpenBankingAPI) * https://docs.google.com/document/d/15LbxVoQQRoa4uU7QiV7FpJFVjkyyNb9_HJwFvS47O4I/edit?pli=1#heading=h.xfl6jxdpcpy1 h2. Sample APIs to be Documented --- Fineract 1.x Self Service App (Mifos Mobile) API Matrix (completed by Ashwin) https://docs.google.com/spreadsheets/d/1gR84jZzLF-mM0iRw5JyeMAsHMK6RQPK0vyDmNAY9VhE/edit#gid=0 Fineract 1.x Self-Service App (Mifos Mobile) API Matrix (completed by Shivangi) https://docs.google.com/spreadsheets/d/1exTv68v1IW_ygS7mSj0_ySFWGTj06NcxPZeNLjNIy6Y/edit?pli=1#gid=0 h2. Helpful Skills Android development, SQL, Java, Javascript, Git, Spring, OpenJPA, Rest, Kotlin, Gravitee, WSO2 h2. Impact By providing a standard UK Open Banking API layer we can provide both a secure way for our trusted first party apps to allow customers to authenticate and access their accounts as well as an API layer for third party fintechs to securely access Fineract and request information or initiate transactions with the consent of customers. h2. Other Resources CGAP Research on Open Banking: https://www.cgap.org/research/publication/open-banking-how-design-financial-inclusion Docs: https://mifos.gitbook.io/docs/wso2-1/setup-openbanking-apis Self-Service APIs: https://demo.mifos.io/api-docs/apiLive.htm#selfbasicauth * https://cwiki.apache.org/confluence/display/FINERACT/Customer+Self-Service+Phase+2 Open Banking Adapter: https://github.com/openMF/openbanking-adapter * Transforms Open Banking API to Fineract API * Works with both Fineract 1.x and Fineract CN * Can connect to different API gateways and can transform against different API standards. Reference Open Banking Fintech App: * Backend: https://github.com/openMF/openbanking-tpp-server * GUI: https://github.com/openMF/openbanking-tpp-client Google Whitepaper on 3PPI: https://static.googleusercontent.com/media/nextbillionusers.google/en//tools/3PPI-2021-whitepaper.pdf UK Open Banking API Standard: https://standards.openbanking.org.uk/ Open Banking Developer Zone: https://openbanking.atlassian.net/wiki/spaces/DZ/overview Examples
[jira] [Created] (FINERACT-1331) Create Open Banking Layer for Fineract 1.x Self-Service Apps
Ed Cable created FINERACT-1331: -- Summary: Create Open Banking Layer for Fineract 1.x Self-Service Apps Key: FINERACT-1331 URL: https://issues.apache.org/jira/browse/FINERACT-1331 Project: Apache Fineract Issue Type: Improvement Reporter: Ed Cable h2. Mentors * [~avikg] * Naman Dwivedi h2. Overview & Objectives Across our ecosystem we're seeing more and more adoption and innovation from fintechs. A huge democratizing force across the financial services sector is the Open Banking movement providing Open Banking APIs to enable third parties to directly interact with customers of financial institutions. We have recently started providing an Open Banking API layer that will allow financial institutions using Mifos and Fineract to offer third parties access to requesting account information and initiating payments via these APIs. Most recently the Mojaloop community, led by Google, has led the development of a centralized PISP API. We have chosen to the follow the comprehensive UK Open Banking API standard which is being followed and adopted by a number of countries through Sub-Saharan Africa and Latin America. Tremendous impact can be had at the Base of the Pyramid by enabling third parties to establish consent with customers to authorize transactions to be initiated or information to be accessed from accounts at their financial institution. This Open Banking API layer would enable any institution using Mifos or Fineract to provide a UK Open Banking API layer to third parties and fintechs. The API Gateway to connect to is still being chosen (WS02, Gravitee, etc.) h2. Description The APIS that are consumed by the the reference Fineract 1.x mobile banking application have been documented in the spreadsheet below. The APIs have also been categorized according to whether they are an existing self-service API or back-office API and if they have an equivalent Open Banking API and if so, a link to the corresponding Open Banking API. For each API with an equivalent Open Banking API, the interns must: Take rest api, upload swagger definition, do transformation in OpenBanking Adapter, and publish on API gateway. For back-office and/or self-service APIs with no equivalent Open Banking API, the process is: Take rest api, upload swagger definition, and publish on API gateway. For example: * Submit Loan Application (Self-ServiceAPIwith EquivalentOpenBankingAPI) * https://demo.mifos.io/api-docs/apiLive.htm#loans_create * Used by Fineract 1.x Self-Service App * ImagesAPI(Back-OfficeAPIwith No EquivalentOpenBankingAPI) * https://demo.mifos.io/api-docs/apiLive.htm#client_images * Used by Mifos Mobile and Mobile Wallet * Fetch Identification CardAPI(Fineract CNAPIwith no equivalentOpenBankingAPI) * https://docs.google.com/document/d/15LbxVoQQRoa4uU7QiV7FpJFVjkyyNb9_HJwFvS47O4I/edit?pli=1#heading=h.xfl6jxdpcpy1 h2. Sample APIs to be Documented --- Fineract 1.x Self Service App (Mifos Mobile) API Matrix (completed by Ashwin) https://docs.google.com/spreadsheets/d/1gR84jZzLF-mM0iRw5JyeMAsHMK6RQPK0vyDmNAY9VhE/edit#gid=0 Fineract 1.x Self-Service App (Mifos Mobile) API Matrix (completed by Shivangi) https://docs.google.com/spreadsheets/d/1exTv68v1IW_ygS7mSj0_ySFWGTj06NcxPZeNLjNIy6Y/edit?pli=1#gid=0 h2. Helpful Skills Android development, SQL, Java, Javascript, Git, Spring, OpenJPA, Rest, Kotlin, Gravitee, WSO2 h2. Impact By providing a standard UK Open Banking API layer we can provide both a secure way for our trusted first party apps to allow customers to authenticate and access their accounts as well as an API layer for third party fintechs to securely access Fineract and request information or initiate transactions with the consent of customers. h2. Other Resources CGAP Research on Open Banking: https://www.cgap.org/research/publication/open-banking-how-design-financial-inclusion Docs: https://mifos.gitbook.io/docs/wso2-1/setup-openbanking-apis Self-Service APIs: https://demo.mifos.io/api-docs/apiLive.htm#selfbasicauth * https://cwiki.apache.org/confluence/display/FINERACT/Customer+Self-Service+Phase+2 Open Banking Adapter: https://github.com/openMF/openbanking-adapter * Transforms Open Banking API to Fineract API * Works with both Fineract 1.x and Fineract CN * Can connect to different API gateways and can transform against different API standards. Reference Open Banking Fintech App: * Backend: https://github.com/openMF/openbanking-tpp-server * GUI: https://github.com/openMF/openbanking-tpp-client Google Whitepaper on 3PPI: https://static.googleusercontent.com/media/nextbillionusers.google/en//tools/3PPI-2021-whitepaper.pdf UK Open Banking API Standard: https://standards.openbanking.org.uk/ Open Banking Developer Zone: https://openbanking.atlassian.net/wiki/spaces/DZ/overview
[jira] [Created] (FINERACT-1329) Live Fineract CN API Documentation (Swagger, etc.)
Ed Cable created FINERACT-1329: -- Summary: Live Fineract CN API Documentation (Swagger, etc.) Key: FINERACT-1329 URL: https://issues.apache.org/jira/browse/FINERACT-1329 Project: Apache Fineract Issue Type: Improvement Reporter: Ed Cable h2. Mentors * [~sanyam] * [~manthan] h2. Overview & Objectives The aim of this project is to provide a visual display of the Fineract CN API Documentation. We are now starting to use more of the Postman toolset for our developer portal and this project would focus on extending the existing work that was done. h2. Description This project involves providing a visual display of the API Documentation of Apache Fineract CN. Student would have to optimize documentation snippets ( .adoc ), document any service which isn't completely documented like template and reporting, document failing unit tests too and develop a visual website where these html files will be hosted. h2. Helpful Skills Java, PostgreSQL, MariaDB, Cassandra, TDD With JUnit 4, Spring REST Docs, Asciidoctor, HTML/CSS, Graphic Design h2. Impact A visual presentation of the Fineract CN APIs will be a key building block for an enabling environment for developers working on Fineract CN. h2. Other Resources * https://github.com/aasaru/fineract-cn-api-docs * https://izakey.github.io/fineract-cn-api-docs-site/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FINERACT-1328) Update Fineract 1.x Android Client SDK
Ed Cable created FINERACT-1328: -- Summary: Update Fineract 1.x Android Client SDK Key: FINERACT-1328 URL: https://issues.apache.org/jira/browse/FINERACT-1328 Project: Apache Fineract Issue Type: Improvement Reporter: Ed Cable h2. Mentors * [~ChinmayKulkarni] h2. Overview & Objectives The goal of this project is to continue work on developing the Fineract 1.x Client Android SDK which will be used in other Mifos Mobile Applications (android-client, mifos-mobile, mobile-wallet). The project aims to remove a lot of repeated code in the mobile apps and help mobile apps easily migrate to newer versions of Apache Fineract 1.x h2. Description The student will be working on implementing the following things: * Generate and release latest Fineract Client SDK for Android using the Open API Specification of Apache Fineract * Generate and publish documentation for the Fineract Android Client SDK * Add support for RxJava + LiveData * Migrate Mifos Android Field Officer App project to consume the new Fineract Client Android SDK * Provide testing coverage throughout the SDK * Implement CI/CD to automate steps 1 and 2 h2. Helpful Skills Java, Kotlin, Android, Swagger Specification, Open API Specification, Spring (Good to have) h2. Impact Enabling other mifos mobile apps to easily migrate to latest versions of Fineract. More stable and error free codebase h2. Other Resources * Last year progress - https://gist.github.com/Grandolf49/f79537436a467dac0baa9458a38290c5 * Jira Issue for reference: https://issues.apache.org/jira/browse/FINERACT-838 * https://github.com/apache/fineract * https://github.com/openMF/fineract-client -- This message was sent by Atlassian Jira (v8.3.4#803005)
