Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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


 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 to implement the document template generation module.


Project implementation plan


  1. User interface for report template generation.

          Mock UI : link

    • At this phase I will integrate 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).There are few options in choosing the editor, a simple jquery based editor like jHTMLArea, a more advanced JavaScript editor like ckeditor.
    • Writeclient side rules using jquery ,to dynamically  render the dynamic components of the template designing UI.

     2. Expose a set of context sensitive keywords. like ${clientName}, ${loanIdentifier} through the API, which users can add as placeholders in the 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 “clientName","address","age","joiningdate" 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.

    1. 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).
    2. 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..
    1. 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…

    1. 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


    • I hope to work on the “periodic  background search” explained in the project implementation plan(3).
    • I hope to solve some issues listed in MIFOSX jira.
  • No labels