Because of regulatory reasons or to do background check of a client (risk management), MFIs depend on credit bureaus. As part of it, MFI must submit client details to credit bureau and also need to pull client information from credit bureau before approving any new loans to a client.Mifos X can be integrated with a popular CBs in India and from other regions (based on the demand).

This will be an optional module inside Mifos X, and this module can be turned on/off based on the institutes requirements. And will be flexible to configure with different CBs (may not be practical to integrate with all CBs).

The major functionality will be sending the data to CBs on regular intervals in the format CB expects. And option to pull the client’s information from CB whenever loan officer/branch manager/ user wants to view the information for a particular client.Microfinance institutions usually work with various external parties, such as funders or investors. Using the data that is available in MifosX we would like to offer those stakeholders a seperate portal showing accurate and high-level information about the institution that would otherwise be reported manually by the institution. This information helps them in their decision making processes, but also enables them to assess the broader impact they are having with their funding.

To develop a portal that aggregates information from different Mifos X deployments and report on predefined social and operational metrics

Objectives:

• Implement back-end logic in MifosX required to make information available to the client impact portal
• Implement UI and back-end logic of the Client impact portal

The credit report shows account information such as repayment record, defaults, type of loan, amount of loan, etc. of the customer. This information facilitates prudent decision-making when the credit underwriter processes the loan application. This help MFI to reduce the risk of bad loans and reduces the multiple lendings to same person from different MFIs.

1. Build a module that extends loan product definition to include specific physical product ordering - e.g. a clean energy loan associated with a specific solar product. Create a daily batch process to send data in JSON or XML to appropriate third party system (e.g. MEC Tracker). Extend this to include "down payments" on the product purchase - i.e. only partially financed.
2. Build a supplier ordering/invoice & financial reconciliation process and transfer funds directly to "Supplier Account" upon fulfillment of order.
3. Create reports on aging of orders, fulfillment timing, and geographic spread.

Data Analytics & Client Insight - Are we making an impact? (Client Impact Portal demo)

Client Impact Portal POC - (mifos/password are login credentials)

Because of regulatory reasons or to do background check of a client (risk management), MFIs depend on credit bureaus. As part of it, MFI must submit client details to credit bureau and also need to pull client information from credit bureau before approving any new loans to a client.Mifos X can be integrated with a popular CBs in India and from other regions (based on the demand).

This will be an optional module inside Mifos X, and this module can be turned on/off based on the institutes requirements. And will be flexible to configure with different CBs (may not be practical to integrate with all CBs).

The major functionality will be sending the data to CBs on regular intervals in the format CB expects. And option to pull the client’s information from CB whenever loan officer/branch manager/ user wants to view the information for a particular client.

The credit report shows account information such as repayment record, defaults, type of loan, amount of loan, etc. of the customer. This information facilitates prudent decision-making when the credit underwriter processes the loan application. This help MFI to reduce the risk of bad loans and reduces the multiple lendings to same person from different MFIs.

1. Create a pre-paid account mechanism as an account type or account option in Mifos (perhaps extending existing classes), zero fees.
2. Create a new API for consuming pre-paid account balances.  
3. Create a simple external model that mimics consumption by a household on a daily basis - imagined as a set of data received from solar panel (watts used, time of day, volts present).  
4. Load up pre-paid account by account transfer in P2P interface (my phone to your account) or via trusted agent - i.e. trusted agent receives cash and loads account on Mifos.

1. Build a module that extends loan product definition to include specific physical product ordering - e.g. a clean energy loan associated with a specific solar product. Create a daily batch process to send data in JSON or XML to appropriate third party system (e.g. MEC Tracker). Extend this to include "down payments" on the product purchase - i.e. only partially financed.
2. Build a supplier ordering/invoice & financial reconciliation process and transfer funds directly to "Supplier Account" upon fulfillment of order.
3. Create reports on aging of orders, fulfillment timing, and geographic spread.

Providers of pay-as-you-go solar can use MIFOS for their operations. MFIs can become such providers.MFIs become more capable of integrating with third party systems for management of deliveries, after-sales service, and carbon tracking.

A business rule system enables these financial institutes policies and other operational decisions to be defined, tested, executed. Rule engines typically support rules, facts, priority (score), mutual exclusion, preconditions, and other functions.

This module will enable MFI admin to add, remove or modify the business rule against pre-defined work flows in the application.

As financial institutes, the business process of the institute is governed by local regulatory, and internal rules and rules defined by other other stake holders. And MIS should have provision to define these rules in the application to achive the objectives of these rules defined by various stake holders.

