Thanks Ed, turns out it was my fault - didn't notice I wasn't logged in... I've opened an issue and a pull request with a fix to the import.
Thanks for your help Markus. With the current fix teller would still log warnings every time a loan is repaid. Perhaps it would be a good idea to also change ChargeDefinitionRestController in portfolio so that it returns all charge definitions and not just the configurable ones. (Or maybe add an endpoint so there's a distinction in the api between configurable and non configurable?) On Mon, Jun 15, 2020 at 8:20 PM Ed Cable <[email protected]> wrote: > Markus, > > Thanks for your help to Michael. > > Michael - by default the permissions for > https://jira.apache.org/jira/projects/FINCN should allow anyone with a > jira ID to create issues. I just confirmed that by looking at our > permission schemes but don't have control over individual-level > permissions. > > If it's a blocker, I can create the issue and then assign to you. Let me > forward to the apache infra team and see if they can troubleshoot. What is > your user ID? > > Thanks, > > Ed > > On Mon, Jun 15, 2020 at 3:39 AM Michael Elgavi <[email protected]> > wrote: > >> I'd like to send a pull request with a fix for the wrong import. To do >> this I assume an issue has to be created, but I don't seem to have the >> permissions to open issues on the JIRA. >> >> On Sun, Jun 14, 2020 at 9:12 AM Markus Geiß <[email protected]> wrote: >> >>> Hey Michael, >>> >>> the reason why Teller is trying to fetch the definition of charges is >>> because it adds this information to the screen showing all parts of a >>> transaction including cost. >>> >>> Using the exception from office seems to be the real issue, so fixing it >>> by using the correct one is the right choice. >>> >>> IMHO >>> >>> Cheers >>> >>> Markus >>> >>> Gesendet von Outlook Mobile <https://aka.ms/blhgte> >>> >>> ------------------------------ >>> *From:* Ed Cable <[email protected]> >>> *Sent:* Sunday, June 14, 2020 2:37:41 AM >>> *To:* Dev <[email protected]>; Robert Elles < >>> [email protected]>; Craig S. Chelius <[email protected]>; >>> Victor Manuel Romero Rodriguez <[email protected]>; Jose >>> Hernandez <[email protected]> >>> *Subject:* Re: Fineract-CN Repay Loan Fails >>> >>> Michael, >>> >>> Glad to see your continued active presence in the community. Happy to >>> see how deep you're digging into the Fineract CN code and your willingness >>> to contribute back pull requests to the community. >>> >>> I'm cc'ing @Robert Elles <[email protected]> and @Craig S. Chelius >>> <[email protected]> from Kuelap as they should have experience >>> using the teller module in production. >>> >>> @Victor Manuel Romero Rodriguez <[email protected]> and @Jose >>> Hernandez <[email protected]> have you interacted with >>> repaying loans via teller? >>> >>> Thanks, >>> >>> Ed >>> ---------- Forwarded message --------- >>> From: *Michael Elgavi* <[email protected]> >>> Date: Sat, Jun 13, 2020 at 3:35 PM >>> Subject: Fineract-CN Repay Loan Fails >>> To: <[email protected]> >>> >>> >>> Hi all. >>> >>> We've been testing out Fineract-CN for a while now and encountered an >>> issue when trying to repay a loan from a teller (using fims). >>> >>> Tracking down the source of the problem, I've found the following line >>> in portfolio's log: >>> Responding with a service error ServiceError{code=404, message='No >>> charge definition with the identifier repay-principal found.'} >>> >>> Taking a look at teller and portfolio code, the problem seems to be as >>> follows: >>> 1. Teller calls portfolioManager.getCostComponentsForAction(), which >>> returns cost components as expected. >>> 2. Teller then calls portfolio again for every cost component and >>> confirms the charge definition identifier referenced is real by calling >>> portfolioManager.getChargeDefinition(). (This was introduced in this >>> commit >>> <https://github.com/apache/fineract-cn-teller/commit/815b7db174e7e8207ed06e562991c682b391ef77>, >>> and really doesn't make much sense to me. If teller doesn't trust >>> getCostComponents then why is it trusting getChargeDefinition?) >>> 3. Portfolio returns 404 when asked for the `repay-principal` charge >>> definition. This is because since this commit >>> <https://github.com/apache/fineract-cn-portfolio/commit/8568aa0938faab9ff5d6b74c1823863b0ce8781a>, >>> ChargeDefinitionRestController no longer deals with all charge definitions, >>> but only charges that are configurable. (The only configurable definitions >>> for loans are the fees. Other microservices currently have no way of >>> accessing the read-only non configurable charge definitions.) >>> 4. Teller is supposed to catch this 404 and handle it gracefully by catching >>> the NotFoundException >>> <https://github.com/apache/fineract-cn-teller/blob/c7896d6fce218ddb1ca5a6f8c20a71c04834351e/service/src/main/java/org/apache/fineract/cn/teller/service/internal/service/helper/PortfolioService.java#L81> >>> and just logging a warning, but for some reason it's catching >>> org.apache.fineract.cn.office.api.v1.client.NotFoundException >>> <https://github.com/apache/fineract-cn-teller/blob/c7896d6fce218ddb1ca5a6f8c20a71c04834351e/service/src/main/java/org/apache/fineract/cn/teller/service/internal/service/helper/PortfolioService.java#L35> >>> instead of org.apache.fineract.cn.api.util.NotFoundException. >>> >>> So the way I see it there are multiple ways to resolve this: >>> 1. Have portfolio return non configurable charge definitions too. >>> 2. Remove teller's (seemingly pointless) checking of charge definitions. >>> 3. Fix the wrong exception being caught. >>> >>> I have tested solution 3 and was able to repay a loan successfully. TBH >>> the right solution is probably to do all of these, but technically any one >>> would do. >>> >>> Before submitting any pull requests, I'd like to know if my analysis of >>> the problem is correct. Has anyone else experienced this problem? Is our >>> installation misconfigured somehow? or is it just that nobody has actually >>> tried repaying a loan with the teller (is there a better way)? >>> >>> >>> -- >>> *Ed Cable* >>> President/CEO, Mifos Initiative >>> [email protected] | Skype: edcable | Mobile: +1.484.477.8649 >>> >>> *Collectively Creating a World of 3 Billion Maries | *http://mifos.org >>> <http://facebook.com/mifos> <http://www.twitter.com/mifos> >>> >>> > > -- > *Ed Cable* > President/CEO, Mifos Initiative > [email protected] | Skype: edcable | Mobile: +1.484.477.8649 > > *Collectively Creating a World of 3 Billion Maries | *http://mifos.org > <http://facebook.com/mifos> <http://www.twitter.com/mifos> > >
