fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aditya Hendre <>
Subject Re: GSoC (UPI Integration) progress
Date Tue, 24 May 2016 08:42:19 GMT

I have created a product requirements page for UPI[1] on MifosX wiki alongside other requirement
pages. Specific requirements, use cases should be added to the page. I have attached relevant
documentation. Suggestions could also be invited from users by announcing on user@fineract
mailing list.


> I request you to take some small bugs and fix it and test it and send the
> code back to community code base.

I have been sifting through Fineract JIRA issues but it is difficult to find right bugs to
work on; they seem either too easy or too involved, and also there is no introductory label
used on Fineract JIRA. For a newcomer it is difficult to say what knowledge is required to
fix a particular bug or to estimate the work required to fix it. Can someone suggest some
bugs which I could fix?

I have shortlisted some bugs which sound easy. Please suggest which ones I should fix.

* FINERACT-16 Cannot close Savings Account when linked to a loan even when loan status is
* FINERACT-46 Throw an exception if staff to be deactivated is attached to an entity with
status enum id not equal to 600
* FINERACT-42 display name for datatable
* FINERACT-36 User defined Templates do not work when Tomcat is behind a proxy
* FINERACT-80 Group loans not included in resultset returned by "LoanReadPlatformServiceImpl.retrieveAll"
* FINERACT-97 Add the "on_hold_funds_derived" property to the savings account summary data
* FINERACT-120 Hide inactive code values from "/datatable/<tableName>" output
* FINERACT-45 The "getRejectedByUser" method in the "LoanRescheduleRequest" entity class returns
the wrong value.
* FINERACT-44 Cannot delete an inactive charge
* FINERACT-51 Add the "is_reversed" property of the loan transaction entity to the "LoanTransactionData"
* FINERACT-52 Null value not handled in "ClientWritePlatformServiceJpaRepositoryImpl.CloseClient"
date comparison
* FINERACT-53 Make the "clientId" URL parameter optional for "loan details template" retrieval
* FINERACT-55 Standing instruction not disabled at loan/savings account closure
* FINERACT-71 "AuditReadPlatformServiceImpl.retrieveEntries" returns duplicate results for
users without the "ALL_FUNCTIONS" and "CHECKER_SUPER_USER" permissions.
* FINERACT-92 "Loan.validateActivityNotBefore ..." methods missing "LOAN_RECOVERY_PAYMENT"
switch case
* FINERACT-118 Standing instruction not disabled when you undo a loan disbursal

#44, #45 and few other 'minor improvements' seem trivial; why are they still languishing?
Should I make the suggested changes and send a pull request?

Newcomer-friendly bugs should be tagged as "introductory" in Fineract JIRA.

Aditya Hendre

On Friday 20 May 2016 05:17 PM, Nayan Ambali wrote:
> Aditya,
> Nice summary of how you have understood the platform code and architecture.
> <>
>>> or on Confluence wiki?
> First check that, is there wiki or requirements document put into JIRA, if
> not then i suggest to start with wiki for documentation of requirements and
> use cases, JIRA is basically for more of tracking the the feature
> developments as measurable goals or tasks and less of documenting
> functional specification.
> Please let us know where you are planning to documenting UPI related
> requirements so that others can also contribute.
> I request you to take some small bugs and fix it and test it and send the
> code back to community code base.
> Credit Bureau Integration is not related UPI but one can say similar in
> nature as third party integration with platform and no more similarity :)
> Thanks and Regards,
> Nayan Ambali
> +91 9591996042
> skype: nayangambali
> On Fri, May 20, 2016 at 3:00 AM, Aditya H <> wrote:
>> Hi all,
>> I have been doing a lot of mental gymnastics lately, trying to wrap my
>> brains around Fineract, stitching together a mental big picture by reading
>> the source, API doc, log output.
>> I have learned the basics of Gradle, and Spring Framework. Now I can
>> interpret the *.gradle build files which define the high-level logistics.
>> Dependency Injection/IoC, and Spring Framework with all its numerous
>> components was overwhelming at first, but after reading from Spring
>> Framework Reference[1] I feel quite comfortable. You provide the bean
>> definitions to the container and it creates those objects and manages their
>> life cycles for you. It took some time to understand the subtle differences
>> between @Configuration, @Component, @Service, @Repository, @Controller
>> annotations.
>> [1]
>> I have multiple approaches:
>> I start with reading and try to reason about the
>> control flow, reading about the Spring annotations that are encountered
>> along the way. The startup log output helps in this. ServerApplication
>> @imports DataSourceConfiguration (which uses @Autowired JDBCDriverConfig
>> instance) which sets up the network connection to the MySQL database.
>> ServerApplication also @imports EmbeddedTomcatWithSSLConfiguration which
>> sets up the embedded Tomcat ServletContainer instance.
>> AbstractApplicationConfiguration pulls in all the XML bean definitions. And
>> so on..
>> Another approach is to start with any ApiResource class, say
>> ClientsApiResource, and trace the execution which happens in response to
>> each of the supported requests.
>> Listing all the beans:
>> Pretty much all the classes annotated with @Component, @Service,
>> @Repository, and methods annotated with @Bean and definitions in
>> (resources/META-INF/spring/) XML files are objects managed by the Spring
>> context. They are all the ApiResource's, RepositoryWrapper's,
>> CommandHandler's, ServiceImpl's. They get instantiated according to their
>> inter-dependencies.
>> Spring Security is used for securing the API endpoints with (Oauth/Basic
>> auth) authentication.
>> Flyway updates the schemas of the databases by sequentially applying all
>> the SQL scripts in resources/sql/migrations. It was nice to find out such a
>> tool exists. This must eliminate lot of headache involved in reproducing
>> and debugging bugs connected with evolving database schemas. Each class
>> annotated with @Entity in the domain/ directories represents a table in the
>> relational database.
>> We should have a product requirement page for Unified Payment Interface,
>> where developers/users who already know UPI can add specific requirements.
>> Should the page be created at
>> or on Confluence wiki?
>> I was wondering whether Mobile Money Integration or Credit Bureau
>> Integration is a similar/related task to UPI integration.
>> Soon I'll begin working on the UPI Java SDK.
>> Regards,
>> Aditya

View raw message