Example: Insurance company does not provider insurance to any person above 65 age. In that case in the MIS if users tries to attach a insurance feed to a client's loan account whos age is more than 65 years then "business rule engine" should prevent that action with appropriate message.

1. Create a pre-paid account mechanism as an account type or account option in Mifos (perhaps extending existing classes), zero fees.
2. Create a new API for consuming pre-paid account balances.  
3. Create a simple external model that mimics consumption by a household on a daily basis - imagined as a set of data received from solar panel (watts used, time of day, volts present).  
4. Load up pre-paid account by account transfer in P2P interface (my phone to your account) or via trusted agent - i.e. trusted agent receives cash and loads account on Mifos.

Providers of pay-as-you-go solar can use MIFOS for their operations. MFIs can become such providers.

At present MIfos X platform is shipped with Community-App (SPA) as default UI, but initial load time of the application high. And for users on narrow bandwidth internet it takes a considerable amount of time to load the app.

Instead of loading the app every time, we can convert the Community-App into a Chrome App and user can download them once and install it ion the machine, and it can used as thick client.

Community-App is completely developed on top of JavaScript, CSS and HTML. And Chrome apps are also written in same stack. Using grunt we should be able to repackage Community-App(SPA) into Community-App(Chrome App)

Users with slow internet connectivity can use this app (Installed on the machine) instead of loading Community-App (SPA) on the browser. Users will also have a continually updated app. This will also allow MFIs to potentially use Chromebooks as field-based devices for their branches.

Right now Mifos X contains core client management functionalities including tracking basic demographic information, know your customer information, document management, and survey collection through data tables. As financial institutions serving the poor begin to offer a more in-depth and diverse range of financial inclusion products, the need for more robust client management and in-depth client understanding has grows. Their core system needs to provide more and more CRM-type functionality that complement the portfolio management and financial/social reporting the Mifos X provides.

This project will work to deliver the initial set of customer relationship management functionalities including a module for tracking inquiries, complaints

This module will have a request management functionality. A request can be of 2 types: Complaints and Service Requests. Each request must be against a customer and optionally against an account of the customer. Each request will go through a simple workflow.

Actions that can be performed on a request:

Assign -> will change status to "assigned"

Start Work --> will change status to "in progress"

Close --> will change status to "closed" (with a sub-reason code)

At each step user can enter comments.

The customer summary screen will have a link to view the requests of the customer - along with a summary and current status - with option to click-through to get the complete history of each request.

Deepening the client relationship and ensuring fair, responsible, and transparent financial services to the poor is a core piece of the industry's roadmap for financial inclusion. Providing customers the ability to voice their concerns and feedback about the services they're receiving provides a simple yet powerful tool to protect the client. Empowering the financial institution with the ability to track these inquiries and overall maintain a more holistic relationship tracking entire lifecycle of their clients gives them a much better ability to understand their clients and respond to their needs with appropriately designed services and products.

We believe the Mifos X platform is super secure and impenetrable. Your mission, should you choose to accept it, is to prove us wrong, and help close gaps you may find.

Beyond a one time exercise, you should integrate (some of) the tools you've used into our build chain so that, even after you've gone, tools flag up future newly introduced potential vulnerabilities.

A business rule system enables these financial institutes policies and other operational decisions to be defined, tested, executed. Rule engines typically support rules, facts, priority (score), mutual exclusion, preconditions, and other functions.

This module will enable MFI admin to add, remove or modify the business rule against pre-defined work flows in the application.

As financial institutes, the business process of the institute is governed by local regulatory, and internal rules and rules defined by other other stake holders. And MIS should have provision to define these rules in the application to achive the objectives of these rules defined by various stake holders.

Example: Insurance company does not provider insurance to any person above 65 age. In that case in the MIS if users tries to attach a insurance feed to a client's loan account whos age is more than 65 years then "business rule engine" should prevent that action with appropriate message.

At present MIfos X platform is shipped with Community-App (SPA) as default UI, but initial load time of the application high. And for users on narrow bandwidth internet it takes a considerable amount of time to load the app.

Instead of loading the app every time, we can convert the Community-App into a Chrome App and user can download them once and install it ion the machine, and it can used as thick client.

Community-App is completely developed on top of JavaScript, CSS and HTML. And Chrome apps are also written in same stack. Using grunt we should be able to repackage Community-App(SPA) into Community-App(Chrome App)

Users with slow internet connectivity can use this app (Installed on the machine) instead of loading Community-App (SPA) on the browser. Users will also have a continually updated app. This will also allow MFIs to potentially use Chromebooks as field-based devices for their branches.

