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:lio...@poincenot.com] 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.r...@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:lio...@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 > >
