...

Introduction

The ability to support makerMaker-checker Checker style processes in Mifos X has been requested and discussed through email by various community members and also at the Mifos Summit 2012. The This page is being used to share and communicate initial thoughts on how this will be approached from a design and implementation point of view.

...

A MAKER performs a maintenance function that has been designated as following the MAKER-CHECKER workflow. Instead of being immediately applied, the proposed changes are held in a queue (also known as an inbox). A CHECKER can pull the proposed changes from the inbox and then either
a) ACCEPT the changes (possibly after some edits)
b) REJECT the changes (possibly with some notes that allows and possibly the MAKER to can resubmit the changes later).

The makerMaker-checker Checker concept can be used for quality improvement (4 Eyes) or fraud prevention (superior signs-off) purposes.

The plan is to do a basic prototype which can be demo'd (sometime between 19th - 23rd Nov).  During the demo, the scope of the initial release can be discussed.

...

Assume that the "Create Client" task always uses the Maker-Checker Workflow but no other task uses it.

MAKER

Any application user with the permission to create a client.

...

A CHECKER can see a queue of any proposed changes that they didn't MAKE themselves. A CHECKER can select an item from their queue and see the proposed changes before accepting or rejecting them. 

FULL SCOPE (for discussion during demo)

...

Ability to globally enable and disable Maker-Checker functionality.
Ability to enable and disable Maker-Checker workflow for each non-read task.
... and then to add futher the possiblity of adding further optional rules to limit the CHECKER to a specific ROLE or other things including transaction amount limits.

...

Possibly any application user having their is_checker box ticked or it might be better to have a CHECKER permission or it might be enough to match any optional CHECKER rules set against the
task (e.g. if a loan can only be approved by a Credit Officer role then any user having that role can be a CHECKER for approving loans even if they aren't 'ticked' as one.
Data scoping is applied. CHECKER can only CHECK data they are allowed to see i.e. within their office hierarchy.
Some flows might require more than one CHECK.

...

A CHECKER can see any proposed changes that they didn't MAKE themselves than that they are allowed to CHECK. A CHECKER can select an item from their queue and see the proposed 
changes proposed changes before accepting or rejecting them. Notes may be attached to acceptance or rejection and the MAKER can see these.

...

• The workflow is managed using a maker-checker inbox (separate table) rather than by having statuses on the 'master' table.
• Mifos has some examples of the maker-check concept - creating Centres, Groups and Clients and also Loan Approval. These example would be covered by this more general Maker-Checker solution.
• The Mifos X api will probably be extended so that any proposed changes can be returned e.g. for 'Create Client' the UI would need the template data (defaults and allowed values) as per normal AND the proposed changes in JSON in order to show the details as typed by the MAKER. e.g. /clients?template=true&MakerCheckerId=787877
• It would be good to see other software that employs the maker-checker concept to help us understand more fully what those looking for this functionality expect from the approach.  Haven't seen one yet.

Other Notes

...

Not everyone wants to enforce a maker-checker and for those that do, it probably doesnt make sense to have 'maker-checker' enforced for every capabliity in the system that changes 'state'. As such:

• By default maker-checker will not be enabled
• Some configuration ability will be support to allow a system user to enable/disable maker-checker for any or all of the tasks supported by the platform.
• For indication of who has permission to be a 'maker' and a 'checker' for certain tasks; the intention is to add an extra option in which a role can be setup with defined set of permissions and this role in turn associated with users

Zero impact on existing API

We see makerthe Maker-checker Checker capability as a core and internal part of the Mifos X platform. As such it should not impact existing API structure and be pretty much invisible. For creation a client is still a POST to /clients with JSON as documented in https://ec2-46-137-62-163.eu-west-1.compute.amazonaws.com:8443/api-docs/apiLive.htm#clients_create. If makerMaker-checker Checker is enabled for this client creation task, they we expect the following to happen:

...

At present the existing API returns only the system id of the entity that has been created or updated. Through makerMaker-check Check flow, new entitys entities are not created yet so need to pass back system id for maker-checker entry and no id for new entity which client applications will have to handle.

Question 1:

If the task being maker-checker'ized is an update (e.g. update client name/dob/office) then it probably makes sense that when I view the client details on system, would I want to know that there are 'changes awaiting' on this client and possibly even see what they are?

Example usage

The following describe one possible example usage of makerMaker-checker Checker for one praticular particular operation: CREATE_CLIENT

• Data-entry user creates a new client through the user interface entering correct details and presses submit
• makerMaker-checker Checker is enabled for this operation so instead of a new client being added to the database, an entry is made in maker-checker table - the maker Maker information is populated at this point
• At this point, an An application user who has checker rights for CREATE_CLIENT needs to verify this entry before it can be persisted in database, reject it if not wanted or modify it if needed
  
  • REJECT: if the checker rejects the entry, what then? 
  • MODIFY: should there be a facility to allow the checker to modify the entry?
  • VERIFY: entry should attempt to be persisted in database (at this point there could still be problems with persisting it, data integrity rules etc)

...