Right now Mifos X contains core client management functionalities including tracking basic demographic information, know your customer information, document management, and survey collection through data tables. As financial institutions serving the poor begin to offer a more in-depth and diverse range of financial inclusion products, the need for more robust client management and in-depth client understanding has grows. Their core system needs to provide more and more CRM-type functionality that complement the portfolio management and financial/social reporting the Mifos X provides.

This project will work to deliver the initial set of customer relationship management functionalities including a module for tracking inquiries, complaints

This module will have a request management functionality. A request can be of 2 types: Complaints and Service Requests. Each request must be against a customer and optionally against an account of the customer. Each request will go through a simple workflow.

Actions that can be performed on a request:

Assign -> will change status to "assigned"

Start Work --> will change status to "in progress"

Close --> will change status to "closed" (with a sub-reason code)

At each step user can enter comments.

The customer summary screen will have a link to view the requests of the customer - along with a summary and current status - with option to click-through to get the complete history of each request.

Deepening the client relationship and ensuring fair, responsible, and transparent financial services to the poor is a core piece of the industry's roadmap for financial inclusion. Providing customers the ability to voice their concerns and feedback about the services they're receiving provides a simple yet powerful tool to protect the client. Empowering the financial institution with the ability to track these inquiries and overall maintain a more holistic relationship tracking entire lifecycle of their clients gives them a much better ability to understand their clients and respond to their needs with appropriately designed services and products.

We believe the Mifos X platform is super secure and impenetrable. Your mission, should you choose to accept it, is to prove us wrong, and help close gaps you may find.

Beyond a one time exercise, you should integrate (some of) the tools you've used into our build chain so that, even after you've gone, tools flag up future newly introduced potential vulnerabilities.

https://www.owasp.org/index.php/Main_Page

https://code.google.com/p/zaproxy/

http://wapiti.sourceforge.net

Run FindBugs & related tools for some serious static code analysis

http://en.wikipedia.org/wiki/Penetration_test

MIfos X platform is shipped with a Community-App (SPA) as the default UI which is optimized for Web Browser display on large screens (Mobile, Laptops and Tablets). We need to extend the same to support mobile views (with minor changes to workflow) and provide offline functionality

Community-App is completely developed on top of JavaScript, CSS and HTML. Also since there is a clear separation between the view and the Controllers in Angular JS, we should be able to spin up mobile views fairly easily reusing the same Controllers and Services. As it is quite common for Mobile users to have intermittent data connection, we should also support offline functionality,

Field officers can access MifosX from a Mobile optimized view, capture data offline that can be synced back to the server when an internet connection is available.

It also becomes easier for the community volunteers to maintain the mobile view ( as we reuse most of the code from the Community app) as opposed to maintaining a separate Android app.

Other Resources

This project would seek to create one unified ID/login and profile for community members similar to the OpenMRS ID. It would achieve the following two primary objectives:

1. One unified profile and identity for community members in which they can share with the community who they are and also build reputation and recognition. This ability to discover and self-identify with other community members is difficult when we have so many different tools and profiles to maintain.
2. Single Sign On for our various collaboration and community infrastructure tools listed below.

1. Identifying a single sign-on authentication protocol that ties together authentication of our various community collaboration tools: 1) Atlassian Studio - JIRA, Confluence, JIRA Agile, 2) Social Q&A - AnswerHub 3) Mailing Lists - Mailman (administered through SourceForge 4) Source Code Version Control - GitHub 5) Continuous Integration - Jenkins 6) General Community Website (mifos.org) - Wordpress 7) Partner Directory
   1. This could be built out independently, tie into some OpenID protocol, or leverage one of our existing tools for this authentication - Atlassian Studio/Crowd or AnswerHub or another common OpenID protocol. 
2. Design and implement a dashboard to handle the creation of this unified ID
3. Design and create a common profile tied to this ID with basic information and photos that is searchable by the community.

Design a profile

Extra Credit:

• Gamification/Reputation Building - Tie into Open Badge system like Mozilla Open Badges http://openbadges.org/ or Ushahidi Badges: http://ushahidi.github.io/Badges/

Impact is two-fold:

• Common unified profile and identity can help to grow collaboration and participation in the community. By being able to simply share who you are or discover who's in your community, we can deepen the bonds of community which motivates each member to participate more often and invest personally in the health of the community. Building reputation and recognizing efforts of each type of community member (users, partners, volunteers, etc) in a tangible way also helps to increase participation.
• Single sign-on will it make much easier for community members to collaborate and communicate. Right now there is often a high barrier to signing up for the various tools - SSO will make that process easier but also encourage others to more regularly be involved.

Initial version of Mifos X was not designed to be database agnostic. Goal of this project is to make it so, and test this out in practice by running it locally on Oracle, make sure our test suite runs against Oracle as well as mysql, and well documenting how this can be set up by end-user clients, if they wish to go for this deployment.

