[jira] [Commented] (FINERACT-1095) Remove direct sqlSearch support from /clients and all other APIs [Security & Performance]

[Vishwas Babu A J (Jira)]

[ 
https://issues.apache.org/jira/browse/FINERACT-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163860#comment-17163860
 ] 

Vishwas Babu A J commented on FINERACT-1095:


>>This was apparently introduced by [~vishwasbabu]  in 
>>[https://github.com/openMF/community-app/pull/1582|https://github.com/openMF/community-app/pull/1582/files]
>> for [MIFOSX-2712.|https://mifosforge.jira.com/browse/MIFOSX-2712.] 

[~vorburger] , not me! this is another Vishwa.

> Remove direct sqlSearch support from /clients and all other APIs [Security & 
> Performance]
> -
>
> Key: FINERACT-1095
> URL: https://issues.apache.org/jira/browse/FINERACT-1095
> Project: Apache Fineract
>  Issue Type: Improvement
>Reporter: Michael Vorburger
>Assignee: Manthan Surkar
>Priority: Major
>
> While code reviewing PRs from [~Manthan] such as 
> [https://github.com/apache/fineract/pull/1171/files] and 
> [https://github.com/apache/fineract/pull/1123/files] re. FINERACT-854, I've 
> learnt about Fineract's support for an {{sqlSearch}} parameter on a number of 
> its APIs, such as {{/clients}} (and others).
> According to 
> [https://demo.fineract.dev/fineract-provider/api-docs/apiLive.htm] :
> {quote}_sqlSearch
>  String optional 
>  Use an sql fragment valid for the underlying client schema to filter 
> results. e.g. display_name like %K%
> {quote}
> [https://github.com/apache/fineract/search?p=2=sqlSearch_q=sqlSearch]
>  shows all current occurrences. There are a number, but not THAT many either. 
> (By far not every API supports this, only a handful.)
> This can be used e.g. like this: 
> [https://demo.fineract.dev/fineract-provider/api/v1/clients?paged=true=c.account_no=3=default]
> To me, this is an egregious violation of "layering architecture". Basically, 
> the REST API gives you direct SQL database access! You apparently have to 
> know the exact name of not the SQL table but the alias used in the respective 
> internally hard-coded query (note the use of {{c.}} in the example above, NOT 
> {{m_client}}), and the internal SQL column name (note the use of 
> {{account_no}}, NOT {{accountNo}}). There is no real documentation how to use 
> this, and even if there were, in my tests I've noticed its fairly easy to 
> provoke _500 Internal Server Errors_ when using {{sqlSearch}} with a slightly 
> wrong syntax.
> From a security point of view, it's not quite as bad as it looks, because 
> there is code with heuristics to "validate" the {{sqlSearch}} and prevent SQL 
> Injections. But that could have holes (I don't want to know!), so... this 
> still isn't great, at all, IMHO.
> From a performance point of view, permitting clients to run arbitrary queries 
> isn't great either. You can't really reliable offer performance guarantees, 
> or offer tuning with indices, if at the end of the day the wide open API just 
> lets a client "query whatever they want" anyway.
> Use of {{sqlSearch}} by (public) API clients isn't that hard to find. I did 
> some digging, and:
>  * The new web-app UI doesn't use sqlSearch (or not yet), see 
> [https://github.com/openMF/web-app/search?q=sqlSearch_q=sqlSearch]
>  * The old community-app UI does use sqlSearch, see 
> [https://github.com/openMF/community-app/search?p=1=sqlSearch_q=sqlSearch].
>  But only in 2 very specific places, for Loans' {{l.loan_status_id in 
> (100,200)}} and Clients' {{c.status_enum=100}}. This was apparently 
> introduced by [~vishwasbabu]  in 
> [https://github.com/openMF/community-app/pull/1582|https://github.com/openMF/community-app/pull/1582/files]
>  for [MIFOSX-2712.|https://mifosforge.jira.com/browse/MIFOSX-2712.] It's 
> noteworthy that the Find on 
> [https://cui.fineract.dev/.../clients|https://cui.fineract.dev/?baseApiUrl=https://demo.fineract.dev=default#/clients]
>  does NOT use {{sqlSearch}} but the [/search 
> API|https://demo.fineract.dev/fineract-provider/api-docs/apiLive.htm#search]
>  * other repos on openMF, such as Mobile Apps & Co, don't realy seem to 
> actively use {{sqlSearch}}, looking at 
> [https://github.com/search?p=7=org%3AopenMF+sqlSearch=Code]
> Other than that, I don't know if anyone actively using {{sqlSearch}} would 
> have any major objections to... just simply altogether removing this 
> entirely? Folks may of course be using this in their own client UIs, but... 
> they really shouldn't, this is a "bad" API. If you are missing a query 
> facility, just contribute to the upstream project and raise a pull request to 
> add whatever query option you are missing to whatever Fineract API (such as 
> e.g. by status for Loans and Clients).
> Let's further discuss on the developer mailing list on thread "Use of 
> sqlSearch argument in Groups/Clients List" if anyone wants to strongly defend 
> 

[jira] [Commented] (FINERACT-877) Clarify Fineract Version 1.3.1

[Vishwas Babu A J (Jira)]

[ 
https://issues.apache.org/jira/browse/FINERACT-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17077286#comment-17077286
 ] 

Vishwas Babu A J commented on FINERACT-877:
---

[~vorburger] : Release 1.3.0 was broken. Any app (Mobile or web) could not 
connect to this release due to a CORS issue. The issue was caused by 
[https://github.com/apache/fineract/commit/eb5ad448fa6cb365dad7e2691f4c6f7e9bb1c196]
 . The 1.3.1 branch was setup for making a hot fix release with only one 
change, i.e reverting the commit causing the CORS issue. This patch release has 
not been shipped. I am assuming nobody is using the 1.3.0 release (given that 
any app cannot connect to it)

> Clarify Fineract Version 1.3.1
> --
>
> Key: FINERACT-877
> URL: https://issues.apache.org/jira/browse/FINERACT-877
> Project: Apache Fineract
>  Issue Type: Bug
>Reporter: Michael Vorburger
>Priority: Major
>
> In JIRA, there is a 1.3.1 version, but it was never released. 
> I doubt a 1.3.1 will be released (anyone?) - if anything, a 1.4.0, see 
> FINERACT-873.
> There were 3 issues marked Fixed Version 1.3.1 today: FINERACT-755, and 
> FINERACT-848 &  FINERACT-832. The latter two have no PRs and so certainly 
> never were for 1.3.1, the Report must have just not known which Fix Version 
> to set; so I've just removed 1.3.1 from those two.
> The FINERACT-755 is more interesting - I don't fully understand yet is that 
> is also in develop, or not.
> Shall we delete the 1.3.1 version in JIRA? And in git, after clarifying 
> FINERACT-755 ?
> [~vishwasbabu] [~angelboxes]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (FINCN-190) Enable Database Configurability On Fineract CN

[Vishwas Babu A J (Jira)]

[ 
https://issues.apache.org/jira/browse/FINCN-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17064100#comment-17064100
 ] 

Vishwas Babu A J commented on FINCN-190:


[~awasum] : My suggestion would be to de-prioritize this issue and let an 
organization who needs support on a different DB initiate work on the same. For 
GSOC other issues that provide more impact like swagger docs, Integration tests 
and deepening core savings/loan functionality should ideally take precedence.

> Enable Database Configurability On Fineract CN
> --
>
> Key: FINCN-190
> URL: https://issues.apache.org/jira/browse/FINCN-190
> Project: Fineract Cloud Native
>  Issue Type: Improvement
>  Components: fineract-cn-postgresql
>Reporter: Isaac Kamga
>Priority: Major
>
> Based off this discussion ^[1]^ on the mailing list, transform the PostgreSQL 
> library ^[2]^ into DBMS library which can support alternate databases such as 
> PostgreSQL and MariaDB.
> [1] 
> [https://lists.apache.org/thread.html/d0b1483e986e7c80e705690974932f9711ee5468e469a5930ded046f@%3Cdev.fineract.apache.org%3E]
> [2] [https://github.com/apache/fineract-cn-postgresql]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (FINERACT-609) Topup loan is not working for Group loans

[Vishwas Babu A J (JIRA)]

[ 
https://issues.apache.org/jira/browse/FINERACT-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864408#comment-16864408
 ] 

Vishwas Babu A J commented on FINERACT-609:
---

[~edcable] and [~santoshmath] : While Dylan has resolved this issue ( see 
[https://github.com/apache/fineract/pull/574] ) , I am curious as to how this 
bug was prioritized ? While it is definitely a bug, is there actually any 
customer using Mifos who provides top-up group loans (I have seen Individual 
and JLG top-up loans, but never group loans) ? 

> Topup  loan is not working for Group loans
> --
>
> Key: FINERACT-609
> URL: https://issues.apache.org/jira/browse/FINERACT-609
> Project: Apache Fineract
>  Issue Type: Bug
>  Components: Loan
>Affects Versions: 1.0.0
>Reporter: Santosh Math
>Priority: Major
>  Labels: gsoc, p1, volunteers
> Attachments: topuploan.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> # Create a  loan product with top up enabled.
>  # Take a group loan and disburse it.
>  # Take another group loan application , Check 'Is topup loan' and try  to 
> select previous loan  account.  Previously created loan account is not 
> displaying.
> Top up loan  is working fine client level loan application. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-759) Possible thread unsafe bug for batch processing

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-759:
--
Fix Version/s: 1.4.0

> Possible thread unsafe bug for batch processing
> ---
>
> Key: FINERACT-759
> URL: https://issues.apache.org/jira/browse/FINERACT-759
> Project: Apache Fineract
>  Issue Type: Bug
>Reporter: Mohit Sinha
>Priority: Critical
> Fix For: 1.4.0
>
>
> I have noticed some errors while doing batch processing in Mifos.
>   
>  
> !https://mail.google.com/mail/u/0?ui=2=1a1c6fef1c=0.1=msg-a:r-170619917994284201=16afe11c353a555b=fimg=s0-l75-ft=ANGjdJ9p_KNZRnGZYdfbuosB_WlTfMEykfXgJGyi1TLe-OeGixMWmUITIPJQgNsQNC9oHaLkTi-bS1S7TPq-ogo39qUYdie-_bMiWAHXhB2ewuIgRzmoR_ga1abS6rA=emb=ii_jw7o4odi1|width=1354,height=319!
>  I found out some reasons for this on this link 
> [https://stackoverflow.com/questions/53470042/java-util-concurrentmodificationexception-bug-when-performing-io-operations]
>   
>  Hence, the object might change when it is in the middle of Gson 
> serialization.
>   
>  After further studying the codebase, I found out some possible thread 
> related bugs in *BatchApiServiceImpl.java.* 
>  It is a singleton with a variable that stores the state for a request. 
> {code:java}
> private List checkList = new ArrayList<>();  {code}
>  
>  On line number 125,
> {code:java}
> checkList = responseList;
> return responseList;  {code}
> This line may cause the error.
>   
>  There are some possible fixes for this:
>  # I can remove *BatchApiServiceImpl.java* from the Spring Context and create 
> a new object for every request. This will handle the possible thread related 
> bugs.
>  # In *BatchApiResource.java* line 119 
> {code:java}
> if (enclosingTransaction) {
>  result = service.handleBatchRequestsWithEnclosingTransaction(requestList, 
> uriInfo);
> } else {
>  result = service.handleBatchRequestsWithoutEnclosingTransaction(requestList, 
> uriInfo);
> }
> return this.toApiJsonSerializer.serialize(result);{code}
> I can clone the *result* array and then pass it for serialization. This will 
> remove the error, but won't solve possible thread related bugs.
>  # I can modify *checkList* logic and possibly remove it from 
> *BatchApiServiceImpl.java* . 
>  
>  I will need your suggestions and opinions on this.
>   
>   



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (FINERACT-759) Possible thread unsafe bug for batch processing

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J resolved FINERACT-759.
---
Resolution: Fixed

> Possible thread unsafe bug for batch processing
> ---
>
> Key: FINERACT-759
> URL: https://issues.apache.org/jira/browse/FINERACT-759
> Project: Apache Fineract
>  Issue Type: Bug
>Reporter: Mohit Sinha
>Priority: Critical
> Fix For: 1.4.0
>
>
> I have noticed some errors while doing batch processing in Mifos.
>   
>  
> !https://mail.google.com/mail/u/0?ui=2=1a1c6fef1c=0.1=msg-a:r-170619917994284201=16afe11c353a555b=fimg=s0-l75-ft=ANGjdJ9p_KNZRnGZYdfbuosB_WlTfMEykfXgJGyi1TLe-OeGixMWmUITIPJQgNsQNC9oHaLkTi-bS1S7TPq-ogo39qUYdie-_bMiWAHXhB2ewuIgRzmoR_ga1abS6rA=emb=ii_jw7o4odi1|width=1354,height=319!
>  I found out some reasons for this on this link 
> [https://stackoverflow.com/questions/53470042/java-util-concurrentmodificationexception-bug-when-performing-io-operations]
>   
>  Hence, the object might change when it is in the middle of Gson 
> serialization.
>   
>  After further studying the codebase, I found out some possible thread 
> related bugs in *BatchApiServiceImpl.java.* 
>  It is a singleton with a variable that stores the state for a request. 
> {code:java}
> private List checkList = new ArrayList<>();  {code}
>  
>  On line number 125,
> {code:java}
> checkList = responseList;
> return responseList;  {code}
> This line may cause the error.
>   
>  There are some possible fixes for this:
>  # I can remove *BatchApiServiceImpl.java* from the Spring Context and create 
> a new object for every request. This will handle the possible thread related 
> bugs.
>  # In *BatchApiResource.java* line 119 
> {code:java}
> if (enclosingTransaction) {
>  result = service.handleBatchRequestsWithEnclosingTransaction(requestList, 
> uriInfo);
> } else {
>  result = service.handleBatchRequestsWithoutEnclosingTransaction(requestList, 
> uriInfo);
> }
> return this.toApiJsonSerializer.serialize(result);{code}
> I can clone the *result* array and then pass it for serialization. This will 
> remove the error, but won't solve possible thread related bugs.
>  # I can modify *checkList* logic and possibly remove it from 
> *BatchApiServiceImpl.java* . 
>  
>  I will need your suggestions and opinions on this.
>   
>   



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FINERACT-758) Gradle task for starting tomcat does not when dev profile is selected

[Vishwas Babu A J (JIRA)]

Vishwas Babu A J created FINERACT-758:
-

 Summary: Gradle task for starting tomcat does not when dev profile 
is selected
 Key: FINERACT-758
 URL: https://issues.apache.org/jira/browse/FINERACT-758
 Project: Apache Fineract
  Issue Type: Bug
Reporter: Vishwas Babu A J


See 
[https://lists.apache.org/thread.html/fd333e3fd2837becfd92bd978cd58646cb827bedace9af531bea2ab7@%3Cdev.fineract.apache.org%3E]
 for details



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-757) Client list retrieval returns emtpy result when using search parameter

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-757:
--
Priority: Critical  (was: Major)

> Client list retrieval returns emtpy result when using search parameter
> --
>
> Key: FINERACT-757
> URL: https://issues.apache.org/jira/browse/FINERACT-757
> Project: Apache Fineract
>  Issue Type: Bug
>  Components: Client
>Reporter: Angel Cajas
>Assignee: Santosh Math
>Priority: Critical
> Fix For: 1.4.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Client list retrieval while using search parameters returns an empty result.
> While testing /clients endpoint to search clients using search parameters 
> such as firstName, secondName or externalId the search gave no results.
> Apparently in the past queries that required given paramaters were built 
> concatenating strings and sqlInjection validation was needed and the function 
> sqlEncodeString in the class ApiParametersHelper was used for this reason.
> The function validated if parameters contained sqlInjection but also appended 
> quotation marks to the the given parameter, however parameters are being 
> passed as an object array instead of being appended to the query string so 
> this validation isn't needed anymore as it's done by the sqlTemplate class 
> used to run the query.
> For example: Calling the sqlEncodeString modified the searchParam "Joe" to 
> "'Joe'" adding quotation marks and since there are no clients with quotation 
> marks in their name no clients were found and the result was empty.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-757) Client list retrieval returns emtpy result when using search parameter

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-757:
--
Description: 
Client list retrieval while using search parameters returns an empty result.

While testing /clients endpoint to search clients using search parameters such 
as firstName, secondName or externalId the search gave no results.

Apparently in the past queries that required given paramaters were built 
concatenating strings and sqlInjection validation was needed and the function 
sqlEncodeString in the class ApiParametersHelper was used for this reason.

The function validated if parameters contained sqlInjection but also appended 
quotation marks to the the given parameter, however parameters are being passed 
as an object array instead of being appended to the query string so this 
validation isn't needed anymore as it's done by the sqlTemplate class used to 
run the query.

For example: Calling the sqlEncodeString modified the searchParam "Joe" to 
"'Joe'" adding quotation marks and since there are no clients with quotation 
marks in their name no clients were found and the result was empty.

  was:Client list retrieval while using search parameters returns an empty 
result.


> Client list retrieval returns emtpy result when using search parameter
> --
>
> Key: FINERACT-757
> URL: https://issues.apache.org/jira/browse/FINERACT-757
> Project: Apache Fineract
>  Issue Type: Bug
>  Components: Client
>Reporter: Angel Cajas
>Assignee: Santosh Math
>Priority: Major
> Fix For: 1.4.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Client list retrieval while using search parameters returns an empty result.
> While testing /clients endpoint to search clients using search parameters 
> such as firstName, secondName or externalId the search gave no results.
> Apparently in the past queries that required given paramaters were built 
> concatenating strings and sqlInjection validation was needed and the function 
> sqlEncodeString in the class ApiParametersHelper was used for this reason.
> The function validated if parameters contained sqlInjection but also appended 
> quotation marks to the the given parameter, however parameters are being 
> passed as an object array instead of being appended to the query string so 
> this validation isn't needed anymore as it's done by the sqlTemplate class 
> used to run the query.
> For example: Calling the sqlEncodeString modified the searchParam "Joe" to 
> "'Joe'" adding quotation marks and since there are no clients with quotation 
> marks in their name no clients were found and the result was empty.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (FINERACT-757) Client list retrieval returns emtpy result when using search parameter

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J resolved FINERACT-757.
---
   Resolution: Fixed
 Assignee: Santosh Math  (was: Angel Cajas)
Fix Version/s: 1.4.0

> Client list retrieval returns emtpy result when using search parameter
> --
>
> Key: FINERACT-757
> URL: https://issues.apache.org/jira/browse/FINERACT-757
> Project: Apache Fineract
>  Issue Type: Bug
>  Components: Client
>Reporter: Angel Cajas
>Assignee: Santosh Math
>Priority: Major
> Fix For: 1.4.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Client list retrieval while using search parameters returns an empty result.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-747) change String.replaceAll() to replace() if the replaced one is plain string.

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-747:
--
Issue Type: Improvement  (was: Bug)

> change String.replaceAll() to replace() if the replaced one is plain string.
> 
>
> Key: FINERACT-747
> URL: https://issues.apache.org/jira/browse/FINERACT-747
> Project: Apache Fineract
>  Issue Type: Improvement
>Reporter: bd2019us
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.4.0
>
> Attachments: 1.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Locations: 
> (1) 
> fineract-provider/src/main/java/org/apache/fineract/accounting/rule/api/AccountingRuleJsonInputParams.java
> (2) 
> fineract-provider/src/main/java/org/apache/fineract/infrastructure/bulkimport/populator/fixeddeposits/
> FixedDepositTransactionWorkbookPopulator.java
> (3) 
> fineract-provider/src/main/java/org/apache/fineract/infrastructure/bulkimport/populator/loanrepayment/LoanRepaymentWorkbookPopulator.java
> (4) 
> fineract-provider/src/main/java/org/apache/fineract/infrastructure/bulkimport/populator/savings/SavingsTransactionsWorkbookPopulator.java
> (5) 
> fineract-provider/src/main/java/org/apache/fineract/portfolio/common/domain/ConditionType.java
> (6) 
> fineract-provider/src/main/java/org/apache/fineract/portfolio/group/service/CenterReadPlatformServiceImpl.java
> (7) 
> fineract-provider/src/main/java/org/apache/fineract/portfolio/group/service/GroupReadPlatformServiceImpl.java
> (8) 
> fineract-provider/src/main/java/org/apache/fineract/portfolio/loanaccount/service/LoanReadPlatformServiceImpl.java
>  
> The String.replaceAll(regex, other) is usually used to replace strings 
> represented by regular expression "regex". When the replaced string is a 
> plain string but regex form, the String.replace(origin, other) is recommended 
> as it does not need to compile and can improve the performance.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-747) Performance updates : change String.replaceAll() to replace() if the replaced one is plain string.

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-747:
--
Summary: Performance updates : change String.replaceAll() to replace() if 
the replaced one is plain string.  (was: change String.replaceAll() to 
replace() if the replaced one is plain string.)

> Performance updates : change String.replaceAll() to replace() if the replaced 
> one is plain string.
> --
>
> Key: FINERACT-747
> URL: https://issues.apache.org/jira/browse/FINERACT-747
> Project: Apache Fineract
>  Issue Type: Improvement
>Reporter: bd2019us
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.4.0
>
> Attachments: 1.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Locations: 
> (1) 
> fineract-provider/src/main/java/org/apache/fineract/accounting/rule/api/AccountingRuleJsonInputParams.java
> (2) 
> fineract-provider/src/main/java/org/apache/fineract/infrastructure/bulkimport/populator/fixeddeposits/
> FixedDepositTransactionWorkbookPopulator.java
> (3) 
> fineract-provider/src/main/java/org/apache/fineract/infrastructure/bulkimport/populator/loanrepayment/LoanRepaymentWorkbookPopulator.java
> (4) 
> fineract-provider/src/main/java/org/apache/fineract/infrastructure/bulkimport/populator/savings/SavingsTransactionsWorkbookPopulator.java
> (5) 
> fineract-provider/src/main/java/org/apache/fineract/portfolio/common/domain/ConditionType.java
> (6) 
> fineract-provider/src/main/java/org/apache/fineract/portfolio/group/service/CenterReadPlatformServiceImpl.java
> (7) 
> fineract-provider/src/main/java/org/apache/fineract/portfolio/group/service/GroupReadPlatformServiceImpl.java
> (8) 
> fineract-provider/src/main/java/org/apache/fineract/portfolio/loanaccount/service/LoanReadPlatformServiceImpl.java
>  
> The String.replaceAll(regex, other) is usually used to replace strings 
> represented by regular expression "regex". When the replaced string is a 
> plain string but regex form, the String.replace(origin, other) is recommended 
> as it does not need to compile and can improve the performance.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (FINERACT-747) change String.replaceAll() to replace() if the replaced one is plain string.

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J resolved FINERACT-747.
---
Resolution: Fixed

> change String.replaceAll() to replace() if the replaced one is plain string.
> 
>
> Key: FINERACT-747
> URL: https://issues.apache.org/jira/browse/FINERACT-747
> Project: Apache Fineract
>  Issue Type: Improvement
>Reporter: bd2019us
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.4.0
>
> Attachments: 1.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Locations: 
> (1) 
> fineract-provider/src/main/java/org/apache/fineract/accounting/rule/api/AccountingRuleJsonInputParams.java
> (2) 
> fineract-provider/src/main/java/org/apache/fineract/infrastructure/bulkimport/populator/fixeddeposits/
> FixedDepositTransactionWorkbookPopulator.java
> (3) 
> fineract-provider/src/main/java/org/apache/fineract/infrastructure/bulkimport/populator/loanrepayment/LoanRepaymentWorkbookPopulator.java
> (4) 
> fineract-provider/src/main/java/org/apache/fineract/infrastructure/bulkimport/populator/savings/SavingsTransactionsWorkbookPopulator.java
> (5) 
> fineract-provider/src/main/java/org/apache/fineract/portfolio/common/domain/ConditionType.java
> (6) 
> fineract-provider/src/main/java/org/apache/fineract/portfolio/group/service/CenterReadPlatformServiceImpl.java
> (7) 
> fineract-provider/src/main/java/org/apache/fineract/portfolio/group/service/GroupReadPlatformServiceImpl.java
> (8) 
> fineract-provider/src/main/java/org/apache/fineract/portfolio/loanaccount/service/LoanReadPlatformServiceImpl.java
>  
> The String.replaceAll(regex, other) is usually used to replace strings 
> represented by regular expression "regex". When the replaced string is a 
> plain string but regex form, the String.replace(origin, other) is recommended 
> as it does not need to compile and can improve the performance.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-747) change String.replaceAll() to replace() if the replaced one is plain string.

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-747:
--
Fix Version/s: 1.4.0

> change String.replaceAll() to replace() if the replaced one is plain string.
> 
>
> Key: FINERACT-747
> URL: https://issues.apache.org/jira/browse/FINERACT-747
> Project: Apache Fineract
>  Issue Type: Bug
>Reporter: bd2019us
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.4.0
>
> Attachments: 1.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Locations: 
> (1) 
> fineract-provider/src/main/java/org/apache/fineract/accounting/rule/api/AccountingRuleJsonInputParams.java
> (2) 
> fineract-provider/src/main/java/org/apache/fineract/infrastructure/bulkimport/populator/fixeddeposits/
> FixedDepositTransactionWorkbookPopulator.java
> (3) 
> fineract-provider/src/main/java/org/apache/fineract/infrastructure/bulkimport/populator/loanrepayment/LoanRepaymentWorkbookPopulator.java
> (4) 
> fineract-provider/src/main/java/org/apache/fineract/infrastructure/bulkimport/populator/savings/SavingsTransactionsWorkbookPopulator.java
> (5) 
> fineract-provider/src/main/java/org/apache/fineract/portfolio/common/domain/ConditionType.java
> (6) 
> fineract-provider/src/main/java/org/apache/fineract/portfolio/group/service/CenterReadPlatformServiceImpl.java
> (7) 
> fineract-provider/src/main/java/org/apache/fineract/portfolio/group/service/GroupReadPlatformServiceImpl.java
> (8) 
> fineract-provider/src/main/java/org/apache/fineract/portfolio/loanaccount/service/LoanReadPlatformServiceImpl.java
>  
> The String.replaceAll(regex, other) is usually used to replace strings 
> represented by regular expression "regex". When the replaced string is a 
> plain string but regex form, the String.replace(origin, other) is recommended 
> as it does not need to compile and can improve the performance.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FINERACT-733) Swagger Documentation for Fineract API's

[Vishwas Babu A J (JIRA)]

[ 
https://issues.apache.org/jira/browse/FINERACT-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806365#comment-16806365
 ] 

Vishwas Babu A J commented on FINERACT-733:
---

[~kangbreder] : This is indeed a project for GSoc 2019. [~sanyam96] is the 
mentor for the same. As you have noted, there are a few API's which are absent 
in the documentation, we would need to add the same as a part of GSOC.

[~sanyam96] , can you please respond to the queries that Kang has ?

> Swagger Documentation for Fineract API's
> 
>
> Key: FINERACT-733
> URL: https://issues.apache.org/jira/browse/FINERACT-733
> Project: Apache Fineract
>  Issue Type: Improvement
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
> Fix For: 1.4.0
>
> Attachments: Screen Shot 2019-03-17 at 3.59.23 AM.png
>
>
> The original documentation for Fineract is at 
> [https://github.com/apache/fineract/blob/develop/api-docs/apiLive.htm.] This 
> documentation was handcrafted to meet the following goals
>  # Provide a detailed overview of the API design and common options (under 
> "Overview" section of the top Navbar at 
> [https://demo.openmf.org/api-docs/apiLive.htm|https://demo.openmf.org/api-docs/apiLive.htm#loans])
>  # Help consumers to easily visualize related API's to quickly determine the 
> scope of functionality supported by the system ( Ex: links to all loan 
> related API's consolidated under the "Loan" section of the navbar)
>  # For each entity in the system, provide a meaningful description of what 
> the entity represents in the real world (Ex: 
> [https://demo.openmf.org/api-docs/apiLive.htm#glaccounts] )
>  # For common fields associated with an entity, provide a meaningful 
> description of what they represent and how they are to be used (Ex: 
> [https://demo.openmf.org/api-docs/apiLive.htm#loans] , see the description 
> and detailed explanation of fields like transactionProcessingStrategyId )
>  # Provide a detailed overview of the functionality supported by each API 
> call (especially when their usage is not obvious, see the detailed 
> documentation for Batch API's at 
> [https://demo.openmf.org/api-docs/apiLive.htm#batch_api] )
>  # Provide examples of sample requests and responses for each API call
> However, this documentation suffered a major drawback, i.e all of it was 
> handwritten and was difficult for new committers to add to and maintain. It 
> was also preferable that users be allowed to try out all API's from the 
> documentation itself, which wasn't an option.
> The newly added Swagger documentation aims to address these concerns. The 
> current status of the same and the work needed to meet the goals of the 
> original documentation is described below
>  
> *Goal 1* 
> The swagger docs rely on the existing API docs through hyperlinks for the 
> entire overview section. To make the swagger docs the single source of truth 
> for API documentation, the existing docs need to be deprecated. For doing the 
> same, this entire section needs to be copied over to the swagger UI (and well 
> formatted) and all references to the older docs removed. ** 
> *Goal 2* 
> All API's are currently listed in a random order and someone new to the 
> system cannot comprehend relationships between them. The home page needs to 
> be improved with either a sidebar or a navbar (similar to the one in the 
> existing documentation) which groups together related API's and provides 
> hyperlinks to their swagger documentation
> *Goal 3* 
> While entity descriptions seem to be present in the codebase (Ex: 
> https://github.com/apache/fineract/blob/201cbf82f67f7a623b8c38bf9465f4af79791c20/fineract-provider/src/main/java/org/apache/fineract/portfolio/savings/api/SavingsAccountsApiResource.java#L76),
>  they aren't reflected in the generated documentation. This is likely because 
> the description field is deprecated, see discussion at 
> [https://github.com/swagger-api/swagger-core/issues/1476.] 
> It would be nice if this description was well formatted too.
> *Goal 4* 
> Taking [https://demo.openmf.org/api-docs/apiLive.htm#loans] as an example, 
> the details and descriptions of fields like "transactionProcessingStrategyId" 
> are not carried over. Without this information, an API consumer would not 
> understand what each of these (non-obvious) fields mean and how they are to 
> be used.
> *Goal 5* 
> The amount of information present for an API like 
> [https://demo.openmf.org/api-docs/apiLive.htm#batch_api] is significantly 
> more than that of the equivalent API in Swagger (detailed description, 
> possible errors, command strategies supported etc). We would need to go 
> through each API to ensure that all information is migrated.
> Here's a screenshot of another commonly used API for updating loan statuses 

[jira] [Commented] (FINERACT-643) Journal Entries are not filterable by type of entry: system

[Vishwas Babu A J (JIRA)]

[ 
https://issues.apache.org/jira/browse/FINERACT-643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806218#comment-16806218
 ] 

Vishwas Babu A J commented on FINERACT-643:
---

[~sezal98] : Please do !

> Journal Entries are not filterable by type of entry: system
> ---
>
> Key: FINERACT-643
> URL: https://issues.apache.org/jira/browse/FINERACT-643
> Project: Apache Fineract
>  Issue Type: Improvement
>  Components: Accounting
>Affects Versions: 1.1.0
>Reporter: Santosh Math
>Assignee: Shruthi  M R
>Priority: Major
>  Labels: GSOC, Volunteer, gci, p2
> Fix For: 1.5.0
>
>
> Related Front -End Issue: 
> https://github.com/openMF/web-app/issues/236
> As a developer, I am unable to implement the filter for Journal Entries by 
> type of entry: system, as the only parameter available to filter entries by 
> type is manualEntriesOnly which filters manual entries (as clear from its 
> name). There is no way to filter system entries from server-side.
> (similar issue in community-app)
> Due to a large number of entries in database (over 8), its essential to 
> implement it from server-side because the default implementation of sending a 
> HTTP request to get all the entries at once and implementing the logic on 
> client-side will be too costly for people with slow internet connections.
>  
> Refer: [https://demo.openmf.org/api-docs/apiLive.htm#journalentries_list]
> Expected Behaviour:
> Journal Entries should be filterable by type of entry: system apart from the 
> manual as well from the server-side so that it can be implemented on the 
> client side.
> h2. Actual Behaviour
> Journal Entries are not filterable by type of entry: system from the 
> server-side due to which filter by type of entry cannot be implemented 
> properly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (FINERACT-738) Broken link for client Transaction (API docs)

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J resolved FINERACT-738.
---
Resolution: Fixed

Woohoo! Your first commit to Fineract [~muarachmann]

> Broken link for client Transaction (API docs)
> -
>
> Key: FINERACT-738
> URL: https://issues.apache.org/jira/browse/FINERACT-738
> Project: Apache Fineract
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.2.0, 1.3.0
> Environment: Mac OS, El captain 10.11, 8g RAM, 2.5Ghz
>Reporter: Mua Ndzo Laurent
>Priority: Blocker
>  Labels: beginner, newbie
> Fix For: 1.4.0
>
> Attachments: Screen Shot 2019-03-25 at 11.52.39 PM.png, Screen Shot 
> 2019-03-25 at 11.53.05 PM.png
>
>   Original Estimate: 5m
>  Remaining Estimate: 5m
>
> Currently in the clients menu one cannot navigate to the client Transaction 
> section due to a broken link. 
> This displays an unpleasant string `td>` at the top the dropdown as shown in 
> the screenshot attached. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-738) Broken link for client Transaction (API docs)

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-738:
--
Affects Version/s: (was: 1.4.0)
   1.3.0
   1.2.0

> Broken link for client Transaction (API docs)
> -
>
> Key: FINERACT-738
> URL: https://issues.apache.org/jira/browse/FINERACT-738
> Project: Apache Fineract
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.2.0, 1.3.0
> Environment: Mac OS, El captain 10.11, 8g RAM, 2.5Ghz
>Reporter: Mua Ndzo Laurent
>Priority: Blocker
>  Labels: beginner, newbie
> Attachments: Screen Shot 2019-03-25 at 11.52.39 PM.png, Screen Shot 
> 2019-03-25 at 11.53.05 PM.png
>
>   Original Estimate: 5m
>  Remaining Estimate: 5m
>
> Currently in the clients menu one cannot navigate to the client Transaction 
> section due to a broken link. 
> This displays an unpleasant string `td>` at the top the dropdown as shown in 
> the screenshot attached. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-738) Broken link for client Transaction (API docs)

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-738:
--
Fix Version/s: 1.4.0

> Broken link for client Transaction (API docs)
> -
>
> Key: FINERACT-738
> URL: https://issues.apache.org/jira/browse/FINERACT-738
> Project: Apache Fineract
>  Issue Type: Bug
>Affects Versions: 1.0.0, 1.2.0, 1.3.0
> Environment: Mac OS, El captain 10.11, 8g RAM, 2.5Ghz
>Reporter: Mua Ndzo Laurent
>Priority: Blocker
>  Labels: beginner, newbie
> Fix For: 1.4.0
>
> Attachments: Screen Shot 2019-03-25 at 11.52.39 PM.png, Screen Shot 
> 2019-03-25 at 11.53.05 PM.png
>
>   Original Estimate: 5m
>  Remaining Estimate: 5m
>
> Currently in the clients menu one cannot navigate to the client Transaction 
> section due to a broken link. 
> This displays an unpleasant string `td>` at the top the dropdown as shown in 
> the screenshot attached. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FINERACT-724) Upgrade Spring Boot, Spring and Spring Security to their latest stable version

[Vishwas Babu A J (JIRA)]

[ 
https://issues.apache.org/jira/browse/FINERACT-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801517#comment-16801517
 ] 

Vishwas Babu A J commented on FINERACT-724:
---

[~kamila.molina97] : Please refer 
https://cwiki.apache.org/confluence/display/FINERACT/Getting+Started+Docs

> Upgrade Spring Boot, Spring and Spring Security to their latest stable version
> --
>
> Key: FINERACT-724
> URL: https://issues.apache.org/jira/browse/FINERACT-724
> Project: Apache Fineract
>  Issue Type: Improvement
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>
> Fineract uses versions of spring (including spring security) and spring boot 
> which have approached their EOL and needs to be updated to the latest stable 
> releases.
> Spring -> 5.2.x (expected to be released before GSOC starts)
> Spring boot -> 2.2.x (expected to be released before GSOC starts)
>  
> This upgrade would likely throw up a number of issues which would need to be 
> addressed. Some sample issues would be
>  * Deprecated methods which have now been removed. Ex: The codebases uses 
> JdbcTemplate.queryForInt which would need to be replaced with queryForObject
>  * The implementation of custom Filters like 
> TenantAwareBasicAuthenticationFilter would need to change as overridden 
> methods like doFilter in OncePerRequestFilter are final in recent Spring 
> releases
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (FINERACT-720) Recurring Integration Test failures around Applying Annual Fees and Other Fee Types on Savings accounts

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J closed FINERACT-720.
-
Resolution: Won't Fix

Won't fix as per the observations made in the previous comments

> Recurring Integration Test failures around Applying Annual Fees and Other Fee 
> Types on Savings accounts
> ---
>
> Key: FINERACT-720
> URL: https://issues.apache.org/jira/browse/FINERACT-720
> Project: Apache Fineract
>  Issue Type: Sub-task
>Reporter: Vishwas Babu A J
>Priority: Trivial
>
> Fineract consists of two separate methods (and associated API's and batch 
> jobs) for Applying Annual and Savings Charges 
> inSavingsAccountWritePlatformServiceJpaRepositoryImpl, namely
>  * applyAnnualFee : Applies any due annual Fee (only once) for an active 
> savings account
>  * applyChargeDue : Applies any due fee (including annual fee) till it is 
> completely paid for a savings account
> The crux of the cause of intermittent failure of test cases is as follows:
> An annual charge is applied on a savings account for say the 1st of Jan 2015 
> and then applyAnnualFee batch job is run on the same as on Feb 2th 2019. This 
> results in the charge being paid as on 1st Jan 2015 and the next due date 
> being set to 1st Jan 2016. This behavior is probably incorrect and I would 
> presume that the charge would have to be paid for the years 2016, 2017,2018 
> and 2019 as well and the next due date should be set to 1st Jan 2020.
> Next, when at any point in time, when the applyChargeDue test case is run, it 
> recognizes the Annual fee charge due on 1st Jan 2016 and tries to repay the 
> same as on today's date. However, existing validation in this method throws 
> an exception.
> Based on an initial observation, it looks like the following fixes would need 
> to be made
>  # Running applyAnnualFee should pay of *all* annual fees due on the account 
> as of today's date
>  # applyChargeDue should not try to pay annual fees
> The change required for 1 has been made and it fixes the observed test case 
> failure. The change of 2 has not been made for now, as I am not a 100% sure 
> why the code is written in this way in the first place and in the absence of 
> sufficient integration tests, do not want to possibly introduce any side 
> effects.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FINERACT-720) Recurring Integration Test failures around Applying Annual Fees and Other Fee Types on Savings accounts

[Vishwas Babu A J (JIRA)]

[ 
https://issues.apache.org/jira/browse/FINERACT-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801199#comment-16801199
 ] 

Vishwas Babu A J commented on FINERACT-720:
---

[~kangbreder] : 

1) 
[SchedulerJobsTest.java|https://github.com/apache/fineract/pull/536/files#diff-38d6eccc76ab694890ecee7e470c772a]
 is the Integration test for all scheduled jobs, this would test applying 
annual fees too

2) The scheduler job is designed to run for all accounts, i.e you cannot run it 
for a single account

I would suggest that you pick up some other issue. This issue seems to have 
been around for a long time, apparently hasn't caused issues for anybody and 
with the fix made for the upcoming 1.3 release, it shall not cause errors as 
long as the applyAnnualFee batch job is run before applyChargeDue / 
organization does not create backdated savings accounts

> Recurring Integration Test failures around Applying Annual Fees and Other Fee 
> Types on Savings accounts
> ---
>
> Key: FINERACT-720
> URL: https://issues.apache.org/jira/browse/FINERACT-720
> Project: Apache Fineract
>  Issue Type: Sub-task
>Reporter: Vishwas Babu A J
>Priority: Trivial
>
> Fineract consists of two separate methods (and associated API's and batch 
> jobs) for Applying Annual and Savings Charges 
> inSavingsAccountWritePlatformServiceJpaRepositoryImpl, namely
>  * applyAnnualFee : Applies any due annual Fee (only once) for an active 
> savings account
>  * applyChargeDue : Applies any due fee (including annual fee) till it is 
> completely paid for a savings account
> The crux of the cause of intermittent failure of test cases is as follows:
> An annual charge is applied on a savings account for say the 1st of Jan 2015 
> and then applyAnnualFee batch job is run on the same as on Feb 2th 2019. This 
> results in the charge being paid as on 1st Jan 2015 and the next due date 
> being set to 1st Jan 2016. This behavior is probably incorrect and I would 
> presume that the charge would have to be paid for the years 2016, 2017,2018 
> and 2019 as well and the next due date should be set to 1st Jan 2020.
> Next, when at any point in time, when the applyChargeDue test case is run, it 
> recognizes the Annual fee charge due on 1st Jan 2016 and tries to repay the 
> same as on today's date. However, existing validation in this method throws 
> an exception.
> Based on an initial observation, it looks like the following fixes would need 
> to be made
>  # Running applyAnnualFee should pay of *all* annual fees due on the account 
> as of today's date
>  # applyChargeDue should not try to pay annual fees
> The change required for 1 has been made and it fixes the observed test case 
> failure. The change of 2 has not been made for now, as I am not a 100% sure 
> why the code is written in this way in the first place and in the absence of 
> sufficient integration tests, do not want to possibly introduce any side 
> effects.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-720) Recurring Integration Test failures around Applying Annual Fees and Other Fee Types on Savings accounts

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-720:
--
Priority: Trivial  (was: Major)

> Recurring Integration Test failures around Applying Annual Fees and Other Fee 
> Types on Savings accounts
> ---
>
> Key: FINERACT-720
> URL: https://issues.apache.org/jira/browse/FINERACT-720
> Project: Apache Fineract
>  Issue Type: Sub-task
>Reporter: Vishwas Babu A J
>Priority: Trivial
>
> Fineract consists of two separate methods (and associated API's and batch 
> jobs) for Applying Annual and Savings Charges 
> inSavingsAccountWritePlatformServiceJpaRepositoryImpl, namely
>  * applyAnnualFee : Applies any due annual Fee (only once) for an active 
> savings account
>  * applyChargeDue : Applies any due fee (including annual fee) till it is 
> completely paid for a savings account
> The crux of the cause of intermittent failure of test cases is as follows:
> An annual charge is applied on a savings account for say the 1st of Jan 2015 
> and then applyAnnualFee batch job is run on the same as on Feb 2th 2019. This 
> results in the charge being paid as on 1st Jan 2015 and the next due date 
> being set to 1st Jan 2016. This behavior is probably incorrect and I would 
> presume that the charge would have to be paid for the years 2016, 2017,2018 
> and 2019 as well and the next due date should be set to 1st Jan 2020.
> Next, when at any point in time, when the applyChargeDue test case is run, it 
> recognizes the Annual fee charge due on 1st Jan 2016 and tries to repay the 
> same as on today's date. However, existing validation in this method throws 
> an exception.
> Based on an initial observation, it looks like the following fixes would need 
> to be made
>  # Running applyAnnualFee should pay of *all* annual fees due on the account 
> as of today's date
>  # applyChargeDue should not try to pay annual fees
> The change required for 1 has been made and it fixes the observed test case 
> failure. The change of 2 has not been made for now, as I am not a 100% sure 
> why the code is written in this way in the first place and in the absence of 
> sufficient integration tests, do not want to possibly introduce any side 
> effects.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-737) Ability to fetch details of charges paid by a loan transaction

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-737:
--
Description: 
As a side effect of  
[https://github.com/apache/fineract/commit/aaa61695cf27419a2bc9e018fc6e2715512a1094]
 , along with the functionality for "Predefined nominal interest rates" 
associated with loan products, the ability to fetch the details of charges paid 
by a loan transaction have also been added in 
[https://github.com/apache/fineract/tree/Fineract-614.]

Details of the relevant code changes and the functionality are present in 
comments on github at 
[https://github.com/apache/fineract/pull/465#pullrequestreview-212401382.]

To merge the same into our develop branch, the API docs and Integration tests 
needs to updated to reflect these changes

  was:
As a side effect of  
[https://github.com/apache/fineract/commit/aaa61695cf27419a2bc9e018fc6e2715512a1094]
 , along with the functionality for "Predefined nominal interest rates" 
associated with loan products, the ability to fetch the details of charges paid 
by a loan transaction have also been added in 
[https://github.com/apache/fineract/tree/Fineract-614.]

Details of the relevant code changes and the functionality are present in 
comments on github at 
[https://github.com/apache/fineract/pull/465#pullrequestreview-212401382.]

To merge the same into our develop branch, the API docs and Integration tests 
need to updates to reflect these changes


> Ability to fetch details of charges paid by a loan transaction
> --
>
> Key: FINERACT-737
> URL: https://issues.apache.org/jira/browse/FINERACT-737
> Project: Apache Fineract
>  Issue Type: New Feature
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
> Fix For: 1.4.0
>
>
> As a side effect of  
> [https://github.com/apache/fineract/commit/aaa61695cf27419a2bc9e018fc6e2715512a1094]
>  , along with the functionality for "Predefined nominal interest rates" 
> associated with loan products, the ability to fetch the details of charges 
> paid by a loan transaction have also been added in 
> [https://github.com/apache/fineract/tree/Fineract-614.]
> Details of the relevant code changes and the functionality are present in 
> comments on github at 
> [https://github.com/apache/fineract/pull/465#pullrequestreview-212401382.]
> To merge the same into our develop branch, the API docs and Integration tests 
> needs to updated to reflect these changes



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-736) Update API docs for associating pre-defined nominal interest rates to loan products

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-736:
--
Summary: Update API docs for associating pre-defined nominal interest rates 
to loan products  (was: Update API docs for sub-rates functionality)

> Update API docs for associating pre-defined nominal interest rates to loan 
> products
> ---
>
> Key: FINERACT-736
> URL: https://issues.apache.org/jira/browse/FINERACT-736
> Project: Apache Fineract
>  Issue Type: Sub-task
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>
> With 
> [https://github.com/apache/fineract/commit/aaa61695cf27419a2bc9e018fc6e2715512a1094]
>  , the functionality for defining "sub rates" for Interest for loan products 
> has been added in [https://github.com/apache/fineract/tree/Fineract-614.]
> The API documentation for the same needs to be updated at 
> https://github.com/apache/fineract/blob/Fineract-614/api-docs/apiLive.htm



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-736) Update API docs for associating pre-defined nominal interest rates to loan products

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-736:
--
Description: 
With 
[https://github.com/apache/fineract/commit/aaa61695cf27419a2bc9e018fc6e2715512a1094]
 , the functionality for "Associating pre-defined nominal interest rates to 
loan products" has been added in 
[https://github.com/apache/fineract/tree/Fineract-614.]

The API documentation for the same needs to be updated at 
[https://github.com/apache/fineract/blob/Fineract-614/api-docs/apiLive.htm]

  was:
With 
[https://github.com/apache/fineract/commit/aaa61695cf27419a2bc9e018fc6e2715512a1094]
 , the functionality for defining "sub rates" for Interest for loan products 
has been added in [https://github.com/apache/fineract/tree/Fineract-614.]

The API documentation for the same needs to be updated at 
https://github.com/apache/fineract/blob/Fineract-614/api-docs/apiLive.htm


> Update API docs for associating pre-defined nominal interest rates to loan 
> products
> ---
>
> Key: FINERACT-736
> URL: https://issues.apache.org/jira/browse/FINERACT-736
> Project: Apache Fineract
>  Issue Type: Sub-task
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>
> With 
> [https://github.com/apache/fineract/commit/aaa61695cf27419a2bc9e018fc6e2715512a1094]
>  , the functionality for "Associating pre-defined nominal interest rates to 
> loan products" has been added in 
> [https://github.com/apache/fineract/tree/Fineract-614.]
> The API documentation for the same needs to be updated at 
> [https://github.com/apache/fineract/blob/Fineract-614/api-docs/apiLive.htm]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-614) Associating pre-defined nominal interest rates to loan products

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-614:
--
Summary: Associating pre-defined nominal interest rates to loan products  
(was: Associating pre-defined Nominal interest rates to Loan Products)

> Associating pre-defined nominal interest rates to loan products
> ---
>
> Key: FINERACT-614
> URL: https://issues.apache.org/jira/browse/FINERACT-614
> Project: Apache Fineract
>  Issue Type: Improvement
>  Components: Loan
>Affects Versions: 1.1.0
>Reporter: Angel Cajas
>Assignee: Angel Cajas
>Priority: Minor
>  Labels: external, p2
> Fix For: 1.4.0
>
>
> Nominal interest rate for loans can be composed of previously defined 
> interest rates, When a new loan product or loan account is created you can 
> choose which rates should apply for the loan.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-735) Integration test cases for associating pre-defined nominal interest rates to loan products

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-735:
--
Description: 
With 
[https://github.com/apache/fineract/commit/aaa61695cf27419a2bc9e018fc6e2715512a1094]
 , the functionality for "Associating pre-defined nominal interest rates to 
loan products" has been added in 
[https://github.com/apache/fineract/tree/Fineract-614.]

Integration tests to validate the functionality needs to be added.

  was:
With 
[https://github.com/apache/fineract/commit/aaa61695cf27419a2bc9e018fc6e2715512a1094]
 , the functionality for defining "sub rates" for Interest for loan products 
has been added in [https://github.com/apache/fineract/tree/Fineract-614.]

Integration tests to validate the functionality needs to be added.


> Integration test cases for associating pre-defined nominal interest rates to 
> loan products
> --
>
> Key: FINERACT-735
> URL: https://issues.apache.org/jira/browse/FINERACT-735
> Project: Apache Fineract
>  Issue Type: Sub-task
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>
> With 
> [https://github.com/apache/fineract/commit/aaa61695cf27419a2bc9e018fc6e2715512a1094]
>  , the functionality for "Associating pre-defined nominal interest rates to 
> loan products" has been added in 
> [https://github.com/apache/fineract/tree/Fineract-614.]
> Integration tests to validate the functionality needs to be added.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-735) Integration test cases for associating pre-defined nominal interest rates to loan products

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-735:
--
Summary: Integration test cases for associating pre-defined nominal 
interest rates to loan products  (was: Integration test cases for sub rates 
functionality)

> Integration test cases for associating pre-defined nominal interest rates to 
> loan products
> --
>
> Key: FINERACT-735
> URL: https://issues.apache.org/jira/browse/FINERACT-735
> Project: Apache Fineract
>  Issue Type: Sub-task
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>
> With 
> [https://github.com/apache/fineract/commit/aaa61695cf27419a2bc9e018fc6e2715512a1094]
>  , the functionality for defining "sub rates" for Interest for loan products 
> has been added in [https://github.com/apache/fineract/tree/Fineract-614.]
> Integration tests to validate the functionality needs to be added.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-614) Associating pre-defined Nominal interest rates to Loan Products

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-614:
--
Summary: Associating pre-defined Nominal interest rates to Loan Products  
(was: Creation of sub rates)

> Associating pre-defined Nominal interest rates to Loan Products
> ---
>
> Key: FINERACT-614
> URL: https://issues.apache.org/jira/browse/FINERACT-614
> Project: Apache Fineract
>  Issue Type: Improvement
>  Components: Loan
>Affects Versions: 1.1.0
>Reporter: Angel Cajas
>Assignee: Angel Cajas
>Priority: Minor
>  Labels: external, p2
> Fix For: 1.4.0
>
>
> Nominal interest rate for loans can be composed of previously defined 
> interest rates, When a new loan product or loan account is created you can 
> choose which rates should apply for the loan.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-737) Ability to fetch details of charges paid by a loan transaction

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-737:
--
Labels: gsoc2019  (was: )

> Ability to fetch details of charges paid by a loan transaction
> --
>
> Key: FINERACT-737
> URL: https://issues.apache.org/jira/browse/FINERACT-737
> Project: Apache Fineract
>  Issue Type: New Feature
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
> Fix For: 1.4.0
>
>
> As a side effect of  
> [https://github.com/apache/fineract/commit/aaa61695cf27419a2bc9e018fc6e2715512a1094]
>  , along with the functionality for "Predefined nominal interest rates" 
> associated with loan products, the ability to fetch the details of charges 
> paid by a loan transaction have also been added in 
> [https://github.com/apache/fineract/tree/Fineract-614.]
> Details of the relevant code changes and the functionality are present in 
> comments on github at 
> [https://github.com/apache/fineract/pull/465#pullrequestreview-212401382.]
> To merge the same into our develop branch, the API docs and Integration tests 
> need to updates to reflect these changes



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FINERACT-737) Ability to fetch details of charges paid by a loan transaction

[Vishwas Babu A J (JIRA)]

Vishwas Babu A J created FINERACT-737:
-

 Summary: Ability to fetch details of charges paid by a loan 
transaction
 Key: FINERACT-737
 URL: https://issues.apache.org/jira/browse/FINERACT-737
 Project: Apache Fineract
  Issue Type: New Feature
Reporter: Vishwas Babu A J
 Fix For: 1.4.0


As a side effect of  
[https://github.com/apache/fineract/commit/aaa61695cf27419a2bc9e018fc6e2715512a1094]
 , along with the functionality for "Predefined nominal interest rates" 
associated with loan products, the ability to fetch the details of charges paid 
by a loan transaction have also been added in 
[https://github.com/apache/fineract/tree/Fineract-614.]

Details of the relevant code changes and the functionality are present in 
comments on github at 
[https://github.com/apache/fineract/pull/465#pullrequestreview-212401382.]

To merge the same into our develop branch, the API docs and Integration tests 
need to updates to reflect these changes



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-736) Update API docs for sub-rates functionality

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-736:
--
Description: 
With 
[https://github.com/apache/fineract/commit/aaa61695cf27419a2bc9e018fc6e2715512a1094]
 , the functionality for defining "sub rates" for Interest for loan products 
has been added in [https://github.com/apache/fineract/tree/Fineract-614.]

The API documentation for the same needs to be updated at 
https://github.com/apache/fineract/blob/Fineract-614/api-docs/apiLive.htm

> Update API docs for sub-rates functionality
> ---
>
> Key: FINERACT-736
> URL: https://issues.apache.org/jira/browse/FINERACT-736
> Project: Apache Fineract
>  Issue Type: Sub-task
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>
> With 
> [https://github.com/apache/fineract/commit/aaa61695cf27419a2bc9e018fc6e2715512a1094]
>  , the functionality for defining "sub rates" for Interest for loan products 
> has been added in [https://github.com/apache/fineract/tree/Fineract-614.]
> The API documentation for the same needs to be updated at 
> https://github.com/apache/fineract/blob/Fineract-614/api-docs/apiLive.htm



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-735) Integration test cases for sub rates functionality

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-735:
--
Description: 
With 
[https://github.com/apache/fineract/commit/aaa61695cf27419a2bc9e018fc6e2715512a1094]
 , the functionality for defining "sub rates" for Interest for loan products 
has been added in [https://github.com/apache/fineract/tree/Fineract-614.]

Integration tests to validate the functionality needs to be added.

> Integration test cases for sub rates functionality
> --
>
> Key: FINERACT-735
> URL: https://issues.apache.org/jira/browse/FINERACT-735
> Project: Apache Fineract
>  Issue Type: Sub-task
>Reporter: Vishwas Babu A J
>Priority: Major
>
> With 
> [https://github.com/apache/fineract/commit/aaa61695cf27419a2bc9e018fc6e2715512a1094]
>  , the functionality for defining "sub rates" for Interest for loan products 
> has been added in [https://github.com/apache/fineract/tree/Fineract-614.]
> Integration tests to validate the functionality needs to be added.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-735) Integration test cases for sub rates functionality

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-735:
--
Labels: gsoc2019  (was: )

> Integration test cases for sub rates functionality
> --
>
> Key: FINERACT-735
> URL: https://issues.apache.org/jira/browse/FINERACT-735
> Project: Apache Fineract
>  Issue Type: Sub-task
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>
> With 
> [https://github.com/apache/fineract/commit/aaa61695cf27419a2bc9e018fc6e2715512a1094]
>  , the functionality for defining "sub rates" for Interest for loan products 
> has been added in [https://github.com/apache/fineract/tree/Fineract-614.]
> Integration tests to validate the functionality needs to be added.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FINERACT-735) Integration test cases for sub rates functionality

[Vishwas Babu A J (JIRA)]

Vishwas Babu A J created FINERACT-735:
-

 Summary: Integration test cases for sub rates functionality
 Key: FINERACT-735
 URL: https://issues.apache.org/jira/browse/FINERACT-735
 Project: Apache Fineract
  Issue Type: Sub-task
Reporter: Vishwas Babu A J






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FINERACT-736) Update API docs for sub-rates functionality

[Vishwas Babu A J (JIRA)]

Vishwas Babu A J created FINERACT-736:
-

 Summary: Update API docs for sub-rates functionality
 Key: FINERACT-736
 URL: https://issues.apache.org/jira/browse/FINERACT-736
 Project: Apache Fineract
  Issue Type: Sub-task
Reporter: Vishwas Babu A J






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINCN-139) Containerization and Deployment of the Apache Fineract CN using Docker.

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINCN-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINCN-139:
---
Issue Type: New Feature  (was: Bug)

> Containerization and Deployment of the Apache Fineract CN using Docker.
> ---
>
> Key: FINCN-139
> URL: https://issues.apache.org/jira/browse/FINCN-139
> Project: Fineract Cloud Native
>  Issue Type: New Feature
>  Components: fineract-cn-demo-server
>Reporter: Courage Angeh
>Priority: Major
>  Labels: gsoc, gsoc2019
>
> * Improve Docker-compose deployment configuration to deploy on a swarm node
>  * Implement new Fineract service to generate RSA keys and complete the 
> provisioning process.
>  * Improve provisioner and migration script to work with both a swarm cluster 
> and a single machine running multiple compose services
>  * Build and publish the Fineract images on Docker hub
>  * Link Docker Hub to Github service repositories via an Automation Server 
> pipeline
>  *



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FINERACT-700) Upgrade ancient version of Gradle

[Vishwas Babu A J (JIRA)]

[ 
https://issues.apache.org/jira/browse/FINERACT-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16799931#comment-16799931
 ] 

Vishwas Babu A J commented on FINERACT-700:
---

Thread with more details of the Flyway / Drizzle driver issue 
https://lists.apache.org/thread.html/3fade23ba553a248481bd6e066cea1548d800be1454da16bb5d2c038@%3Cdev.fineract.apache.org%3E

> Upgrade ancient version of Gradle
> -
>
> Key: FINERACT-700
> URL: https://issues.apache.org/jira/browse/FINERACT-700
> Project: Apache Fineract
>  Issue Type: Improvement
>Reporter: Michael Vorburger.ch
>Assignee: Michael Vorburger.ch
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Fineract (non-CN) uses the ancient pre-historic old Gradle 2.10 version - 
> current is 5.2.1.
> Let's try to upgrade it...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FINERACT-728) Update Integration test case and API docs for changes made to Fineract-698

[Vishwas Babu A J (JIRA)]

[ 
https://issues.apache.org/jira/browse/FINERACT-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16799360#comment-16799360
 ] 

Vishwas Babu A J commented on FINERACT-728:
---

[~muarachmann] : You can place it directly under 
/fineract-provider/src/integrationTest/java/org/apache/fineract/integrationtests

You can name the file based on the feature you are testing, Ex : 
AuditIntegrationTest and the method based on the functionality you are 
validating , Ex : shouldReturnAuditEntryAssociatedWithGUID

> Update Integration test case and API docs for changes made to Fineract-698
> --
>
> Key: FINERACT-728
> URL: https://issues.apache.org/jira/browse/FINERACT-728
> Project: Apache Fineract
>  Issue Type: Sub-task
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>
> The code changes required are in place at 
> [https://github.com/apache/fineract/pull/515].
> The same needs to be tested with an integration test and details of this 
> change needs to be updated in the API-docs
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (FINERACT-718) Fix failure with rejectShareAccount Test case

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J closed FINERACT-718.
-
Resolution: Fixed

> Fix failure with rejectShareAccount Test case
> -
>
> Key: FINERACT-718
> URL: https://issues.apache.org/jira/browse/FINERACT-718
> Project: Apache Fineract
>  Issue Type: Sub-task
>Reporter: Vishwas Babu A J
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Test case fails with below error
>  
> {code:java}
> org.junit.ComparisonFailure: expected:<5[2].0> but was:<5[0].0>
> at org.junit.Assert.assertEquals(Assert.java:115)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at 
> org.apache.fineract.integrationtests.common.shares.ShareAccountIntegrationTests.rejectShareAccount(ShareAccountIntegrationTests.java:270)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-713) Improve code-coverage to at-least 50% and reduce execution time

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-713:
--
Description: 
While Fineract has integration tests, they currently cover very limited 
scenarios and code coverage is very low.

Enable gradle plugins to report the current code coverage and add new 
Integration tests to ensure that code coverage, esp in critical packages like 
loans, savings, and accounting is at-least 50%. Once the packages with low code 
coverage have been identified, we could take the help of [~santoshmath] to 
collect manual test cases covering these packages and go about automating the 
same.

Also, the existing tests are run sequentially and take around 23 minutes to 
complete on [https://travis-ci.org/apache/fineract.] Along with improving code 
coverage, we would also have to determine which tests can be run in parallel 
and enable parallelization to ensure the total time taken is still reasonable.

  was:
While Fineract has integration tests, they currently cover very limited 
scenarios and code coverage is very low.

Enable gradle plugins to report the current code coverage and add new 
Integration tests to ensure that code coverage, esp in critical packages like 
loans, savings, and accounting is at-least 50%.

Also, the existing tests are run sequentially and take around 23 minutes to 
complete on [https://travis-ci.org/apache/fineract.] Along with improving code 
coverage, we would also have to determine which tests can be run in parallel 
and enable parallelization to ensure the total time taken is still reasonable.


> Improve code-coverage to at-least 50% and reduce execution time
> ---
>
> Key: FINERACT-713
> URL: https://issues.apache.org/jira/browse/FINERACT-713
> Project: Apache Fineract
>  Issue Type: Improvement
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> While Fineract has integration tests, they currently cover very limited 
> scenarios and code coverage is very low.
> Enable gradle plugins to report the current code coverage and add new 
> Integration tests to ensure that code coverage, esp in critical packages like 
> loans, savings, and accounting is at-least 50%. Once the packages with low 
> code coverage have been identified, we could take the help of [~santoshmath] 
> to collect manual test cases covering these packages and go about automating 
> the same.
> Also, the existing tests are run sequentially and take around 23 minutes to 
> complete on [https://travis-ci.org/apache/fineract.] Along with improving 
> code coverage, we would also have to determine which tests can be run in 
> parallel and enable parallelization to ensure the total time taken is still 
> reasonable.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FINERACT-407) Ability to Re-open closed Accounts (especially Savings and Share Accounts)

[Vishwas Babu A J (JIRA)]

[ 
https://issues.apache.org/jira/browse/FINERACT-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798419#comment-16798419
 ] 

Vishwas Babu A J commented on FINERACT-407:
---

[~edcable] , [~santoshmath] : I have not looked into the dormancy functionality 
as implemented in Fineract . However , I have read the spec and it isn’t clear 
if there are accounting entries associated with moving an account to dormancy ( 
or this is used as just a reporting flag ?).
 
If moving the account to dormancy has accounting entries , then we would have 
to ask the reporter to use the same instead of closing accounts that are 
inactive (as long as the funds are moved into a configurable liability account 
, I am assuming this would meet the needs the reporter is trying to satisfy by 
closing unused accounts from an accounting perspective )

> Ability to Re-open closed Accounts (especially Savings and Share Accounts)
> --
>
> Key: FINERACT-407
> URL: https://issues.apache.org/jira/browse/FINERACT-407
> Project: Apache Fineract
>  Issue Type: Improvement
>  Components: Savings
>Reporter: Ippez Roberts
>Assignee: Markus Geiss
>Priority: Major
>  Labels: Fineract-CN, gsoc, p3
>
> When a client has not make transactions for many years for example, the MFI 
> may not know if the client is alive or dead so the MFI can decide to close 
> this client's Accounts (Savings and Share Accounts). The balances of this 
> account can be transferred to a GL Account.
> Client - GL Transfer: DR Client Accounts and CR. GL Account e.g Share Transfer
> After some time, the client surfaces and would like to make transactions on 
> his accounts.
> As a system admin, i should be able to re-open these closed accounts and be 
> able to transfer the balances from the contra Account back to client's 
> Savings Account either automatically or manually through batch/journal 
> Entries where you DR. GL Accounts affected (where the balances are 
> transferred) and Credit Clients Savings and Share Accounts with the balances 
> at closure.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINCN-139) Containerization and Deployment of the Apache Fineract CN using Docker.

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINCN-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINCN-139:
---
Summary: Containerization and Deployment of the Apache Fineract CN using 
Docker.  (was: Containerization and Deployement of the Apache Fineract CN using 
Docker.)

> Containerization and Deployment of the Apache Fineract CN using Docker.
> ---
>
> Key: FINCN-139
> URL: https://issues.apache.org/jira/browse/FINCN-139
> Project: Fineract Cloud Native
>  Issue Type: Bug
>  Components: fineract-cn-demo-server
>Reporter: Courage Angeh
>Priority: Major
>  Labels: gsoc, gsoc2019
>
> * Improve Docker-compose deployment configuration to deploy on a swarm node
>  * Implement new Fineract service to generate RSA keys and complete the 
> provisioning process.
>  * Improve provisioner and migration script to work with both a swarm cluster 
> and a single machine running multiple compose services
>  * Build and publish the Fineract images on Docker hub
>  * Link Docker Hub to Github service repositories via an Automation Server 
> pipeline
>  *



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FINERACT-239) Ability to adjust Principal and Interest as a super user

[Vishwas Babu A J (JIRA)]

[ 
https://issues.apache.org/jira/browse/FINERACT-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16797827#comment-16797827
 ] 

Vishwas Babu A J commented on FINERACT-239:
---

[~edcable] : All the business scenarios are valid. However, it might be better 
from a usability perspective to provide more graceful support at the portfolio 
level for handling the same rather than allowing debits/credits.

For Ex: *Scenario Credit Principal*. This allows you to correct an erroneous 
posting of disbursement, whether a wrong amount was posted for the disbursement 
or it was posted to a wrong account.

You can do the same on Fineract 1.x by 
 * Undoing the disbursal
 * Making a new disbursal on the same account or another loan account

The core underlying issue that needs to be fixed on Fineract 1.x (and possibly 
Fineract CN ?) for this to work in all scenarios is that the system tracks only 
two dates for transactions and associated journal entries, namely
 # Created Date: Timestamp on which the transaction was created
 # Transaction Date: Date on which the change is affected due to the 
transaction. The same is carried over as the "Entry date" on the Journal 
(affects accounting books). This common terminology for this being "value date"

However, this leads to complications when accounting closures are done 
(typically on a daily basis is mature organizations). The branch would now need 
to remove the accounting closure to correct such mistakes in the past as the 
"Transaction date" on the loan/savings and the "Entry" date on the journal are 
the same.

The change needed for addressing the same would be to optionally delink these 
dates, i.e a separate "Entry date" which can be associated with transactions 
and then carried over to the journal entries that need to be made on a 
different day than the transaction date.

If this isn't already a part of Fineract-CN, then we should definitely 
prioritize the same.

 

> Ability to adjust Principal and Interest as a super user
> 
>
> Key: FINERACT-239
> URL: https://issues.apache.org/jira/browse/FINERACT-239
> Project: Apache Fineract
>  Issue Type: Improvement
>  Components: Loan
>Reporter: Dayna Harp
>Assignee: Markus Geiss
>Priority: Major
>  Labels: Fineract-CN, gsoc, large, p3
>
> https://mifosforge.jira.com/browse/MIFOSX-2518
> This should allow you to make adjustments on the principal and/or interest 
> balances of a loan account for correction purposes. The adjustment process 
> should always be a voucher transaction not cash and should be fixed by 
> default.
> *Credit Principal*. This allows you to correct an erroneous posting of 
> disbursement, whether a wrong amount was posted for the disbursement or it 
> was posted to a wrong account.
> *Debit Principal*. This allows you to correct an erroneous posting of a 
> repayment, whether a wrong amount was posted or it was posted to a wrong 
> account.
> *Credit Accrual. *This allows you to correct erroneous posting of loan 
> accruals—interest, penalties and charges—to an account or to waive penalties. 
> This is also used to reduce accruals whenever there was a delay in the 
> posting of a repayment.
> *Debit Accrual.* This allows you to apply loan accruals—interest, penalties 
> and charges—to an account in cases of repayment cancellation. This is 
> particularly necessary if the cancellation occurred after the day that the 
> repayment was posted



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (FINERACT-729) Handle exception in downloading bulk import tool

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J resolved FINERACT-729.
---
Resolution: Fixed

> Handle exception in downloading bulk import tool 
> -
>
> Key: FINERACT-729
> URL: https://issues.apache.org/jira/browse/FINERACT-729
> Project: Apache Fineract
>  Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Vishwas Babu A J
>Priority: Major
> Fix For: 1.3.0
>
>
> [LoanRepaymentWorkbookPopulator.java|https://github.com/apache/fineract/pull/472/files#diff-415f5ca056159a584caaea69aa11024b]
>  tries to parse a String value (Loan Account Number) as Long



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FINERACT-424) SELF-SERVICE: store 4 digit pin on back-end

[Vishwas Babu A J (JIRA)]

[ 
https://issues.apache.org/jira/browse/FINERACT-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796693#comment-16796693
 ] 

Vishwas Babu A J commented on FINERACT-424:
---

[~edcable] : For a self-service user, I would think that the authentication 
should always be two-factor (i.e "something they know" and "something they 
have"). While the "something they have" has to be stored locally, and the 
"something they know" should not.

For a mobile device
 * The "something they have" could be a unique identifier associated with the 
Mobile device when it is first registered with the Fineract server. This would 
be unique to each Mobile device the user has and would be stored on the server 
side as well (Storing OAuth access and refresh tokens generated after login, as 
would be the case with Fineract 1.x should work equally well IMHO) 
 * The "something they know" could be the passcode which is stored only on the 
server.

Logging in would involve sending both these information to the server (even 
though the user enters only the passcode). I am not sure what is more common, 
having separate passcodes for each device or having a passcode for a user. 
Either way, as long as each device needs to be registered (and get it's own 
unique "something they have" ), I guess it shouldn't make much too different 
from a security perspective.

 

> SELF-SERVICE: store 4 digit pin on back-end
> ---
>
> Key: FINERACT-424
> URL: https://issues.apache.org/jira/browse/FINERACT-424
> Project: Apache Fineract
>  Issue Type: New Feature
>Reporter: Edward Cable
>Assignee: Markus Geiss
>Priority: Major
>  Labels: gsoc, p3
>
> First off, in order to make it easier for a user to log in and not have to 
> fully authenticate themselves each time they leave the self-service app, we 
> wanted to enable a 4 digit pin code that could be used to log in to the app 
> (once fully authenticated for a first time). This is pretty standard practice 
> in banking apps.
> We didn't want to store that locally since it wouldn't be secure on phones 
> that are rooted.
> With that constraint, we need to be able to store this pin on the back-end - 
> then it can also be shared across phones as well.
> See https://github.com/openMF/self-service-app/issues/115 and 
> https://github.com/openMF/self-service-app/issues/132



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (FINERACT-210) Database Tampering and Detection of Data Fraud by Using the Forensic Scrutiny Technique

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J resolved FINERACT-210.
---
Resolution: Won't Do
  Assignee: (was: Markus Geiss)

> Database Tampering and Detection of Data Fraud by Using the Forensic Scrutiny 
> Technique
> ---
>
> Key: FINERACT-210
> URL: https://issues.apache.org/jira/browse/FINERACT-210
> Project: Apache Fineract
>  Issue Type: New Feature
>Reporter: Ippez Roberts
>Priority: Major
>  Labels: gsoc, p3
>
> Abstract
> Database Tampering and the Data Fiddle is one of the important role in 
> Database Management System (DBMS).To Provide the security to the Data Storage 
> Has Become Requirement of our time. The Main Objective of this is to choose 
> among different techniques the best and detection of different Places in 
> Database. We could use the cryptographic hash
> algorithm to discover the tampering of a Database. Consequently the Tiled 
> Bitmap Forensic analysis algorithm helps to find at what time and possibly 
> finally who and why Tamper the Database. This algorithm establish the concept 
> of applicant places (possible places of spot tampering) and prevent the 
> intruder, the computing of the candidate set is
> also presented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FINERACT-227) Option For Creating Loan Loss provisioning for total principle outstanding or total outstanding

[Vishwas Babu A J (JIRA)]

[ 
https://issues.apache.org/jira/browse/FINERACT-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796602#comment-16796602
 ] 

Vishwas Babu A J commented on FINERACT-227:
---

[~edcable] : It's not been merged, see 
https://github.com/apache/fineract/pull/221

> Option For Creating Loan Loss provisioning for total principle outstanding or 
> total outstanding
> ---
>
> Key: FINERACT-227
> URL: https://issues.apache.org/jira/browse/FINERACT-227
> Project: Apache Fineract
>  Issue Type: Improvement
>  Components: Loan
>Reporter: venkat Ganesh
>Assignee: Markus Geiss
>Priority: Major
>  Labels: gsoc, p2
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FINERACT-210) Database Tampering and Detection of Data Fraud by Using the Forensic Scrutiny Technique

[Vishwas Babu A J (JIRA)]

[ 
https://issues.apache.org/jira/browse/FINERACT-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796600#comment-16796600
 ] 

Vishwas Babu A J commented on FINERACT-210:
---

[~edcable] : In my view, database security, encryption at rest etc are beyond 
the scope of Fineract. The hosted database vendors (like Aurora on AWS) provide 
various options for the same.

> Database Tampering and Detection of Data Fraud by Using the Forensic Scrutiny 
> Technique
> ---
>
> Key: FINERACT-210
> URL: https://issues.apache.org/jira/browse/FINERACT-210
> Project: Apache Fineract
>  Issue Type: New Feature
>Reporter: Ippez Roberts
>Assignee: Markus Geiss
>Priority: Major
>  Labels: gsoc, p3
>
> Abstract
> Database Tampering and the Data Fiddle is one of the important role in 
> Database Management System (DBMS).To Provide the security to the Data Storage 
> Has Become Requirement of our time. The Main Objective of this is to choose 
> among different techniques the best and detection of different Places in 
> Database. We could use the cryptographic hash
> algorithm to discover the tampering of a Database. Consequently the Tiled 
> Bitmap Forensic analysis algorithm helps to find at what time and possibly 
> finally who and why Tamper the Database. This algorithm establish the concept 
> of applicant places (possible places of spot tampering) and prevent the 
> intruder, the computing of the candidate set is
> also presented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FINERACT-322) Rewarding Early Repayment

[Vishwas Babu A J (JIRA)]

[ 
https://issues.apache.org/jira/browse/FINERACT-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16796592#comment-16796592
 ] 

Vishwas Babu A J commented on FINERACT-322:
---

[~edcable] : Using "Declining balance" or "Flat" as the interest method would 
calculate the interest on the initially generated schedule accordingly. This 
issue report doesn't deal with the initial interest calculation, rather the 
"Payment apportioning logic", in particular, what happens when a pre-payment is 
made?

[~santoshmath] : The user expects the future interest to be recalculated if 
there is any prepayment. I would assume that he hasn't used the interest 
recalculation option, using the same should mostly meet his requirement. If he 
doesn't expect interest recalculation to run in all scenarios (late payment 
etc) , you could also use the repayment strategy "Early payment strategy" 
instead.

The behavior of early payments on the same is as follows: For any payment that 
pays off an installment that occurs before the due date of the installment, 
payments are allocated only towards principal payments of future installments. 
Interest and fees/penalties of future installments are not paid and may be 
waived manually if required. See 
[https://demo.openmf.org/api-docs/apiLive.htm#paymentapplicationlogic] for 
details

> Rewarding Early Repayment
> -
>
> Key: FINERACT-322
> URL: https://issues.apache.org/jira/browse/FINERACT-322
> Project: Apache Fineract
>  Issue Type: Improvement
>  Components: Loan
>Reporter: Santosh Math
>Assignee: Markus Geiss
>Priority: Minor
>  Labels: gsoc, p2
>
> Reported by Shepard Chihoro at https://mifosforge.jira.com/browse/MIFOSX-2520
> Original Description:
> MIFOSX does not reward customers who make early repayments on a flat interest 
> calculation method.My normal client contract is has a maximum repayment 
> period of 6 months and a minimum repayment period of 3 months.On 
> disbursement,MIFOSX calculates the interest for the entire 6 months and makes 
> principal and interest for 6 months outstanding.In the event that the 
> customer repays the full principal in 3 months,the customer`s account remains 
> with 3 months interest due.I would like to see interest outstanding being 
> stopped once the principal has been repaid in full.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-733) Swagger Documentation for Fineract API's

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-733:
--
Labels: gsoc2019  (was: )

> Swagger Documentation for Fineract API's
> 
>
> Key: FINERACT-733
> URL: https://issues.apache.org/jira/browse/FINERACT-733
> Project: Apache Fineract
>  Issue Type: Improvement
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
> Fix For: 1.4.0
>
> Attachments: Screen Shot 2019-03-17 at 3.59.23 AM.png
>
>
> The original documentation for Fineract is at 
> [https://github.com/apache/fineract/blob/develop/api-docs/apiLive.htm.] This 
> documentation was handcrafted to meet the following goals
>  # Provide a detailed overview of the API design and common options (under 
> "Overview" section of the top Navbar at 
> [https://demo.openmf.org/api-docs/apiLive.htm|https://demo.openmf.org/api-docs/apiLive.htm#loans])
>  # Help consumers to easily visualize related API's to quickly determine the 
> scope of functionality supported by the system ( Ex: links to all loan 
> related API's consolidated under the "Loan" section of the navbar)
>  # For each entity in the system, provide a meaningful description of what 
> the entity represents in the real world (Ex: 
> [https://demo.openmf.org/api-docs/apiLive.htm#glaccounts] )
>  # For common fields associated with an entity, provide a meaningful 
> description of what they represent and how they are to be used (Ex: 
> [https://demo.openmf.org/api-docs/apiLive.htm#loans] , see the description 
> and detailed explanation of fields like transactionProcessingStrategyId )
>  # Provide a detailed overview of the functionality supported by each API 
> call (especially when their usage is not obvious, see the detailed 
> documentation for Batch API's at 
> [https://demo.openmf.org/api-docs/apiLive.htm#batch_api] )
>  # Provide examples of sample requests and responses for each API call
> However, this documentation suffered a major drawback, i.e all of it was 
> handwritten and was difficult for new committers to add to and maintain. It 
> was also preferable that users be allowed to try out all API's from the 
> documentation itself, which wasn't an option.
> The newly added Swagger documentation aims to address these concerns. The 
> current status of the same and the work needed to meet the goals of the 
> original documentation is described below
>  
> *Goal 1* 
> The swagger docs rely on the existing API docs through hyperlinks for the 
> entire overview section. To make the swagger docs the single source of truth 
> for API documentation, the existing docs need to be deprecated. For doing the 
> same, this entire section needs to be copied over to the swagger UI (and well 
> formatted) and all references to the older docs removed. ** 
> *Goal 2* 
> All API's are currently listed in a random order and someone new to the 
> system cannot comprehend relationships between them. The home page needs to 
> be improved with either a sidebar or a navbar (similar to the one in the 
> existing documentation) which groups together related API's and provides 
> hyperlinks to their swagger documentation
> *Goal 3* 
> While entity descriptions seem to be present in the codebase (Ex: 
> https://github.com/apache/fineract/blob/201cbf82f67f7a623b8c38bf9465f4af79791c20/fineract-provider/src/main/java/org/apache/fineract/portfolio/savings/api/SavingsAccountsApiResource.java#L76),
>  they aren't reflected in the generated documentation. This is likely because 
> the description field is deprecated, see discussion at 
> [https://github.com/swagger-api/swagger-core/issues/1476.] 
> It would be nice if this description was well formatted too.
> *Goal 4* 
> Taking [https://demo.openmf.org/api-docs/apiLive.htm#loans] as an example, 
> the details and descriptions of fields like "transactionProcessingStrategyId" 
> are not carried over. Without this information, an API consumer would not 
> understand what each of these (non-obvious) fields mean and how they are to 
> be used.
> *Goal 5* 
> The amount of information present for an API like 
> [https://demo.openmf.org/api-docs/apiLive.htm#batch_api] is significantly 
> more than that of the equivalent API in Swagger (detailed description, 
> possible errors, command strategies supported etc). We would need to go 
> through each API to ensure that all information is migrated.
> Here's a screenshot of another commonly used API for updating loan statuses 
> from swagger docs. 
> !Screen Shot 2019-03-17 at 3.59.23 AM.png|width=807,height=519!
> Issues here
>  * Details of actual commands supported (approve, reject) are missing
>  * Lack of formatting makes it hard to read
> *Goal 6* 
> At first glance, it looks like the swagger documentation does a good 

[jira] [Updated] (FINERACT-733) Swagger Documentation for Fineract API's

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-733:
--
Description: 
The original documentation for Fineract is at 
[https://github.com/apache/fineract/blob/develop/api-docs/apiLive.htm.] This 
documentation was handcrafted to meet the following goals
 # Provide a detailed overview of the API design and common options (under 
"Overview" section of the top Navbar at 
[https://demo.openmf.org/api-docs/apiLive.htm|https://demo.openmf.org/api-docs/apiLive.htm#loans])
 # Help consumers to easily visualize related API's to quickly determine the 
scope of functionality supported by the system ( Ex: links to all loan related 
API's consolidated under the "Loan" section of the navbar)
 # For each entity in the system, provide a meaningful description of what the 
entity represents in the real world (Ex: 
[https://demo.openmf.org/api-docs/apiLive.htm#glaccounts] )
 # For common fields associated with an entity, provide a meaningful 
description of what they represent and how they are to be used (Ex: 
[https://demo.openmf.org/api-docs/apiLive.htm#loans] , see the description and 
detailed explanation of fields like transactionProcessingStrategyId )
 # Provide a detailed overview of the functionality supported by each API call 
(especially when their usage is not obvious, see the detailed documentation for 
Batch API's at [https://demo.openmf.org/api-docs/apiLive.htm#batch_api] )
 # Provide examples of sample requests and responses for each API call

However, this documentation suffered a major drawback, i.e all of it was 
handwritten and was difficult for new committers to add to and maintain. It was 
also preferable that users be allowed to try out all API's from the 
documentation itself, which wasn't an option.

The newly added Swagger documentation aims to address these concerns. The 
current status of the same and the work needed to meet the goals of the 
original documentation is described below

 

*Goal 1* 

The swagger docs rely on the existing API docs through hyperlinks for the 
entire overview section. To make the swagger docs the single source of truth 
for API documentation, the existing docs need to be deprecated. For doing the 
same, this entire section needs to be copied over to the swagger UI (and well 
formatted) and all references to the older docs removed. ** 

*Goal 2* 

All API's are currently listed in a random order and someone new to the system 
cannot comprehend relationships between them. The home page needs to be 
improved with either a sidebar or a navbar (similar to the one in the existing 
documentation) which groups together related API's and provides hyperlinks to 
their swagger documentation

*Goal 3* 

While entity descriptions seem to be present in the codebase (Ex: 
https://github.com/apache/fineract/blob/201cbf82f67f7a623b8c38bf9465f4af79791c20/fineract-provider/src/main/java/org/apache/fineract/portfolio/savings/api/SavingsAccountsApiResource.java#L76),
 they aren't reflected in the generated documentation. This is likely because 
the description field is deprecated, see discussion at 
[https://github.com/swagger-api/swagger-core/issues/1476.] 

It would be nice if this description was well formatted too.

*Goal 4* 

Taking [https://demo.openmf.org/api-docs/apiLive.htm#loans] as an example, the 
details and descriptions of fields like "transactionProcessingStrategyId" are 
not carried over. Without this information, an API consumer would not 
understand what each of these (non-obvious) fields mean and how they are to be 
used.

*Goal 5* 

The amount of information present for an API like 
[https://demo.openmf.org/api-docs/apiLive.htm#batch_api] is significantly more 
than that of the equivalent API in Swagger (detailed description, possible 
errors, command strategies supported etc). We would need to go through each API 
to ensure that all information is migrated.

Here's a screenshot of another commonly used API for updating loan statuses 
from swagger docs. 

!Screen Shot 2019-03-17 at 3.59.23 AM.png|width=807,height=519!

Issues here
 * Details of actual commands supported (approve, reject) are missing
 * Lack of formatting makes it hard to read

*Goal 6* 

At first glance, it looks like the swagger documentation does a good job here. 
We probably need a round of QA to certify the same 

 

 

 

  was:
The original documentation for Fineract is at 
[https://github.com/apache/fineract/blob/develop/api-docs/apiLive.htm.] This 
documentation was handcrafted to meet the following goals
 # Provide a detailed overview of the API design and common options (under 
"Overview" section of the main drop-down menu)
 # Help consumers to easily visualize related API's to quickly determine the 
scope of functionality supported by the system ( Ex: links to all loan related 
API's consolidated under the "Loan" section of the drop-down 

[jira] [Updated] (FINERACT-733) Swagger Documentation for Fineract API's

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-733:
--
Attachment: Screen Shot 2019-03-17 at 3.59.23 AM.png

> Swagger Documentation for Fineract API's
> 
>
> Key: FINERACT-733
> URL: https://issues.apache.org/jira/browse/FINERACT-733
> Project: Apache Fineract
>  Issue Type: Improvement
>Reporter: Vishwas Babu A J
>Priority: Major
> Fix For: 1.4.0
>
> Attachments: Screen Shot 2019-03-17 at 3.59.23 AM.png
>
>
> The original documentation for Fineract is at 
> [https://github.com/apache/fineract/blob/develop/api-docs/apiLive.htm.] This 
> documentation was handcrafted to meet the following goals
>  # Provide a detailed overview of the API design and common options (under 
> "Overview" section of the main drop-down menu)
>  # Help consumers to easily visualize related API's to quickly determine the 
> scope of functionality supported by the system ( Ex: links to all loan 
> related API's consolidated under the "Loan" section of the drop-down menu)
>  # For each entity in the system, provide a meaningful description of what 
> the entity represents in the real world (Ex: 
> [https://demo.openmf.org/api-docs/apiLive.htm#glaccounts] )
>  # For common fields associated with an entity, provide a meaningful 
> description of what they represent and how they are to be used (Ex: 
> [https://demo.openmf.org/api-docs/apiLive.htm#loans] , see the description 
> and detailed explanation of fields like transactionProcessingStrategyId )
>  # Provide a detailed overview of the functionality supported by each API 
> call (especially when their usage is not obvious, see the detailed 
> documentation for Batch API's at 
> https://demo.openmf.org/api-docs/apiLive.htm#batch_api )
>  # Provide examples of sample requests and responses for each API call
> However, this documentation suffered a major drawback, i.e all of it was 
> handwritten and was difficult for new committers to add to and maintain. It 
> was also preferable that users be allowed to try out all API's from the 
> documentation itself, which wasn't an option.
> The newly added Swagger documentation aims to address these concerns. 
>  
>  
>  
>  
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-733) Swagger Documentation for Fineract API's

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-733:
--
Description: 
The original documentation for Fineract is at 
[https://github.com/apache/fineract/blob/develop/api-docs/apiLive.htm.] This 
documentation was handcrafted to meet the following goals
 # Provide a detailed overview of the API design and common options (under 
"Overview" section of the main drop-down menu)
 # Help consumers to easily visualize related API's to quickly determine the 
scope of functionality supported by the system ( Ex: links to all loan related 
API's consolidated under the "Loan" section of the drop-down menu)
 # For each entity in the system, provide a meaningful description of what the 
entity represents in the real world (Ex: 
[https://demo.openmf.org/api-docs/apiLive.htm#glaccounts] )
 # For common fields associated with an entity, provide a meaningful 
description of what they represent and how they are to be used (Ex: 
[https://demo.openmf.org/api-docs/apiLive.htm#loans] , see the description and 
detailed explanation of fields like transactionProcessingStrategyId )
 # Provide a detailed overview of the functionality supported by each API call 
(especially when their usage is not obvious, see the detailed documentation for 
Batch API's at https://demo.openmf.org/api-docs/apiLive.htm#batch_api )
 # Provide examples of sample requests and responses for each API call

However, this documentation suffered a major drawback, i.e all of it was 
handwritten and was difficult for new committers to add to and maintain. It was 
also preferable that users be allowed to try out all API's from the 
documentation itself, which wasn't an option.

The newly added Swagger documentation aims to address these concerns. 

 

 

 

 

 

 

 

> Swagger Documentation for Fineract API's
> 
>
> Key: FINERACT-733
> URL: https://issues.apache.org/jira/browse/FINERACT-733
> Project: Apache Fineract
>  Issue Type: Improvement
>Reporter: Vishwas Babu A J
>Priority: Major
> Fix For: 1.4.0
>
>
> The original documentation for Fineract is at 
> [https://github.com/apache/fineract/blob/develop/api-docs/apiLive.htm.] This 
> documentation was handcrafted to meet the following goals
>  # Provide a detailed overview of the API design and common options (under 
> "Overview" section of the main drop-down menu)
>  # Help consumers to easily visualize related API's to quickly determine the 
> scope of functionality supported by the system ( Ex: links to all loan 
> related API's consolidated under the "Loan" section of the drop-down menu)
>  # For each entity in the system, provide a meaningful description of what 
> the entity represents in the real world (Ex: 
> [https://demo.openmf.org/api-docs/apiLive.htm#glaccounts] )
>  # For common fields associated with an entity, provide a meaningful 
> description of what they represent and how they are to be used (Ex: 
> [https://demo.openmf.org/api-docs/apiLive.htm#loans] , see the description 
> and detailed explanation of fields like transactionProcessingStrategyId )
>  # Provide a detailed overview of the functionality supported by each API 
> call (especially when their usage is not obvious, see the detailed 
> documentation for Batch API's at 
> https://demo.openmf.org/api-docs/apiLive.htm#batch_api )
>  # Provide examples of sample requests and responses for each API call
> However, this documentation suffered a major drawback, i.e all of it was 
> handwritten and was difficult for new committers to add to and maintain. It 
> was also preferable that users be allowed to try out all API's from the 
> documentation itself, which wasn't an option.
> The newly added Swagger documentation aims to address these concerns. 
>  
>  
>  
>  
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FINERACT-733) Swagger Documentation for Fineract API's

[Vishwas Babu A J (JIRA)]

Vishwas Babu A J created FINERACT-733:
-

 Summary: Swagger Documentation for Fineract API's
 Key: FINERACT-733
 URL: https://issues.apache.org/jira/browse/FINERACT-733
 Project: Apache Fineract
  Issue Type: Improvement
Reporter: Vishwas Babu A J
 Fix For: 1.4.0






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (FINERACT-684) Create and approve loan in batch mode with transaction true fails

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J resolved FINERACT-684.
---
   Resolution: Fixed
Fix Version/s: (was: 1.4.0)
   1.3.0

> Create and approve loan in batch mode with transaction true fails
> -
>
> Key: FINERACT-684
> URL: https://issues.apache.org/jira/browse/FINERACT-684
> Project: Apache Fineract
>  Issue Type: Bug
>  Components: Loan
>Affects Versions: 1.1.0
>Reporter: sapana
>Priority: Major
>  Labels: p1
> Fix For: 1.3.0
>
> Attachments: BatchRequest.txt
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> For pre-approved loans, requirement is to create, approve and disburse loan 
> as part of single batch request with transaction set to true. It fails with 
> Nil pointer exception. 
> Couple of observations:
> 1. if enclosingTransaction=true is not specified, the request works. Only 
> fails with transaction mode on
> 2. If enclosingTransaction=true is specified, and the batch request is to 
> create loan, and approve a pre-existing loan, it works.
>  sample request attached.
> error msg recieved:
> [
> {
> "statusCode": 400,
> "body": "Transaction is being rolled back. First erroneous request: 
> \n{\"requestId\":3,\"statusCode\":500,\"headers\":[{\"name\":\"Content-type\",\"value\":\"text/html\"}],\"body\":\"{\\\"Exception\\\":
>  java.lang.NullPointerException}\"}"
> }
> ]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FINERACT-135) Performance improvement using EHCache or any other cache managers

[Vishwas Babu A J (JIRA)]

[ 
https://issues.apache.org/jira/browse/FINERACT-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16788752#comment-16788752
 ] 

Vishwas Babu A J commented on FINERACT-135:
---

[~jwilke] : Our platform codebase is on [https://github.com/apache/fineract] . 
A summary of the work on caching done so far is at 
[https://mifosforge.jira.com/wiki/spaces/projects/pages/38600834/GSOC+2013+-+Distributed+Caching+support#GSOC2013-DistributedCachingsupport-Challenges]
 . 

By default, caching is disabled on the system and can be enabled by turning on 
a Global configuration: 
[https://mifosforge.jira.com/wiki/spaces/docs/pages/67895362/Global+Configuration]
 describes how this can be done from the MifosX User interface

Some useful links to files on the platform codebase :

Ex of Caching : 
https://github.com/apache/fineract/blob/e0cb00315b25293cb8a5067c84a259f1cd03146d/fineract-provider/src/main/java/org/apache/fineract/organisation/office/service/OfficeReadPlatformServiceImpl.java#L150

Ex of Cache Eviction: 
[https://github.com/apache/fineract/blob/e0cb00315b25293cb8a5067c84a259f1cd03146d/fineract-provider/src/main/java/org/apache/fineract/organisation/office/service/OfficeWritePlatformServiceJpaRepositoryImpl.java#L86]

Files related to Cache setup: [^Screen Shot 2019-03-09 at 9.16.48 AM.png]

[~edcable] : Do you know if any organization is facing performance issues and 
looking at enabling Caching on Fineract ?  Would it be something that makes 
sense for a MifosX GSOC project that Jens could possibly help on?

 

> Performance improvement using EHCache or any other cache managers
> -
>
> Key: FINERACT-135
> URL: https://issues.apache.org/jira/browse/FINERACT-135
> Project: Apache Fineract
>  Issue Type: Improvement
>Reporter: Binny Gopinath Sreevas
>Assignee: Markus Geiss
>Priority: Critical
>  Labels: gsoc2019
> Attachments: Screen Shot 2019-03-09 at 9.16.48 AM.png
>
>
> In a production environment wiith about 130,000 clients with loans - the 
> performance of the loan APIs are poor. I have been told is that enabling 
> EHCache and making it work will definitely improve the performance. Can this 
> be done and tested for deployment scenarios - including multi-tenant setup 
> and load balanced (multiple tomcats/FINERACT instances which talk to the same 
> database).
> Reference to previous work on this:
> https://mifosforge.jira.com/wiki/display/projects/GSOC+2013+-+Distributed+Caching+support



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-135) Performance improvement using EHCache or any other cache managers

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-135:
--
Attachment: Screen Shot 2019-03-09 at 9.16.48 AM.png

> Performance improvement using EHCache or any other cache managers
> -
>
> Key: FINERACT-135
> URL: https://issues.apache.org/jira/browse/FINERACT-135
> Project: Apache Fineract
>  Issue Type: Improvement
>Reporter: Binny Gopinath Sreevas
>Assignee: Markus Geiss
>Priority: Critical
>  Labels: gsoc2019
> Attachments: Screen Shot 2019-03-09 at 9.16.48 AM.png
>
>
> In a production environment wiith about 130,000 clients with loans - the 
> performance of the loan APIs are poor. I have been told is that enabling 
> EHCache and making it work will definitely improve the performance. Can this 
> be done and tested for deployment scenarios - including multi-tenant setup 
> and load balanced (multiple tomcats/FINERACT instances which talk to the same 
> database).
> Reference to previous work on this:
> https://mifosforge.jira.com/wiki/display/projects/GSOC+2013+-+Distributed+Caching+support



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FINERACT-712) Fineract codebase should pass PMD, Findbugs and Checkstyle analysis

[Vishwas Babu A J (JIRA)]

[ 
https://issues.apache.org/jira/browse/FINERACT-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16788731#comment-16788731
 ] 

Vishwas Babu A J commented on FINERACT-712:
---

[~coderquill] : We are not yet sure who the mentor will be. Any of the Fineract 
committers or I can answer the queries you have. For max visibility,  please 
address your question to our mailing list

> Fineract codebase should pass PMD, Findbugs and Checkstyle analysis
> ---
>
> Key: FINERACT-712
> URL: https://issues.apache.org/jira/browse/FINERACT-712
> Project: Apache Fineract
>  Issue Type: Improvement
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>   Original Estimate: 80h
>  Remaining Estimate: 80h
>
> The fineract codebase has findbugs (now spotbugs) and PMD gradle plugins, 
> however, the ignoreFailures option is enabled on the gradle file. Disabling 
> the same and fixing current errors is crucial for the long term 
> maintainability of the Fineract project.
> Another good to have would be checkstyle analysis.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FINERACT-415) Loan product should not allow to be created and should throw proper error when mandatory guarantee is not equal to any one of the guarantee(own or guarantor) or sum o

[Vishwas Babu A J (JIRA)]

[ 
https://issues.apache.org/jira/browse/FINERACT-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16788733#comment-16788733
 ] 

Vishwas Babu A J commented on FINERACT-415:
---

[~trush] : Please feel to work on any issue you want. Also, it might be a good 
idea to address your queries to our mailing lists as not all committers are 
subscribed to Jira alerts

> Loan product should not allow to be created and should throw proper error 
> when mandatory guarantee is not equal to any one of the guarantee(own or 
> guarantor) or sum of both
> 
>
> Key: FINERACT-415
> URL: https://issues.apache.org/jira/browse/FINERACT-415
> Project: Apache Fineract
>  Issue Type: Bug
>  Components: Loan
>Reporter: Santosh Math
>Assignee: Markus Geiss
>Priority: Major
>  Labels: Volunteer, gsoc2017, p2
>
> While creating loan product, Enable 'Place guarantee funds on Hold'.
> There you will see three fileds:
> a) Mandatory Guarantee
> b) Minimum Guarantee from Own Funds
> c) Minimum Guarantee from Guarantor funds.
> a should be equal to b+c.
> If a=b then 'c' can be blank.
> If a=c  then 'b' can be blank.
> If not, the loan product should not allow to be created and should throw 
> proper error: "Mandatory Guarantee should be equal to sum of own fund and 
> guarantor fund OR any one of them".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FINERACT-693) Missing Descriptions for some Configurations

[Vishwas Babu A J (JIRA)]

[ 
https://issues.apache.org/jira/browse/FINERACT-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16788735#comment-16788735
 ] 

Vishwas Babu A J commented on FINERACT-693:
---

[~trush] : Please feel to work on any issue you want. Also, it might be a good 
idea to address your queries to our mailing lists as not all committers are 
subscribed to Jira alerts

> Missing Descriptions for some Configurations
> 
>
> Key: FINERACT-693
> URL: https://issues.apache.org/jira/browse/FINERACT-693
> Project: Apache Fineract
>  Issue Type: Bug
>  Components: System
>Affects Versions: 1.3.0
>Reporter: Chirag Gupta
>Priority: Major
>  Labels: GSOC, Volunteer
> Fix For: 1.4.0
>
>
> There are some descriptions missing for some global configurations.
> [Here|https://mifosforge.jira.com/wiki/spaces/docs/pages/67895362/Global+Configuration]
>  you can find all the descriptions listed for all of the global 
> configurations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FINERACT-718) Fix failure with rejectShareAccount Test case

[Vishwas Babu A J (JIRA)]

[ 
https://issues.apache.org/jira/browse/FINERACT-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16787953#comment-16787953
 ] 

Vishwas Babu A J commented on FINERACT-718:
---

[~SilviaChinwendu] : Sure, please feel free to assign it to yourself!

> Fix failure with rejectShareAccount Test case
> -
>
> Key: FINERACT-718
> URL: https://issues.apache.org/jira/browse/FINERACT-718
> Project: Apache Fineract
>  Issue Type: Sub-task
>Reporter: Vishwas Babu A J
>Priority: Major
>
> Test case fails with below error
>  
> {code:java}
> org.junit.ComparisonFailure: expected:<5[2].0> but was:<5[0].0>
> at org.junit.Assert.assertEquals(Assert.java:115)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at 
> org.apache.fineract.integrationtests.common.shares.ShareAccountIntegrationTests.rejectShareAccount(ShareAccountIntegrationTests.java:270)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FINERACT-729) Handle exception in downloading bulk import tool

[Vishwas Babu A J (JIRA)]

Vishwas Babu A J created FINERACT-729:
-

 Summary: Handle exception in downloading bulk import tool 
 Key: FINERACT-729
 URL: https://issues.apache.org/jira/browse/FINERACT-729
 Project: Apache Fineract
  Issue Type: Bug
Affects Versions: 1.2.0
Reporter: Vishwas Babu A J
 Fix For: 1.3.0


[LoanRepaymentWorkbookPopulator.java|https://github.com/apache/fineract/pull/472/files#diff-415f5ca056159a584caaea69aa11024b]
 tries to parse a String value (Loan Account Number) as Long



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FINERACT-728) Update Integration test case and API docs for changes made to Fineract-698

[Vishwas Babu A J (JIRA)]

Vishwas Babu A J created FINERACT-728:
-

 Summary: Update Integration test case and API docs for changes 
made to Fineract-698
 Key: FINERACT-728
 URL: https://issues.apache.org/jira/browse/FINERACT-728
 Project: Apache Fineract
  Issue Type: Sub-task
Reporter: Vishwas Babu A J


The code changes required are in place at 
[https://github.com/apache/fineract/pull/515].

The same needs to be tested with an integration test and details of this change 
needs to be updated in the API-docs

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FINERACT-713) Improve code-coverage to at-least 50% and reduce execution time

[Vishwas Babu A J (JIRA)]

[ 
https://issues.apache.org/jira/browse/FINERACT-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786332#comment-16786332
 ] 

Vishwas Babu A J commented on FINERACT-713:
---

[~anushkashukla] sure ! maybe you can get started with 
https://issues.apache.org/jira/browse/FINERACT-725 . Let us know what help you 
need. The best way to reach all developers working on Fineract would be on 
https://lists.apache.org/list.html?d...@fineract.apache.org

> Improve code-coverage to at-least 50% and reduce execution time
> ---
>
> Key: FINERACT-713
> URL: https://issues.apache.org/jira/browse/FINERACT-713
> Project: Apache Fineract
>  Issue Type: Improvement
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> While Fineract has integration tests, they currently cover very limited 
> scenarios and code coverage is very low.
> Enable gradle plugins to report the current code coverage and add new 
> Integration tests to ensure that code coverage, esp in critical packages like 
> loans, savings, and accounting is at-least 50%.
> Also, the existing tests are run sequentially and take around 23 minutes to 
> complete on [https://travis-ci.org/apache/fineract.] Along with improving 
> code coverage, we would also have to determine which tests can be run in 
> parallel and enable parallelization to ensure the total time taken is still 
> reasonable.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FINERACT-726) Changes to /authentication API's to pass data as part of request body

[Vishwas Babu A J (JIRA)]

[ 
https://issues.apache.org/jira/browse/FINERACT-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786329#comment-16786329
 ] 

Vishwas Babu A J commented on FINERACT-726:
---

sure [~Hashini] !

> Changes to /authentication API's to pass data as part of request body
> -
>
> Key: FINERACT-726
> URL: https://issues.apache.org/jira/browse/FINERACT-726
> Project: Apache Fineract
>  Issue Type: Improvement
>Affects Versions: 1.2.0
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc, p1, volunteer
> Fix For: 1.4.0
>
>
> Fineract supports authentication either using Basic auth or Oauth. The 
> initial authentication is done using the endpoints described at 
> [https://demo.openmf.org/api-docs/apiLive.htm#authentication_basicauth] and 
> [https://demo.openmf.org/api-docs/apiLive.htm#authentication_oauth] 
> Both rely on passing the username and password as URL query parameters.
> Ex, the endpoint for /authentication is 
> POST  : 
> [https://localhost:8443/fineract-provider/api/v1/authentication?username=mifos=password=default]
>  
> We would want to change the same to
> POST 
> [https://localhost:8443/fineract-provider/api/v1/authentication?tenantIdentifier=default]
> and pass the username and password as apart of the post body in json format.
> Ex:
> {code:java}
> {
> "username":"mifos",
> "password":"password"
> }{code}
>  
> After making this change, the APIdocs and integration test cases would have 
> to be updated accordingly 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-726) Changes to /authentication API's to pass data as part of request body

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-726:
--
Affects Version/s: 1.2.0

> Changes to /authentication API's to pass data as part of request body
> -
>
> Key: FINERACT-726
> URL: https://issues.apache.org/jira/browse/FINERACT-726
> Project: Apache Fineract
>  Issue Type: Improvement
>Affects Versions: 1.2.0
>Reporter: Vishwas Babu A J
>Priority: Major
>
> Fineract supports authentication either using Basic auth or Oauth. The 
> initial authentication is done using the endpoints described at 
> [https://demo.openmf.org/api-docs/apiLive.htm#authentication_basicauth] and 
> [https://demo.openmf.org/api-docs/apiLive.htm#authentication_oauth] 
> Both rely on passing the username and password as URL query parameters.
> Ex, the endpoint for /authentication is 
> POST  : 
> [https://localhost:8443/fineract-provider/api/v1/authentication?username=mifos=password=default]
>  
> We would want to change the same to
> POST 
> [https://localhost:8443/fineract-provider/api/v1/authentication?tenantIdentifier=default]
> and pass the username and password as apart of the post body in json format.
> Ex:
> {code:java}
> {
> "username":"mifos",
> "password":"password"
> }{code}
>  
> After making this change, the APIdocs and integration test cases would have 
> to be updated accordingly 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FINERACT-726) Changes to /authentication API's to pass data as part of request body

[Vishwas Babu A J (JIRA)]

[ 
https://issues.apache.org/jira/browse/FINERACT-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785175#comment-16785175
 ] 

Vishwas Babu A J commented on FINERACT-726:
---

Hint for GSOC students : Entry point at 
https://github.com/apache/fineract/blob/develop/fineract-provider/src/main/java/org/apache/fineract/infrastructure/security/api/AuthenticationApiResource.java#L80

> Changes to /authentication API's to pass data as part of request body
> -
>
> Key: FINERACT-726
> URL: https://issues.apache.org/jira/browse/FINERACT-726
> Project: Apache Fineract
>  Issue Type: Improvement
>Reporter: Vishwas Babu A J
>Priority: Major
>
> Fineract supports authentication either using Basic auth or Oauth. The 
> initial authentication is done using the endpoints described at 
> [https://demo.openmf.org/api-docs/apiLive.htm#authentication_basicauth] and 
> [https://demo.openmf.org/api-docs/apiLive.htm#authentication_oauth] 
> Both rely on passing the username and password as URL query parameters.
> Ex, the endpoint for /authentication is 
> POST  : 
> [https://localhost:8443/fineract-provider/api/v1/authentication?username=mifos=password=default]
>  
> We would want to change the same to
> POST 
> [https://localhost:8443/fineract-provider/api/v1/authentication?tenantIdentifier=default]
> and pass the username and password as apart of the post body in json format.
> Ex:
> {code:java}
> {
> "username":"mifos",
> "password":"password"
> }{code}
>  
> After making this change, the APIdocs and integration test cases would have 
> to be updated accordingly 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FINERACT-726) Changes to /authentication API's to pass data as part of request body

[Vishwas Babu A J (JIRA)]

Vishwas Babu A J created FINERACT-726:
-

 Summary: Changes to /authentication API's to pass data as part of 
request body
 Key: FINERACT-726
 URL: https://issues.apache.org/jira/browse/FINERACT-726
 Project: Apache Fineract
  Issue Type: Improvement
Reporter: Vishwas Babu A J


Fineract supports authentication either using Basic auth or Oauth. The initial 
authentication is done using the endpoints described at 
[https://demo.openmf.org/api-docs/apiLive.htm#authentication_basicauth] and 
[https://demo.openmf.org/api-docs/apiLive.htm#authentication_oauth] 

Both rely on passing the username and password as URL query parameters.

Ex, the endpoint for /authentication is 

POST  : 
[https://localhost:8443/fineract-provider/api/v1/authentication?username=mifos=password=default]

 

We would want to change the same to

POST 
[https://localhost:8443/fineract-provider/api/v1/authentication?tenantIdentifier=default]

and pass the username and password as apart of the post body in json format.

Ex:
{code:java}
{
"username":"mifos",
"password":"password"
}{code}
 

After making this change, the APIdocs and integration test cases would have to 
be updated accordingly 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (FINERACT-712) Fineract codebase should pass PMD, Findbugs and Checkstyle analysis

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J reassigned FINERACT-712:
-

Assignee: (was: Vishwas Babu A J)

> Fineract codebase should pass PMD, Findbugs and Checkstyle analysis
> ---
>
> Key: FINERACT-712
> URL: https://issues.apache.org/jira/browse/FINERACT-712
> Project: Apache Fineract
>  Issue Type: Improvement
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>   Original Estimate: 80h
>  Remaining Estimate: 80h
>
> The fineract codebase has findbugs (now spotbugs) and PMD gradle plugins, 
> however the same is not yet enabled. Enabling the same and fixing current 
> errors is crucial for the long term maintainability of the Fineract project.
> Another good to have would be checkstyle analysis.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FINERACT-725) Measure current code coverage

[Vishwas Babu A J (JIRA)]

Vishwas Babu A J created FINERACT-725:
-

 Summary: Measure current code coverage
 Key: FINERACT-725
 URL: https://issues.apache.org/jira/browse/FINERACT-725
 Project: Apache Fineract
  Issue Type: Sub-task
Reporter: Vishwas Babu A J


Integrate a plugin like 
[https://docs.gradle.org/current/userguide/jacoco_plugin.html] and generate the 
code coverage report for running integration tests on Fineract.

Using this report, we can quickly determine which package have low code 
coverage and work on remediating the same



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-712) Fineract codebase should pass PMD, Findbugs and Checkstyle analysis

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-712:
--
Description: 
The fineract codebase has findbugs (now spotbugs) and PMD gradle plugins, 
however, the ignoreFailures option is enabled on the gradle file. Disabling the 
same and fixing current errors is crucial for the long term maintainability of 
the Fineract project.

Another good to have would be checkstyle analysis.

  was:
The fineract codebase has findbugs (now spotbugs) and PMD gradle plugins, 
however the same is not yet enabled. Enabling the same and fixing current 
errors is crucial for the long term maintainability of the Fineract project.

Another good to have would be checkstyle analysis.


> Fineract codebase should pass PMD, Findbugs and Checkstyle analysis
> ---
>
> Key: FINERACT-712
> URL: https://issues.apache.org/jira/browse/FINERACT-712
> Project: Apache Fineract
>  Issue Type: Improvement
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>   Original Estimate: 80h
>  Remaining Estimate: 80h
>
> The fineract codebase has findbugs (now spotbugs) and PMD gradle plugins, 
> however, the ignoreFailures option is enabled on the gradle file. Disabling 
> the same and fixing current errors is crucial for the long term 
> maintainability of the Fineract project.
> Another good to have would be checkstyle analysis.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (FINERACT-712) Fineract codebase should pass PMD, Findbugs and Checkstyle analysis

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J reassigned FINERACT-712:
-

Assignee: Vishwas Babu A J

> Fineract codebase should pass PMD, Findbugs and Checkstyle analysis
> ---
>
> Key: FINERACT-712
> URL: https://issues.apache.org/jira/browse/FINERACT-712
> Project: Apache Fineract
>  Issue Type: Improvement
>Reporter: Vishwas Babu A J
>Assignee: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>   Original Estimate: 80h
>  Remaining Estimate: 80h
>
> The fineract codebase has findbugs (now spotbugs) and PMD gradle plugins, 
> however the same is not yet enabled. Enabling the same and fixing current 
> errors is crucial for the long term maintainability of the Fineract project.
> Another good to have would be checkstyle analysis.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-713) Improve code-coverage to at-least 50% and reduce execution time

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-713:
--
Issue Type: Improvement  (was: Task)

> Improve code-coverage to at-least 50% and reduce execution time
> ---
>
> Key: FINERACT-713
> URL: https://issues.apache.org/jira/browse/FINERACT-713
> Project: Apache Fineract
>  Issue Type: Improvement
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> While Fineract has integration tests, they currently cover very limited 
> scenarios and code coverage is very low.
> Enable gradle plugins to report the current code coverage and add new 
> Integration tests to ensure that code coverage, esp in critical packages like 
> loans, savings, and accounting is at-least 50%.
> Also, the existing tests are run sequentially and take around 23 minutes to 
> complete on [https://travis-ci.org/apache/fineract.] Along with improving 
> code coverage, we would also have to determine which tests can be run in 
> parallel and enable parallelization to ensure the total time taken is still 
> reasonable.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-713) Improve code-coverage to at-least 50% and reduce execution time

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-713:
--
Description: 
While Fineract has integration tests, they currently cover very limited 
scenarios and code coverage is very low.

Enable gradle plugins to report the current code coverage and add new 
Integration tests to ensure that code coverage, esp in critical packages like 
loans, savings, and accounting is at-least 50%.

Also, the existing tests are run sequentially and take around 23 minutes to 
complete on [https://travis-ci.org/apache/fineract.] Along with improving code 
coverage, we would also have to determine which tests can be run in parallel 
and enable parallelization to ensure the total time taken is still reasonable.

  was:
While Fineract has integration tests, they currently cover very limited 
scenarios and code coverage is very low.

Enable gradle plugins to track the current code coverage and add new 
Integration tests to ensure that code coverage, esp in critical packages like 
loans, savings, and accounting is at-least 50%


> Improve code-coverage to at-least 50% and reduce execution time
> ---
>
> Key: FINERACT-713
> URL: https://issues.apache.org/jira/browse/FINERACT-713
> Project: Apache Fineract
>  Issue Type: Task
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> While Fineract has integration tests, they currently cover very limited 
> scenarios and code coverage is very low.
> Enable gradle plugins to report the current code coverage and add new 
> Integration tests to ensure that code coverage, esp in critical packages like 
> loans, savings, and accounting is at-least 50%.
> Also, the existing tests are run sequentially and take around 23 minutes to 
> complete on [https://travis-ci.org/apache/fineract.] Along with improving 
> code coverage, we would also have to determine which tests can be run in 
> parallel and enable parallelization to ensure the total time taken is still 
> reasonable.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-713) Improve code-coverage to at-least 50% and reduce execution time

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-713:
--
Summary: Improve code-coverage to at-least 50% and reduce execution time  
(was: Improve code-coverage to at-least 50%)

> Improve code-coverage to at-least 50% and reduce execution time
> ---
>
> Key: FINERACT-713
> URL: https://issues.apache.org/jira/browse/FINERACT-713
> Project: Apache Fineract
>  Issue Type: Task
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> While Fineract has integration tests, they currently cover very limited 
> scenarios and code coverage is very low.
> Enable gradle plugins to track the current code coverage and add new 
> Integration tests to ensure that code coverage, esp in critical packages like 
> loans, savings, and accounting is at-least 50%



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-724) Upgrade Spring Boot, Spring and Spring Security to their latest stable version

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-724:
--
Description: 
Fineract uses versions of spring (including spring security) and spring boot 
which have approached their EOL and needs to be updated to the latest stable 
releases.

Spring -> 5.2.x (expected to be released before GSOC starts)

Spring boot -> 2.2.x (expected to be released before GSOC starts)

 

This upgrade would likely throw up a number of issues which would need to be 
addressed. Some sample issues would be
 * Deprecated methods which have now been removed. Ex: The codebases uses 
JdbcTemplate.queryForInt which would need to be replaced with queryForObject
 * The implementation of custom Filters like 
TenantAwareBasicAuthenticationFilter would need to change as overridden methods 
like doFilter in OncePerRequestFilter are final in recent Spring releases

 

 

  was:
Fineract uses versions of spring (including spring security) and spring boot 
which have approached their EOL and needs to be updated to the latest stable 
releases.

Spring -> 5.2.x (expected to be releases before GSOC starts)

Spring boot -> 2.2.x (expected to be releases before GSOC starts)

 

This upgrade would likely throw up a number of issues which would need to be 
addressed. Some sample issues would be
 * Deprecated methods which have now been removed. Ex: The codebases uses 
JdbcTemplate.queryForInt which would need to be replaced with queryForObject
 * The implementation of custom Filters like 
TenantAwareBasicAuthenticationFilter would need to change as overridden methods 
like doFilter in OncePerRequestFilter are final in recent Spring releases

 

 


> Upgrade Spring Boot, Spring and Spring Security to their latest stable version
> --
>
> Key: FINERACT-724
> URL: https://issues.apache.org/jira/browse/FINERACT-724
> Project: Apache Fineract
>  Issue Type: Improvement
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>
> Fineract uses versions of spring (including spring security) and spring boot 
> which have approached their EOL and needs to be updated to the latest stable 
> releases.
> Spring -> 5.2.x (expected to be released before GSOC starts)
> Spring boot -> 2.2.x (expected to be released before GSOC starts)
>  
> This upgrade would likely throw up a number of issues which would need to be 
> addressed. Some sample issues would be
>  * Deprecated methods which have now been removed. Ex: The codebases uses 
> JdbcTemplate.queryForInt which would need to be replaced with queryForObject
>  * The implementation of custom Filters like 
> TenantAwareBasicAuthenticationFilter would need to change as overridden 
> methods like doFilter in OncePerRequestFilter are final in recent Spring 
> releases
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FINERACT-724) Upgrade Spring Boot, Spring and Spring Security to their latest stable version

[Vishwas Babu A J (JIRA)]

Vishwas Babu A J created FINERACT-724:
-

 Summary: Upgrade Spring Boot, Spring and Spring Security to their 
latest stable version
 Key: FINERACT-724
 URL: https://issues.apache.org/jira/browse/FINERACT-724
 Project: Apache Fineract
  Issue Type: Improvement
Reporter: Vishwas Babu A J


Fineract uses versions of spring (including spring security) and spring boot 
which have approached their EOL and needs to be updated to the latest stable 
releases.

Spring -> 5.2.x (expected to be releases before GSOC starts)

Spring boot -> 2.2.x (expected to be releases before GSOC starts)

 

This upgrade would likely throw up a number of issues which would need to be 
addressed. Some sample issues would be
 * Deprecated methods which have now been removed. Ex: The codebases uses 
JdbcTemplate.queryForInt which would need to be replaced with queryForObject
 * The implementation of custom Filters like 
TenantAwareBasicAuthenticationFilter would need to change as overridden methods 
like doFilter in OncePerRequestFilter are final in recent Spring releases

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-723) Integration tests fail when the default tenant has a different time-zone than the system(s) running the application and database servers

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-723:
--
Description: 
Each tenant in Fineract has its timezone configured in the `tenants` table 
under the `fineractplatform-tenants` schema and the application should consider 
the same while carrying out any date/time related operations. This does not 
seem to be done consistently in the application and intermittent errors can be 
seen when the Application (tomcat) and database servers (MySQL) are run on 
systems with different timezones than that of the tenant.

Ex: Set the System timezone to "PDT". The default demo tenant is set to 
"Asia/Kolkata" and integration tests run on the same would fail intermittently.

Fixing the same would involve
 * Ensuring that all dates created in the API / service layers are done in a 
tenant sensitive fashion by utilizing the methods present in the class 
org.apache.fineract.infrastructure.core.service.DateUtils.
 * Ensure database operations do not use MySQL date functions. Ex:

{code:java}
@Override

    public Collection 
retrieveChargesWithAnnualFeeDue() {

        final String sql = "select " + this.chargeDueMapper.schema() + " where 
sac.charge_due_date is not null and sac.charge_time_enum = ? "

                + " and sac.charge_due_date <= NOW() and sa.status_enum = ? ";




        return this.jdbcTemplate.query(sql, this.chargeDueMapper, new Object[] 
{ChargeTimeType.ANNUAL_FEE.getValue(), 
SavingsAccountStatusType.ACTIVE.getValue()});

    }{code}
 in
org.apache.fineract.portfolio.savings.service.SavingsAccountChargeReadPlatformServiceImpl
 would cause issues with Timezones. We should be using something along the 
lines of
{code:java}
@Override
public Collection 
retrieveChargesWithAnnualFeeDue() {
String currentdate = formatter.print(DateUtils.getLocalDateOfTenant());
final String sql = "select " + this.chargeDueMapper.schema() + " where 
sac.charge_due_date is not null and sac.charge_time_enum = "
+ ChargeTimeType.ANNUAL_FEE.getValue() + " and sac.charge_due_date <= ? 
and sa.status_enum = "
+ SavingsAccountStatusType.ACTIVE.getValue();

return this.jdbcTemplate.query(sql, this.chargeDueMapper, new Object[] 
{currentdate});
}{code}
 

 

 

  was:
Each tenant in Fineract has its timezone configured in the `tenants` table 
under the `fineractplatform-tenants` schema and the application should consider 
the same while carrying out any date/time related operations. This does not 
seem to be done consistently in the application and intermittent errors can be 
seen when the Application (tomcat) and database servers (MySQL) are run on 
systems with different timezones than that of the tenant.

Ex: Set the System timezone to "PST". The default demo tenant is set to 
"Asia/Kolkata" and integration tests run on the same would fail intermittently.

Fixing the same would involve
 * Ensuring that all dates created in the API / service layers are done in a 
tenant sensitive fashion by utilizing the methods present in the class 
org.apache.fineract.infrastructure.core.service.DateUtils.
 * Ensure database operations do not use MySQL date functions. Ex:

{code:java}
@Override

    public Collection 
retrieveChargesWithAnnualFeeDue() {

        final String sql = "select " + this.chargeDueMapper.schema() + " where 
sac.charge_due_date is not null and sac.charge_time_enum = ? "

                + " and sac.charge_due_date <= NOW() and sa.status_enum = ? ";




        return this.jdbcTemplate.query(sql, this.chargeDueMapper, new Object[] 
{ChargeTimeType.ANNUAL_FEE.getValue(), 
SavingsAccountStatusType.ACTIVE.getValue()});

    }{code}
 in
org.apache.fineract.portfolio.savings.service.SavingsAccountChargeReadPlatformServiceImpl
 would cause issues with Timezones. We should be using something along the 
lines of
{code:java}
@Override
public Collection 
retrieveChargesWithAnnualFeeDue() {
String currentdate = formatter.print(DateUtils.getLocalDateOfTenant());
final String sql = "select " + this.chargeDueMapper.schema() + " where 
sac.charge_due_date is not null and sac.charge_time_enum = "
+ ChargeTimeType.ANNUAL_FEE.getValue() + " and sac.charge_due_date <= ? 
and sa.status_enum = "
+ SavingsAccountStatusType.ACTIVE.getValue();

return this.jdbcTemplate.query(sql, this.chargeDueMapper, new Object[] 
{currentdate});
}{code}

 

 

 


> Integration tests fail when the default tenant has a different time-zone than 
> the system(s) running the application and database servers
> 
>
> Key: FINERACT-723
> URL: https://issues.apache.org/jira/browse/FINERACT-723
> Project: 

[jira] [Updated] (FINERACT-723) Integration tests fail when the default tenant has a different time-zone than the system(s) running the application and database servers

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-723:
--
Description: 
Each tenant in Fineract has its timezone configured in the `tenants` table 
under the `fineractplatform-tenants` schema and the application should consider 
the same while carrying out any date/time related operations. This does not 
seem to be done consistently in the application and intermittent errors can be 
seen when the Application (tomcat) and database servers (MySQL) are run on 
systems with different timezones than that of the tenant.

Ex: Set the System timezone to "PDT". The default demo tenant is set to 
"Asia/Kolkata" and integration tests run on the same would fail intermittently.

Fixing the same would involve
 * Ensuring that all dates created in the API / service layers are done in a 
tenant sensitive fashion by utilizing the methods present in the class 
org.apache.fineract.infrastructure.core.service.DateUtils.
 * Ensure database operations do not use MySQL date functions. Ex:

{code:java}
@Override

    public Collection 
retrieveChargesWithAnnualFeeDue() {

        final String sql = "select " + this.chargeDueMapper.schema() + " where 
sac.charge_due_date is not null and sac.charge_time_enum = ? "

                + " and sac.charge_due_date <= NOW() and sa.status_enum = ? ";




        return this.jdbcTemplate.query(sql, this.chargeDueMapper, new Object[] 
{ChargeTimeType.ANNUAL_FEE.getValue(), 
SavingsAccountStatusType.ACTIVE.getValue()});

    }{code}
 in
org.apache.fineract.portfolio.savings.service.SavingsAccountChargeReadPlatformServiceImpl
 would cause issues with Timezones. We should be using something along the 
lines of
{code:java}
@Override
public Collection 
retrieveChargesWithAnnualFeeDue() {
String currentdate = formatter.print(DateUtils.getLocalDateOfTenant());
final String sql = "select " + this.chargeDueMapper.schema() + " where 
sac.charge_due_date is not null and sac.charge_time_enum = ? and 
sac.charge_due_date <= ? and sa.status_enum ? ";

return this.jdbcTemplate.query(sql, this.chargeDueMapper, new Object[] 
{currentdate, ChargeTimeType.ANNUAL_FEE.getValue(), 
SavingsAccountStatusType.ACTIVE.getValue()});
}{code}
 

 

 

  was:
Each tenant in Fineract has its timezone configured in the `tenants` table 
under the `fineractplatform-tenants` schema and the application should consider 
the same while carrying out any date/time related operations. This does not 
seem to be done consistently in the application and intermittent errors can be 
seen when the Application (tomcat) and database servers (MySQL) are run on 
systems with different timezones than that of the tenant.

Ex: Set the System timezone to "PDT". The default demo tenant is set to 
"Asia/Kolkata" and integration tests run on the same would fail intermittently.

Fixing the same would involve
 * Ensuring that all dates created in the API / service layers are done in a 
tenant sensitive fashion by utilizing the methods present in the class 
org.apache.fineract.infrastructure.core.service.DateUtils.
 * Ensure database operations do not use MySQL date functions. Ex:

{code:java}
@Override

    public Collection 
retrieveChargesWithAnnualFeeDue() {

        final String sql = "select " + this.chargeDueMapper.schema() + " where 
sac.charge_due_date is not null and sac.charge_time_enum = ? "

                + " and sac.charge_due_date <= NOW() and sa.status_enum = ? ";




        return this.jdbcTemplate.query(sql, this.chargeDueMapper, new Object[] 
{ChargeTimeType.ANNUAL_FEE.getValue(), 
SavingsAccountStatusType.ACTIVE.getValue()});

    }{code}
 in
org.apache.fineract.portfolio.savings.service.SavingsAccountChargeReadPlatformServiceImpl
 would cause issues with Timezones. We should be using something along the 
lines of
{code:java}
@Override
public Collection 
retrieveChargesWithAnnualFeeDue() {
String currentdate = formatter.print(DateUtils.getLocalDateOfTenant());
final String sql = "select " + this.chargeDueMapper.schema() + " where 
sac.charge_due_date is not null and sac.charge_time_enum = "
+ ChargeTimeType.ANNUAL_FEE.getValue() + " and sac.charge_due_date <= ? 
and sa.status_enum = "
+ SavingsAccountStatusType.ACTIVE.getValue();

return this.jdbcTemplate.query(sql, this.chargeDueMapper, new Object[] 
{currentdate});
}{code}
 

 

 


> Integration tests fail when the default tenant has a different time-zone than 
> the system(s) running the application and database servers
> 
>
> Key: FINERACT-723
> URL: https://issues.apache.org/jira/browse/FINERACT-723
> Project: Apache Fineract
>

[jira] [Updated] (FINERACT-723) Integration tests fail when the default tenant has a different time-zone than the system(s) running the application and database servers

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-723:
--
Labels: gsoc2019  (was: )

> Integration tests fail when the default tenant has a different time-zone than 
> the system(s) running the application and database servers
> 
>
> Key: FINERACT-723
> URL: https://issues.apache.org/jira/browse/FINERACT-723
> Project: Apache Fineract
>  Issue Type: Bug
>Affects Versions: 1.1.0, 1.2.0, 1.3.0
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>
> Each tenant in Fineract has its timezone configured in the `tenants` table 
> under the `fineractplatform-tenants` schema and the application should 
> consider the same while carrying out any date/time related operations. This 
> does not seem to be done consistently in the application and intermittent 
> errors can be seen when the Application (tomcat) and database servers (MySQL) 
> are run on systems with different timezones than that of the tenant.
> Ex: Set the System timezone to "PST". The default demo tenant is set to 
> "Asia/Kolkata" and integration tests run on the same would fail 
> intermittently.
> Fixing the same would involve
>  * Ensuring that all dates created in the API / service layers are done in a 
> tenant sensitive fashion by utilizing the methods present in the class 
> org.apache.fineract.infrastructure.core.service.DateUtils.
>  * Ensure database operations do not use MySQL date functions. Ex:
> {code:java}
> @Override
>     public Collection 
> retrieveChargesWithAnnualFeeDue() {
>         final String sql = "select " + this.chargeDueMapper.schema() + " 
> where sac.charge_due_date is not null and sac.charge_time_enum = ? "
>                 + " and sac.charge_due_date <= NOW() and sa.status_enum = ? ";
>         return this.jdbcTemplate.query(sql, this.chargeDueMapper, new 
> Object[] {ChargeTimeType.ANNUAL_FEE.getValue(), 
> SavingsAccountStatusType.ACTIVE.getValue()});
>     }{code}
>  in
> org.apache.fineract.portfolio.savings.service.SavingsAccountChargeReadPlatformServiceImpl
>  would cause issues with Timezones. We should be using something along the 
> lines of
> {code:java}
> @Override
>   public Collection 
> retrieveChargesWithAnnualFeeDue() {
>   String currentdate = formatter.print(DateUtils.getLocalDateOfTenant());
>   final String sql = "select " + this.chargeDueMapper.schema() + " where 
> sac.charge_due_date is not null and sac.charge_time_enum = "
>   + ChargeTimeType.ANNUAL_FEE.getValue() + " and sac.charge_due_date <= ? 
> and sa.status_enum = "
>   + SavingsAccountStatusType.ACTIVE.getValue();
>   
>   return this.jdbcTemplate.query(sql, this.chargeDueMapper, new Object[] 
> {currentdate});
>   }{code}
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FINERACT-723) Integration tests fail when the default tenant has a different time-zone than the system(s) running the application and database servers

[Vishwas Babu A J (JIRA)]

Vishwas Babu A J created FINERACT-723:
-

 Summary: Integration tests fail when the default tenant has a 
different time-zone than the system(s) running the application and database 
servers
 Key: FINERACT-723
 URL: https://issues.apache.org/jira/browse/FINERACT-723
 Project: Apache Fineract
  Issue Type: Bug
Reporter: Vishwas Babu A J


Each tenant in Fineract has its timezone configured in the `tenants` table 
under the `fineractplatform-tenants` schema and the application should consider 
the same while carrying out any date/time related operations. This does not 
seem to be done consistently in the application and intermittent errors can be 
seen when the Application (tomcat) and database servers (MySQL) are run on 
systems with different timezones than that of the tenant.

Ex: Set the System timezone to "PST". The default demo tenant is set to 
"Asia/Kolkata" and integration tests run on the same would fail intermittently.

Fixing the same would involve
 * Ensuring that all dates created in the API / service layers are done in a 
tenant sensitive fashion by utilizing the methods present in the class 
org.apache.fineract.infrastructure.core.service.DateUtils.
 * Ensure database operations do not use MySQL date functions. Ex:

{code:java}
@Override

    public Collection 
retrieveChargesWithAnnualFeeDue() {

        final String sql = "select " + this.chargeDueMapper.schema() + " where 
sac.charge_due_date is not null and sac.charge_time_enum = ? "

                + " and sac.charge_due_date <= NOW() and sa.status_enum = ? ";




        return this.jdbcTemplate.query(sql, this.chargeDueMapper, new Object[] 
{ChargeTimeType.ANNUAL_FEE.getValue(), 
SavingsAccountStatusType.ACTIVE.getValue()});

    }{code}
 in
org.apache.fineract.portfolio.savings.service.SavingsAccountChargeReadPlatformServiceImpl
 would cause issues with Timezones. We should be using something along the 
lines of
{code:java}
@Override
public Collection 
retrieveChargesWithAnnualFeeDue() {
String currentdate = formatter.print(DateUtils.getLocalDateOfTenant());
final String sql = "select " + this.chargeDueMapper.schema() + " where 
sac.charge_due_date is not null and sac.charge_time_enum = "
+ ChargeTimeType.ANNUAL_FEE.getValue() + " and sac.charge_due_date <= ? 
and sa.status_enum = "
+ SavingsAccountStatusType.ACTIVE.getValue();

return this.jdbcTemplate.query(sql, this.chargeDueMapper, new Object[] 
{currentdate});
}{code}

 

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-722) Integration test cases fail when run on the 1st of a month

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-722:
--
Summary: Integration test cases fail when run on the 1st of a month  (was: 
Some Integration test cases fail on the 1st of every month)

> Integration test cases fail when run on the 1st of a month
> --
>
> Key: FINERACT-722
> URL: https://issues.apache.org/jira/browse/FINERACT-722
> Project: Apache Fineract
>  Issue Type: Bug
>Affects Versions: 1.2.0, 1.3.0
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>
> Set the system clock of the machine on which the test cases are run to the 
> 1st of any month (say March 1st 2019). Now, running the test cases would 
> result in a few failures.
> The cause of each of these failures (likely issues with the test case 
> themselves, however, could also be application issues) needs to be analyzed 
> and fixed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-722) Some Integration test cases fail on the 1st of every month

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-722:
--
Description: 
Set the system clock of the machine on which the test cases are run to the 1st 
of any month (say March 1st 2019). Now, running the test cases would result in 
a few failures.

The cause of each of these failures (likely issues with the test case 
themselves, however, could also be application issues) needs to be analyzed and 
fixed.

> Some Integration test cases fail on the 1st of every month
> --
>
> Key: FINERACT-722
> URL: https://issues.apache.org/jira/browse/FINERACT-722
> Project: Apache Fineract
>  Issue Type: Bug
>Reporter: Vishwas Babu A J
>Priority: Major
>
> Set the system clock of the machine on which the test cases are run to the 
> 1st of any month (say March 1st 2019). Now, running the test cases would 
> result in a few failures.
> The cause of each of these failures (likely issues with the test case 
> themselves, however, could also be application issues) needs to be analyzed 
> and fixed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-722) Some Integration test cases fail on the 1st of every month

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-722:
--
Labels: gsoc2019  (was: )

> Some Integration test cases fail on the 1st of every month
> --
>
> Key: FINERACT-722
> URL: https://issues.apache.org/jira/browse/FINERACT-722
> Project: Apache Fineract
>  Issue Type: Bug
>Affects Versions: 1.2.0, 1.3.0
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>
> Set the system clock of the machine on which the test cases are run to the 
> 1st of any month (say March 1st 2019). Now, running the test cases would 
> result in a few failures.
> The cause of each of these failures (likely issues with the test case 
> themselves, however, could also be application issues) needs to be analyzed 
> and fixed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-722) Some Integration test cases fail on the 1st of every month

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-722:
--
Affects Version/s: 1.3.0
   1.2.0

> Some Integration test cases fail on the 1st of every month
> --
>
> Key: FINERACT-722
> URL: https://issues.apache.org/jira/browse/FINERACT-722
> Project: Apache Fineract
>  Issue Type: Bug
>Affects Versions: 1.2.0, 1.3.0
>Reporter: Vishwas Babu A J
>Priority: Major
>
> Set the system clock of the machine on which the test cases are run to the 
> 1st of any month (say March 1st 2019). Now, running the test cases would 
> result in a few failures.
> The cause of each of these failures (likely issues with the test case 
> themselves, however, could also be application issues) needs to be analyzed 
> and fixed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-722) Test cases failing on the 1st of every month

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-722:
--
Summary: Test cases failing on the 1st of every month  (was: Improve 
project stability)

> Test cases failing on the 1st of every month
> 
>
> Key: FINERACT-722
> URL: https://issues.apache.org/jira/browse/FINERACT-722
> Project: Apache Fineract
>  Issue Type: Improvement
>Reporter: Vishwas Babu A J
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-722) Some Integration test cases fail on the 1st of every month

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-722:
--
Summary: Some Integration test cases fail on the 1st of every month  (was: 
Test cases failing on the 1st of every month)

> Some Integration test cases fail on the 1st of every month
> --
>
> Key: FINERACT-722
> URL: https://issues.apache.org/jira/browse/FINERACT-722
> Project: Apache Fineract
>  Issue Type: Bug
>Reporter: Vishwas Babu A J
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (FINERACT-721) Improve project stability

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J closed FINERACT-721.
-
Resolution: Duplicate

> Improve project stability
> -
>
> Key: FINERACT-721
> URL: https://issues.apache.org/jira/browse/FINERACT-721
> Project: Apache Fineract
>  Issue Type: Improvement
>Reporter: Vishwas Babu A J
>Priority: Major
>
> A set of related tasks which when completed would allow the Fineract 
> community to ship new releases with more confidence



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FINERACT-722) Improve project stability

[Vishwas Babu A J (JIRA)]

Vishwas Babu A J created FINERACT-722:
-

 Summary: Improve project stability
 Key: FINERACT-722
 URL: https://issues.apache.org/jira/browse/FINERACT-722
 Project: Apache Fineract
  Issue Type: Improvement
Reporter: Vishwas Babu A J






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FINERACT-721) Improve project stability

[Vishwas Babu A J (JIRA)]

Vishwas Babu A J created FINERACT-721:
-

 Summary: Improve project stability
 Key: FINERACT-721
 URL: https://issues.apache.org/jira/browse/FINERACT-721
 Project: Apache Fineract
  Issue Type: Improvement
Reporter: Vishwas Babu A J


A set of related tasks which when completed would allow the Fineract community 
to ship new releases with more confidence



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FINERACT-720) Recurring Integration Test failures around Applying Annual Fees and Other Fee Types on Savings accounts

[Vishwas Babu A J (JIRA)]

Vishwas Babu A J created FINERACT-720:
-

 Summary: Recurring Integration Test failures around Applying 
Annual Fees and Other Fee Types on Savings accounts
 Key: FINERACT-720
 URL: https://issues.apache.org/jira/browse/FINERACT-720
 Project: Apache Fineract
  Issue Type: Sub-task
Reporter: Vishwas Babu A J


Fineract consists of two separate methods (and associated API's and batch jobs) 
for Applying Annual and Savings Charges 
inSavingsAccountWritePlatformServiceJpaRepositoryImpl, namely
 * applyAnnualFee : Applies any due annual Fee (only once) for an active 
savings account
 * applyChargeDue : Applies any due fee (including annual fee) till it is 
completely paid for a savings account

The crux of the cause of intermittent failure of test cases is as follows:

An annual charge is applied on a savings account for say the 1st of Jan 2015 
and then applyAnnualFee batch job is run on the same as on Feb 2th 2019. This 
results in the charge being paid as on 1st Jan 2015 and the next due date being 
set to 1st Jan 2016. This behavior is probably incorrect and I would presume 
that the charge would have to be paid for the years 2016, 2017,2018 and 2019 as 
well and the next due date should be set to 1st Jan 2020.

Next, when at any point in time, when the applyChargeDue test case is run, it 
recognizes the Annual fee charge due on 1st Jan 2016 and tries to repay the 
same as on today's date. However, existing validation in this method throws an 
exception.

Based on an initial observation, it looks like the following fixes would need 
to be made
 # Running applyAnnualFee should pay of *all* annual fees due on the account as 
of today's date
 # applyChargeDue should not try to pay annual fees

The change required for 1 has been made and it fixes the observed test case 
failure. The change of 2 has not been made for now, as I am not a 100% sure why 
the code is written in this way in the first place and in the absence of 
sufficient integration tests, do not want to possibly introduce any side 
effects.

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-719) Fix test cases around client, loan and savings Import

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-719:
--
Description: 
The following test cases are currently failing and have been Ignored for the 
time being as they are related to functionality which (I believe) is not widely 
used
 * ClientEntityImportHandlerTest.testClientImport
 * LoanImportHandlerTest. testLoanImport
 * SavingsImportHandlerTest. testSavingsImport

There is an open pull request at [https://github.com/apache/fineract/pull/444] 
which possible fixes some of these failing test. However, we are waiting for 
feedback on the same to be incorporated before it can be merged.

  was:
The following test cases are currently failing and have been Ignored for the 
time being as they are related to functionality which (I believe) is not widely 
used

LoanImportHandlerTest. testLoanImport
 SavingsImportHandlerTest. testSavingsImport

There is an open pull request at [https://github.com/apache/fineract/pull/444] 
which possible fixes some of these failing test. However, we are waiting for 
feedback on the same to be incorporated before it can be merged.


> Fix test cases around client, loan and savings Import
> -
>
> Key: FINERACT-719
> URL: https://issues.apache.org/jira/browse/FINERACT-719
> Project: Apache Fineract
>  Issue Type: Sub-task
>Affects Versions: 1.2.0, 1.3.0
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>
> The following test cases are currently failing and have been Ignored for the 
> time being as they are related to functionality which (I believe) is not 
> widely used
>  * ClientEntityImportHandlerTest.testClientImport
>  * LoanImportHandlerTest. testLoanImport
>  * SavingsImportHandlerTest. testSavingsImport
> There is an open pull request at 
> [https://github.com/apache/fineract/pull/444] which possible fixes some of 
> these failing test. However, we are waiting for feedback on the same to be 
> incorporated before it can be merged.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-719) Fix test cases around client, loan and savings Import

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-719:
--
Summary: Fix test cases around client, loan and savings Import  (was: Fix 
test cases around loan and savings Import)

> Fix test cases around client, loan and savings Import
> -
>
> Key: FINERACT-719
> URL: https://issues.apache.org/jira/browse/FINERACT-719
> Project: Apache Fineract
>  Issue Type: Sub-task
>Affects Versions: 1.2.0, 1.3.0
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>
> The following test cases are currently failing and have been Ignored for the 
> time being as they are related to functionality which (I believe) is not 
> widely used
> LoanImportHandlerTest. testLoanImport
>  SavingsImportHandlerTest. testSavingsImport
> There is an open pull request at 
> [https://github.com/apache/fineract/pull/444] which possible fixes some of 
> these failing test. However, we are waiting for feedback on the same to be 
> incorporated before it can be merged.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-719) Fix test cases around loan and savings Import

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-719:
--
Affects Version/s: 1.3.0
   1.2.0

> Fix test cases around loan and savings Import
> -
>
> Key: FINERACT-719
> URL: https://issues.apache.org/jira/browse/FINERACT-719
> Project: Apache Fineract
>  Issue Type: Sub-task
>Affects Versions: 1.2.0, 1.3.0
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>
> The following test cases are currently failing and have been Ignored for the 
> time being as they are related to functionality which (I believe) is not 
> widely used
> LoanImportHandlerTest. testLoanImport
>  SavingsImportHandlerTest. testSavingsImport
> There is an open pull request at 
> [https://github.com/apache/fineract/pull/444] which possible fixes some of 
> these failing test. However, we are waiting for feedback on the same to be 
> incorporated before it can be merged.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-719) Fix test cases around loan and savings Import

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-719:
--
Description: 
The following test cases are currently failing and have been Ignored for the 
time being as they are related to functionality which (I believe) is not widely 
used

LoanImportHandlerTest. testLoanImport
 SavingsImportHandlerTest. testSavingsImport

There is an open pull request at [https://github.com/apache/fineract/pull/444] 
which possible fixes some of these failing test. However, we are waiting for 
feedback on the same to be incorporated before it can be merged.

  was:
The following test cases are currently failing and have been Ignored for the 
time being as they are related to functionality which (I believe) is not widely 
used

LoanImportHandlerTest. testLoanImport
SavingsImportHandlerTest. testSavingsImport

There is an open pull request at [https://github.com/apache/fineract/pull/444] 
which possible fixes some of these failing test. However, we are waiting for 
feedback on the same to be incorporated before it can be merged

 


> Fix test cases around loan and savings Import
> -
>
> Key: FINERACT-719
> URL: https://issues.apache.org/jira/browse/FINERACT-719
> Project: Apache Fineract
>  Issue Type: Sub-task
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>
> The following test cases are currently failing and have been Ignored for the 
> time being as they are related to functionality which (I believe) is not 
> widely used
> LoanImportHandlerTest. testLoanImport
>  SavingsImportHandlerTest. testSavingsImport
> There is an open pull request at 
> [https://github.com/apache/fineract/pull/444] which possible fixes some of 
> these failing test. However, we are waiting for feedback on the same to be 
> incorporated before it can be merged.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FINERACT-719) Fix test cases around loan and savings Import

[Vishwas Babu A J (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FINERACT-719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vishwas Babu A J updated FINERACT-719:
--
Labels: gsoc2019  (was: )

> Fix test cases around loan and savings Import
> -
>
> Key: FINERACT-719
> URL: https://issues.apache.org/jira/browse/FINERACT-719
> Project: Apache Fineract
>  Issue Type: Sub-task
>Reporter: Vishwas Babu A J
>Priority: Major
>  Labels: gsoc2019
>
> The following test cases are currently failing and have been Ignored for the 
> time being as they are related to functionality which (I believe) is not 
> widely used
> LoanImportHandlerTest. testLoanImport
> SavingsImportHandlerTest. testSavingsImport
> There is an open pull request at 
> [https://github.com/apache/fineract/pull/444] which possible fixes some of 
> these failing test. However, we are waiting for feedback on the same to be 
> incorporated before it can be merged
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FINERACT-719) Fix test cases around loan and savings Import

[Vishwas Babu A J (JIRA)]

Vishwas Babu A J created FINERACT-719:
-

 Summary: Fix test cases around loan and savings Import
 Key: FINERACT-719
 URL: https://issues.apache.org/jira/browse/FINERACT-719
 Project: Apache Fineract
  Issue Type: Sub-task
Reporter: Vishwas Babu A J


The following test cases are currently failing and have been Ignored for the 
time being as they are related to functionality which (I believe) is not widely 
used

LoanImportHandlerTest. testLoanImport
SavingsImportHandlerTest. testSavingsImport

There is an open pull request at [https://github.com/apache/fineract/pull/444] 
which possible fixes some of these failing test. However, we are waiting for 
feedback on the same to be incorporated before it can be merged

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FINERACT-718) Fix failure with rejectShareAccount Test case

[Vishwas Babu A J (JIRA)]

[ 
https://issues.apache.org/jira/browse/FINERACT-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16782529#comment-16782529
 ] 

Vishwas Babu A J commented on FINERACT-718:
---

Am commenting out this test case as the underlying cause for failure is 
ambiguity around https://issues.apache.org/jira/browse/FINERACT-574 . The same 
should be re-enabled once https://issues.apache.org/jira/browse/FINERACT-574 is 
closed

> Fix failure with rejectShareAccount Test case
> -
>
> Key: FINERACT-718
> URL: https://issues.apache.org/jira/browse/FINERACT-718
> Project: Apache Fineract
>  Issue Type: Sub-task
>Reporter: Vishwas Babu A J
>Priority: Major
>
> Test case fails with below error
>  
> {code:java}
> org.junit.ComparisonFailure: expected:<5[2].0> but was:<5[0].0>
> at org.junit.Assert.assertEquals(Assert.java:115)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at 
> org.apache.fineract.integrationtests.common.shares.ShareAccountIntegrationTests.rejectShareAccount(ShareAccountIntegrationTests.java:270)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)