...

• 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

...

Minimise Impact on

...

Existing API

We see the Maker-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 Maker-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 Maker-Check flow, new 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.

Example

...

Usage

The following describe one possible example usage of Maker-Checker for one particular operation: CREATE_CLIENT

...

drop table `m_maker_checker`;
CREATE TABLE `m_maker_checker` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `task_name` varchar(100) NOT NULL,
  `task_json` text NOT NULL,
  `maker_id` bigint(20) NOT NULL,
  `made_on_date` datetime NOT NULL,
  `checker_id` bigint(20) DEFAULT NULL,
  `checked_on_date` datetime DEFAULT NULL,
(John W: probably need to have fields for name and id of related entity e.g. 'Loan', 7666 so the master data and proposed changes can be joined)
  PRIMARY KEY (`id`),
  KEY `FK_m_maker_m_appuser` (`maker_id`),
  KEY `FK_m_checker_m_appuser` (`checker_id`),
  CONSTRAINT `FK_m_maker_m_appuser` FOREIGN KEY (`maker_id`) REFERENCES `m_appuser` (`id`),
  CONSTRAINT `FK_m_checker_m_appuser` FOREIGN KEY (`checker_id`) REFERENCES `m_appuser` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=utf8;

...