To make this possible, all business logic has to be concentrated in the middle tier with the database being as dumb as possible. This means the platform does not rely on any database specific stored procedures or on the database to generate unique keys. And also application heavily use prepared statements (Spring jdbctemplate) for retrieving data and need to make sure all these queries use full JOIN syntax, and bracket the JOINs so that each join is between a single table and bracketed expression.

MFI with large client base can use the application with Oracle or any other commercial databases.

Mifos has abstraction from underlying database using:

• Hibernate as ORM (must have good experience with Hibernate)
• Liquibase as Database refactoring tool
• DbUnit as test dataset maintenance

Primary objective of this project is to build a standalone installer for MifosX platform. Standalone installer is a great way to evaluate and explore MifosX platform quickly. We want:

• Possibility of Mifos self-contained demo package
• Simple / easy launch of integration/acceptance testing, without requiring an external DB
• Development without manual MySQL installation

Standalone installer will consist of an embeded apache server and a DB. It should also ship with the latest mifosx build war file which should automatically deployed
on to the embedded server at the installation time.

1. Develop the installer as an executable jar format so that it will support many platforms with JRE.
2. Provides a simplified installation option with an embedded data base and a server.
3. Develop GUI and command line base installation modes.

GUI MODE OPTIONS
================

Tomcat Port This is the port at which to run tomcat.
MySQL Port This is the port at which to run mysql
File > Quit This menu item stops tomcat and mysql and then closes the application.
File > Launch Browser This menu item opens the MifosX login page for the current web application context.
File > Clear Output This clears the output log in a user interface text area. But does not clear the log file which will written on the file system.
Start This button runs tomcat, which will automatically start the mysql database engine if it was not already running. For the embedded mysql, the first connection automatically starts the mysql engine.
Stop This button stops tomcat and then also stops the mysql database engine, without closing the application.

COMMAND LINE OPTIONS
====================

-mysqlport Use to override the mysql port in the runtime properties file.
-tomcatport Use to override the tomcat port in the runtime properties file.
-start Use to start the server.
-stop Use to stop the server.
-browser Use to launch a new browser instance.

