Mailing-List: contact dev-help@fineract.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@fineract.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <03d701d1ed48$88bcfc50$9a36f4f0$@confluxtechnologies.com>
References: <CAAPXgWvpTqNWOiRGg4FETY8K_uJkJtrddw6GJi1ZYdJ7KR7aKQ@mail.gmail.com>
 <03d701d1ed48$88bcfc50$9a36f4f0$@confluxtechnologies.com>
From: Lionel Raymundi - Poincenot <lionel@poincenot.com>
Date: Wed, 3 Aug 2016 16:20:53 -0300
Message-ID: <CAAPXgWu8t=CPAXbvn59EDaBDQcqbpYAgi+JQDTap5q9HHm83+A@mail.gmail.com>
Subject: Re: Maker-Checker principle and Document management
To: dev@fineract.incubator.apache.org
Content-Type: multipart/alternative; boundary=001a113acdde9ec56b05392fbce4
archived-at: Wed, 03 Aug 2016 19:21:26 -0000

--001a113acdde9ec56b05392fbce4
Content-Type: text/plain; charset=UTF-8

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 reviews the API request and approves
> 4. The API is invoked again and 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 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=approve', 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 to
> the documents uploaded for a client. A user may upload a file saying it is
> an important company document, and somebody else should 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
> 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 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
>
>

--001a113acdde9ec56b05392fbce4--