About me
Link to my personal space : /wiki/spaces/~apremalal/overview
Project proposal
User generated documents module is a new feature which will added to the MifosX system which allow users with basic drag and drop skills and a knowledge of MifosX platform to easily generate custom well formatted report templates.
The key point about generating templates with this module is that the users only have to drag drop/click on context aware tags which will display in a floating tool box to create a custom report template and MifosX system will be capable of rendering the report when the created template applied to a certain entity.
Abstract
...
| Table of Contents |
|---|
Project Resources
Mentor | |
|---|---|
Assigned Contributor |
Project Overview
Overview
MFI’s typically generate client-facing documents (whose format varies from MFI to MFI) from their MIS. These documents are usually limited to the context of a Client (Client registration documents) and Loans (Loan Contracts, Passbooks etc.).
To overcome this limitation , I am proposing the following project plan plan to implement the document template generation module.
Project implementation plan
- User interface for report template generation.
Mock UI : link
...
.
Background and Business Need
One of the biggest challenges for non Technical users in Using Mifos (MifosX) would be in finding local specialists to help them in designing simple client facing reports and documents (like Loan Contracts etc).
Often, small organizations would not be able to afford the services of specialists and would have to do without any custom documents.
This project would enable non technical endusers to create these simple reports using context-sensitive placeholders and a WYSIWYG-Editor, thereby drastically increasing the usability of MifosX.
The actual functionality (wherein a user defines document templates in the system) could be reused for many other related tasks like SMS Integration (
| Jira Legacy | ||||
|---|---|---|---|---|
|
Project Details
A Brief overview of the desired functionality is as follows:
- A rich text editor on the Reference Client, which can be used by a user to create
...
- wysiwyg designs and upload them against various entities at different stages in their Life-cycle ( Ex: An "active" Client, A Loan "Pending disbursal" etc)
...
...
- Expose a set of context sensitive keywords
...
- like
...
- {{client.name}},
...
- {{loan.id}} through the API, which
...
- can
...
- be added as placeholders in
...
- these documents.
When a user choose a particular entity to create a template, the associated context place holders will be sent to the front-end through the REST API.
- Ex: An active Client could have a list of permissible keywords like
...
- "client.name","client.address","client.age","
...
- joining date" etc.
...
An active Loan could have a list of permissible keywords like "disbursalDate", "amount", "principalRepaid", "interestRepaid", "lastRepaymentDate", "lastRepaymentAmount"
...
Jquery UI element accordion will be used to display the tags in the front end form editor.
3. Periodic background saves.(If time permits)
This feature will periodically (every 15 or 30 sec) stores a "draft" of the html form that is being worked on in a "non-submitted" state. This would allow users who do not have permission to edit a submitted form to return to a form (in the instance that perhaps they accidentally close or navigate away from the page in the browser, the computer runs out of battery, etc).
This feature would allow users to not have to start over the form from scratch if a problem occurred. I would propose creating a separate table that contains a flag for signed forms vs. forms in progress. Signed forms would be considered submitted, but prior to "signing" forms would be stored every 15 to 30 sec as a form in progress. forms in progress would appear and could be edited within the encounter's page until they are signed and submitted.
4.Server side and Client side report validation + Client side parser.
- When a user wants to preview the template, firstly it will be validate against set of validation rules and upon successful completion parse the html and render a preview using the default values of the place holder, these default values will be sent to the front-end at the context initialization phase(when the context place holders are initialized).
- When the template applied to a particular entity, a validation layer will be implemented to inform the user with checked errors.
5.Server side parser: Some of the advantages of having the parser at the server side would be,
- Better performance
- We can carry out various optimizations like fetching values for only those placeholders which are present in the particular document etc..
- Implementation of server side parser for simple place holders.
i. Initially ,will deal with simple place holders ,that would be replaced by the Text value the placeholder represents.
Ex : ${clientName} would be replaced by “Andy Jones” etc…
- Implementation of the server side parser for complex place holders.
i. They would be used primarily for generating tabular data.
Ex: The placeholder ${repaymentSchedule('date','principalAmount','interestAmount') } would create a HTML table for repayments with the table columns based on the passed in parameters ‘date', 'principalAmount', 'interestAmount'
The Restful service for server side document generation would look similar to
/{entityName}/user.defined.report/{reportId}?entityId=10&parse=true
Where,
- {entityName} = Name of the entity (Client, Loan etc)
- {reportId} = The Identifier for the report template
- entityId = (Optional Query param) Identifier for compound Entities (Ex: The Loan Product Id for a Loan)
- parse= An Optional Query param, when present causes the server to replace placeholders with actual values. When not specified, the server would return the actual report Template (used for reading the actual template as a part of CRUD operations on "m_report_templates" table)
Once the web service received a request with the above details a spring MVC controller will direct it to the validation layer implemented in the 5th phase. Then the received html content will be parsed upon successful validation and will be sent to the front-end.
6. Write unit test cases.
Participation
I will be hanging around #mifos and mifos developer-mailing list, as those seem to be ideal places to ask for help, and learn from others. I expect to talk with my mentor quite regularly, and ask for advice when needed, as well as receive comments on code review. I expect to submit code as a branch and follow best practices as mentioned in the wiki pages.
Project time line
May 3rd – May 27th | Getting familiar with the needed technologies |
May 28th – June 16th | Knowing each other of the developer community , Discuss project design and plans with the mentor |
June 17th – July 28th | Implementation of task 1, 2 , [3*] |
July 29th – Aug 2nd | Mid Evaluations |
Aug 3rd – Sep 15th | Implementation of task 4, 5 |
Sep 16th – Sep 22nd | Further testing and improve documentation |
Sep 23rd – Sep 27th | Final evaluation |
If time permits
...
- Java parser at the Server side would intelligently replace these placeholders with appropriate content and generate HTML reports
(Would also need API's to be exposed from the platform) - The next step would be to add in advanced controls like loops etc so that we can generate content like pass books with all repayments within a specified period etc
Refer Draft Specs for User Generated Documents for an initial approach for developing this functionality
Project Status
Visit UGD_Planning
Additional Information
Draft Specs for User Generated Documents
MIFOSX-117 - User Defined documents (
Open)