This sub-project would port / apply our MIFOS-5157 Installer-free simple launcher from classic Mifos to Mifos X, and then look at how to extend such a package to run without any existing external database as planned in MIFOS-4926 (which MIFOS-5157 doesn't cover). The first thought that comes to mind is to achieve this with a pure-Java in-memory database such as H2 or Derby. However, in order to avoid maintaining & supporting 2 different databases for Mifos, we'd like to base this on https://github.com/vorburger/MariaDB4j. While we are at it, we should also replace the classic GPL mysql driver by the LGPL MariaDB Client Library.

For many microfinance institutions who lack technical skills, installing Mifos X is a burden that prevents them from using this software to more efficiently serve the poor. Often they get lost in the installation process when having to separately install java, their web server, MySQL, and then deploy Mifos. A self-contained package acting as a simple one-step installer for Mifos would help make the software more accessible to more organizations and allow for MFI to more easily test the software and see the immense value it provides.

https://wiki.openmrs.org/display/docs/OpenMRS+Standalone
https://github.com/openmrs/openmrs-standalone
https://github.com/openmrs/openmrs-standalone/tree/master/src/main/config

See Linux Installers wiki page

Mifos X today is typically used on Tomcat (with Jetty known to work). For a certain class of users, testing it on "Enterprise Stack" application servers (meaning IBM WebSphere and Oracle WebLogic) is desirable - this project would properly test Mifos X on these configurations, make any adaptations to the code which may be required, and produce easy to follow documentation or even small tools helping future users how to go about this.

This project could be combined with and taken up by the same candidate as the Enterprise database project.

Java, Application Server configuration, WAS classloading crap tricks, documentation writing.

Use Cargo, Arquillian etc. for automated testing against WAS & WLS containers?

Vendor pages

The Mifos X platform as of today is a well structure but monolithic code base - one Git repo, one build, one WAR. This has worked out well for us, but as we grow, it could be interesting to introduce a proper SDK and plug-in concept, allowing contributors to build individual JARs that can be dropped into a certain directory of Mifos X to augment the core platform on well defined extension points and hooks. These modules would be loaded at run-time, not require rebuilding Mifos X, and would remain compatible when a customer upgrades their core platform version.

We currently see the SDK as something more relevant to the Java back-end, so in this project you would likely work less on our AngularJS UI (barring some configuration UI for the plug-ins probably); but if you do have any ideas how to make the front-end more modular and extensible as well, we would love to hear from you.

This project will have three axis/phases: 1. platform infrastructure framework kind of work, based on a very simple or fictitious example extension; 2. identifying the functionally which could require / be sensible to extend in Mifos X, extracting clear and documented Java APIs from it, and then make changes to existing functional platform services to make them extensible by plug-ins; 3. well document this - such plugins will only be written if it's easy and clear how to do this. Note that the more technical part 1. should only take about 1/4 of your project, the focus will have to be putting the "theory" from 1. into "practice" in phases 2. & 3.

Many other Java-based platform have such mechanism, and you would be expected to draw at least conceptual, if not outright technical inspiration (re-using code, if feasible) from things like the Eclipse Plug-In architecture (or similar non-OSGi based ones in other IDEs), research if Spring itself or some extension from someone has anything useful for this (think like Guice Multibindings plus ServiceLoader API as discussed on this StackOverflow, or this blog, or these Mycila Guice Extensions; but without going all the way to OSGi-based Spring DM / Dynamic Modules; again, overkill, here), get inspiration from drop-in add-on modules extension capabilities in enterprise software such as e.g. Atlassian plug-in framework, and learn how e.g. our friends at OpenMRS do this (see OpenMRS SDK doc and OpenMRS project).

To allow field-based staff to manage their daily schedules and to ensure that their supervisors are able to review these tasks and to plan field operations and bring in more efficiency and transparency for field operations

Field officers typically have a predefined set of tasks to follow, for example: Do survey for a locality, Conduct Group Trainings, Conduct Group Tests, Do Center Meetings and Collections. Each could have a task code to make operations streamlined.

Field officers manage their calendars by selecting an activity and specifying a center, date and time for which this activity is planned. This becomes their planned activity for this slot.

A simple workflow to manage each slot – when field officer starts the activity, status of the slot is changed from “new” to “open” and when the activity is completed, it is set to “closed”. It would be ideal to manage this workflow using a mobile tool – preferably an inbound SMS message. For example: an SMS from the field officer’s phone with the text “OPEN 1430” will change the status to “OPEN” of the field officer’s activity that was planned for 2:30pm.

Field officer may change his plan up to a certain time prior to the start of the activity.

Auditors and branch managers will review the activities and track the field officers’ planning and efficiency.

To run any business successfully, you need the insight of the business and that is possible when you have information system in which you can get the information in the format your business analysis team needs. And in current world business are very much market adaptive and market scenarios changes very rapidly. To cope up with that  good MIS need to have Ad-hoc report builder.

Easy-to-use, drag-and-drop report designer builds crosstabs, tables, and chart-based reports using a standard browser.

The ad hoc reporting will be based on a logical mapping of Mifos data elements to business entities (like customer, loan account, savings account, loan transactions, savings transactions etc.) and business attributes (like loan approved date, loan amount, loan outstanding amount etc.). An end user will be able to configure and generate reports based on these business entities and business attributes.

Reporting fields and reporting criteria will support basic derived fields like "days overdue", "amount overdue", "customer total outstanding amount", "customer total relationship value" etc.

The reporting will support basic functions like summing up totals, sorting based on different fields and grouping based on different fields.

For better usability system needs to have notifications to the logged in user about actions he/she needs to perform in the application.

Build real time notification system in application to notify to users about pending/new actions she/he needs to take. Example if branch manager login to the application and 3 new loans are created and pending for approval then system should notify him/her about the pending actions.

This involves both invoking and triggering these notifications based on these actions or activities as well as the extension of the user interface to support the display of the notifications as well as the ability of the user to take action upon the notifications.

Develop ETL scripts to create OLAP cubes (fact and dimension tables in MySQL). This will allow managers to perform ad hoc slicing and dicing of their data 
to answer important questions about their operations.

• Create ETL scripts and tests
• Create a Mondrian schema to work with Saiku Analytics

Microfinance institutions usually work with various external parties, such as funders or investors. Using the data that is available in MifosX we would like to offer those stakeholders a seperate portal showing accurate and high-level information about the institution that would otherwise be reported manually by the institution. This information helps them in their decision making processes, but also enables them to assess the broader impact they are having with their funding.

To develop a portal that aggregates information from different Mifos X deployments and report on predefined social and operational metrics

Objectives:

• Implement back-end logic in MifosX required to make information available to the client impact portal
• Implement UI and back-end logic of the Client impact portal

To run any business successfully, you need the insight of the business and that is possible when you have information system in which you can get the information in the format your business analysis team needs. And in current world business are very much market adaptive and market scenarios changes very rapidly. To cope up with that  good MIS need to have Ad-hoc report builder.

Easy-to-use, drag-and-drop report designer builds crosstabs, tables, and chart-based reports using a standard browser.

The ad hoc reporting will be based on a logical mapping of Mifos data elements to business entities (like customer, loan account, savings account, loan transactions, savings transactions etc.) and business attributes (like loan approved date, loan amount, loan outstanding amount etc.). An end user will be able to configure and generate reports based on these business entities and business attributes.

Reporting fields and reporting criteria will support basic derived fields like "days overdue", "amount overdue", "customer total outstanding amount", "customer total relationship value" etc.

The reporting will support basic functions like summing up totals, sorting based on different fields and grouping based on different fields.

For better usability system needs to have notifications to the logged in user about actions he/she needs to perform in the application.

Build real time notification system in application to notify to users about pending/new actions she/he needs to take. Example if branch manager login to the application and 3 new loans are created and pending for approval then system should notify him/her about the pending actions.

This involves both invoking and triggering these notifications based on these actions or activities as well as the extension of the user interface to support the display of the notifications as well as the ability of the user to take action upon the notifications.

Adding the ability to batch requests similar to the one at https://developers.facebook.com/docs/graph-api/making-multiple-requests/ would greatly improve the performance and ease of consumption of MifosX Api's in apps that require bulk processing, syncing of offline data etc

Some of the simplest use cases would involve

a) Disbursing Multiple JLG loans in a center on a given meeting day

