Mailing-List: contact dev-help@fineract.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@fineract.incubator.apache.org
From: "Adi Raju" <adi.raju@confluxtechnologies.com>
To: <dev@fineract.incubator.apache.org>
References: <CAAPXgWvpTqNWOiRGg4FETY8K_uJkJtrddw6GJi1ZYdJ7KR7aKQ@mail.gmail.com> <03d701d1ed48$88bcfc50$9a36f4f0$@confluxtechnologies.com> <CAAPXgWu8t=CPAXbvn59EDaBDQcqbpYAgi+JQDTap5q9HHm83+A@mail.gmail.com>
In-Reply-To: <CAAPXgWu8t=CPAXbvn59EDaBDQcqbpYAgi+JQDTap5q9HHm83+A@mail.gmail.com>
Subject: RE: Maker-Checker principle and Document management
Date: Thu, 4 Aug 2016 11:40:31 +0530
Message-ID: <008b01d1ee16$e95380b0$bbfa8210$@confluxtechnologies.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQIvLEi9KkGjYtCS5MX1E7BY1MB0xwF80BUSAllAiQSfXyHkcA==
Content-Language: en-in
archived-at: Thu, 04 Aug 2016 06:10:42 -0000

Hi Lionel,

Document is not part of any Loan processing workflow restrictions as of =
now.
So, as I see from your requirement, for someone to go ahead with loan =
approval or disbursal, they just need to know that the document is =
verified.

We need not restrict download or update of documents in any way.
Only we need to add an API that approves a document. This API can be =
under maker checker framework(existing).
Person taking the approval/disbursal action can just look at the status =
of the document and know that it is a maker-checker verified document.

Regards,
Adi

-----Original Message-----
From: Lionel Raymundi - Poincenot [mailto:lionel@poincenot.com]=20
Sent: 04 August 2016 00:51
To: dev@fineract.incubator.apache.org
Subject: Re: Maker-Checker principle and Document management

Thanks Adi,

I dont know if I understood you correctly. Aiming to clarify, I =
enumerate some conditions of satisfaction for this enhancement.

1.- Document management API should not return documents which has the =
approved flag in false.
2.- Checker should be able to see the pending document on the maker =
checker tray.
3.- Checker should be able to approve the document.
4.- Checker should be able to reject the document (then the document =
should be removed from filestore?)
5.- All of the above is true if maker-checker is enabled by =
configuration for documents. Otherwise the behavior should be the same =
as current state (all documents are shown by document management api and =
there are no actions required by checker)

Accomplishing 1 is easy with the flag you suggested.

To accomplish 2, 3 and 4, I think we should add an entry to the audit =
table m_portfolio_command_source (maybe with command_as_json as empty =
object), so the check task can be handled by makercheckers resource api. =
The approval command would set the document flag as true and persist the =
info of the checker in the audit table. The reject command would remove =
the document from filestore and from table m_document.

Please correct me if I'm wrong, I'll be looking forward to your =
response.
Should we open an issue/task in jira to comment on this matter?

Thanks again

Lionel


2016-08-03 2:33 GMT-03:00 Adi Raju <adi.raju@confluxtechnologies.com>:

> Hi Lionel,
>
> Maker-checker enabled API workflow is like this:
> 1. Maker invokes an API
> 2. System does all the validation, reverses the transaction and stores =

> the complete API as part of audit table (No DB changes) 3. Checker=20
> reviews the API request and approves 4. The API is invoked again and=20
> the transaction taken to completion (DB changes happen only here)
>
> In case of documents, we need to store the documents on the server and =

> track its location, so DB change has to happen. So Maker-Checker=20
> workflow doesn't apply here.
> May be no body wanted a maker checker verification on documents till =
now.
>
> You are most welcome to contribute with this enhancement.
> My suggestion would be as follows:
> Introduce new field in documents table 'is_approved'.
> Introduce a new POST API '/documents/<documentid>?command=3Dapprove',=20
> which is the only way to change the status of the document.
> This API can be under maker-checker workflow.
>
> Regards,
> Adi
>
> -----Original Message-----
> From: Lionel Raymundi - Poincenot [mailto:lionel@poincenot.com]
> Sent: 02 August 2016 22:35
> To: dev@fineract.incubator.apache.org
> Subject: Maker-Checker principle and Document management
>
> Hi guys,
>
> I am facing a scenario where we need to apply a maker/checker scheme=20
> to the documents uploaded for a client. A user may upload a file=20
> saying it is an important company document, and somebody else should=20
> check that the document is in fact what the former said it is.
>
> I tested it through community app, I was able to configure it, but it=20
> didn't work (i mean, there was no need to validate the document for it =

> to be attached to the client). I made a fast review of the code, and I =

> think maker/checker scheme is not being validated at all when handling =

> documents in Fineract.
>
> So I have some questions...
> 1) Is there any technical/business issue which prevents to develop=20
> this feature?
> 2) If not, are you planning to develop this feature?
> 3) if not, is it useful if I start with it?
> 4) if so, should I "inspire" in any other maker/checker handling =
feature?
> Would you recommend any?
>
> Thanks in advance,
>
> Lionel
>
>