b) A flexible collection sheet, where we could query for all loans that have a scheduled repayment on a particular day, update the actual repayments and post the data back to the platform

c) Batch operations like approving multiple checker requests at a time

Abstract

Batching allows you to pass instructions for several operations in a single HTTP request.

The Batch API takes in an array of logical HTTP requests represented as JSON arrays - each request has a requestId (the id of a request used to specify the sequence and as a dependency between requests), a method (corresponding to HTTP method GET/PUT/POST/DELETE etc.), a relativeUrl (the portion of the URL after https://DomainName/api/v1), optional headers array (corresponding to HTTP headers) and an optional body (for POST and PUT requests).

The Batch API returns an array of logical HTTP responses represented as JSON arrays - each response has a requestId, a status code, an optional headers array and an optional body (which is a JSON encoded string).

First Step & POC

The workflow of an agent acting in the field will be used as a POC.

For the first step we should focus on the following use stories:

• As an agent I want to create a new client for an existing office.

• As an agent I want to update client specific information for an existing office.

• As an agent I want to apply a loan to an existing client.

• As an agent I want to apply a savings to an existing client.

• As an agent I want to collect client charges for a loan.

It should be feasible to implement all this by using existing commands. This solution will include dependency resolution, e.g. adding a new client and apply a new loan.

Definition

POST https://DomainName/api/v1

[
  {
    "requestId" : 1,
    "method" : "POST",
    "relativeUrl" : "clients",
    "body" : "{ \"officeId\": 1, \"firstname\": \"John\", \"lastname\": \"Smith\", ... }"
  },
  { "requestId" : 2,
    "method" : "POST",
    "relativeUrl" : "loans",
    "body" : "{ \"clientId\" : \"$.clientId\", \"productId\" : 1, ...}"
  },
  {
    "requestId" : 3,
    "method" : "POST",
    "relativeUrl" : "clients",
    "body" : "{ \"officeId\": 1, \"fullname\": \"Pocahontas\", ... }"
  },
  {
    "requestId" : 4,
    "method" : "POST",
    "relativeUrl" : "savingsaccount",
    "body" : "{ \"clientId\" : \"$.clientId\", \"productId\" : 1, ...}"
  }
]

[
  {
    "requestId" : 1,
    "statusCode" : 201,
    "headers" : [
      {
        "name" : "Content-Type",
        "value" : "application/json; charset=UTF-8"
      }
    ], 
    "body" : "{ \"officeId\": 1, \"clientId\": 1, ...}"
  },
  {
    "requestId" : 2,
    "statusCode" : 201,
    "headers" : [
      {
        "name" : "Content-Type",
        "value" : "application/json; charset=UTF-8"
      }
    ],
    "body" : "{ \"officeId\": 1, \"clientId\": 1, \"loanId\": 1, ...}"
  },
  {
    "requestId" : 3,
    "statusCode" : 201,
    "headers" : [
      {
        "name" : "Content-Type",
        "value" : "application/json; charset=UTF-8"
      }
    ],
    "body" : "{ \"officeId\": 1, \"clientId\": 2, ...}"
  },
  {
    "requestId" : 4,
    "statusCode" : 201,
    "headers" : [
      {
        "name" : "Content-Type",
        "value" : "application/json; charset=UTF-8"
      }
    ],
    "body" : "{ \"officeId\": 1, \"clientId\": 2, \"savingsId\": 1, ...}"
  }
]

Develop ETL scripts to create OLAP cubes (fact and dimension tables in MySQL). This will allow managers to perform ad hoc slicing and dicing of their data 
to answer important questions about their operations.

• Create ETL scripts and tests
• Create a Mondrian schema to work with Saiku Analytics

This project would seek to create one unified ID/login and profile for community members similar to the OpenMRS ID. It would achieve the following two primary objectives:

1. One unified profile and identity for community members in which they can share with the community who they are and also build reputation and recognition. This ability to discover and self-identify with other community members is difficult when we have so many different tools and profiles to maintain.
2. Single Sign On for our various collaboration and community infrastructure tools listed below.

1. Identifying a single sign-on authentication protocol that ties together authentication of our various community collaboration tools: 1) Atlassian Studio - JIRA, Confluence, JIRA Agile, 2) Social Q&A - AnswerHub 3) Mailing Lists - Mailman (administered through SourceForge 4) Source Code Version Control - GitHub 5) Continuous Integration - Jenkins 6) General Community Website (mifos.org) - Wordpress 7) Partner Directory
   1. This could be built out independently, tie into some OpenID protocol, or leverage one of our existing tools for this authentication - Atlassian Studio/Crowd or AnswerHub or another common OpenID protocol. 
2. Design and implement a dashboard to handle the creation of this unified ID
3. Design and create a common profile tied to this ID with basic information and photos that is searchable by the community.

Design a profile

Extra Credit:

• Gamification/Reputation Building - Tie into Open Badge system like Mozilla Open Badges http://openbadges.org/ or Ushahidi Badges: http://ushahidi.github.io/Badges/

Impact is two-fold:

• Common unified profile and identity can help to grow collaboration and participation in the community. By being able to simply share who you are or discover who's in your community, we can deepen the bonds of community which motivates each member to participate more often and invest personally in the health of the community. Building reputation and recognizing efforts of each type of community member (users, partners, volunteers, etc) in a tangible way also helps to increase participation.
• Single sign-on will it make much easier for community members to collaborate and communicate. Right now there is often a high barrier to signing up for the various tools - SSO will make that process easier but also encourage others to more regularly be involved.

Initial version of Mifos X was not designed to be database agnostic. Goal of this project is to make it so, and test this out in practice by running it locally on Oracle, make sure our test suite runs against Oracle as well as mysql, and well documenting how this can be set up by end-user clients, if they wish to go for this deployment.

To make this possible, all business logic has to be concentrated in the middle tier with the database being as dumb as possible. This means the platform does not rely on any database specific stored procedures or on the database to generate unique keys. And also application heavily use prepared statements (Spring jdbctemplate) for retrieving data and need to make sure all these queries use full JOIN syntax, and bracket the JOINs so that each join is between a single table and bracketed expression.

MFI with large client base can use the application with Oracle or any other commercial databases.

Mifos has abstraction from underlying database using:

• Hibernate as ORM (must have good experience with Hibernate)
• Liquibase as Database refactoring tool
• DbUnit as test dataset maintenance

Primary objective of this project is to build a standalone installer for MifosX platform. Standalone installer is a great way to evaluate and explore MifosX platform quickly. We want:

• Possibility of Mifos self-contained demo package
• Simple / easy launch of integration/acceptance testing, without requiring an external DB
• Development without manual MySQL installation

Standalone installer will consist of an embeded apache server and a DB. It should also ship with the latest mifosx build war file which should automatically deployed
on to the embedded server at the installation time.

1. Develop the installer as an executable jar format so that it will support many platforms with JRE.
2. Provides a simplified installation option with an embedded data base and a server.
3. Develop GUI and command line base installation modes.

GUI MODE OPTIONS
================

Tomcat Port This is the port at which to run tomcat.
MySQL Port This is the port at which to run mysql
File > Quit This menu item stops tomcat and mysql and then closes the application.
File > Launch Browser This menu item opens the MifosX login page for the current web application context.
File > Clear Output This clears the output log in a user interface text area. But does not clear the log file which will written on the file system.
Start This button runs tomcat, which will automatically start the mysql database engine if it was not already running. For the embedded mysql, the first connection automatically starts the mysql engine.
Stop This button stops tomcat and then also stops the mysql database engine, without closing the application.

COMMAND LINE OPTIONS
====================

-mysqlport Use to override the mysql port in the runtime properties file.
-tomcatport Use to override the tomcat port in the runtime properties file.
-start Use to start the server.
-stop Use to stop the server.
-browser Use to launch a new browser instance.

This sub-project would port / apply our MIFOS-5157 Installer-free simple launcher from classic Mifos to Mifos X, and then look at how to extend such a package to run without any existing external database as planned in MIFOS-4926 (which MIFOS-5157 doesn't cover). The first thought that comes to mind is to achieve this with a pure-Java in-memory database such as H2 or Derby. However, in order to avoid maintaining & supporting 2 different databases for Mifos, we'd like to base this on https://github.com/vorburger/MariaDB4j. While we are at it, we should also replace the classic GPL mysql driver by the LGPL MariaDB Client Library.

For many microfinance institutions who lack technical skills, installing Mifos X is a burden that prevents them from using this software to more efficiently serve the poor. Often they get lost in the installation process when having to separately install java, their web server, MySQL, and then deploy Mifos. A self-contained package acting as a simple one-step installer for Mifos would help make the software more accessible to more organizations and allow for MFI to more easily test the software and see the immense value it provides.

https://wiki.openmrs.org/display/docs/OpenMRS+Standalone
https://github.com/openmrs/openmrs-standalone
https://github.com/openmrs/openmrs-standalone/tree/master/src/main/config

See Linux Installers wiki page

Mifos X today is typically used on Tomcat (with Jetty known to work). For a certain class of users, testing it on "Enterprise Stack" application servers (meaning IBM WebSphere and Oracle WebLogic) is desirable - this project would properly test Mifos X on these configurations, make any adaptations to the code which may be required, and produce easy to follow documentation or even small tools helping future users how to go about this.

This project could be combined with and taken up by the same candidate as the Enterprise database project.

Java, Application Server configuration, WAS classloading crap tricks, documentation writing.

Use Cargo, Arquillian etc. for automated testing against WAS & WLS containers?

Vendor pages

The Mifos X platform as of today is a well structure but monolithic code base - one Git repo, one build, one WAR. This has worked out well for us, but as we grow, it could be interesting to introduce a proper SDK and plug-in concept, allowing contributors to build individual JARs that can be dropped into a certain directory of Mifos X to augment the core platform on well defined extension points and hooks. These modules would be loaded at run-time, not require rebuilding Mifos X, and would remain compatible when a customer upgrades their core platform version.

We currently see the SDK as something more relevant to the Java back-end, so in this project you would likely work less on our AngularJS UI (barring some configuration UI for the plug-ins probably); but if you do have any ideas how to make the front-end more modular and extensible as well, we would love to hear from you.

This project will have three axis/phases: 1. platform infrastructure framework kind of work, based on a very simple or fictitious example extension; 2. identifying the functionally which could require / be sensible to extend in Mifos X, extracting clear and documented Java APIs from it, and then make changes to existing functional platform services to make them extensible by plug-ins; 3. well document this - such plugins will only be written if it's easy and clear how to do this. Note that the more technical part 1. should only take about 1/4 of your project, the focus will have to be putting the "theory" from 1. into "practice" in phases 2. & 3.

Many other Java-based platform have such mechanism, and you would be expected to draw at least conceptual, if not outright technical inspiration (re-using code, if feasible) from things like the Eclipse Plug-In architecture (or similar non-OSGi based ones in other IDEs), research if Spring itself or some extension from someone has anything useful for this (think like Guice Multibindings plus ServiceLoader API as discussed on this StackOverflow, or this blog, or these Mycila Guice Extensions; but without going all the way to OSGi-based Spring DM / Dynamic Modules; again, overkill, here), get inspiration from drop-in add-on modules extension capabilities in enterprise software such as e.g. Atlassian plug-in framework, and learn how e.g. our friends at OpenMRS do this (see OpenMRS SDK doc and OpenMRS project).

To allow field-based staff to manage their daily schedules and to ensure that their supervisors are able to review these tasks and to plan field operations and bring in more efficiency and transparency for field operations. To meet the requirement, Android based app need to be developed to cover these uses cases. And this app will be an extension to MIfos X mobile client.

Field officers typically have a predefined set of tasks to follow, for example: Do survey for a locality, Conduct Group Trainings, Conduct Group Tests, Do Center Meetings and Collections. Each could have a task code to make operations streamlined.

Field officers manage their calendars by selecting an activity and specifying a center, date and time for which this activity is planned. This becomes their planned activity for this slot.

A simple workflow to manage each slot – when field officer starts the activity, status of the slot is changed from “new” to “open” and when the activity is completed, it is set to “closed”. It would be ideal to manage this workflow using a mobile tool – preferably an inbound SMS message. For example: an SMS from the field officer’s phone with the text “OPEN 1430” will change the status to “OPEN” of the field officer’s activity that was planned for 2:30pm.

Field officer may change his plan up to a certain time prior to the start of the activity.

Auditors and branch managers will review the activities and track the field officers’ planning and efficiency.