Re: [VOTE] APACHE FINERACT 1.2.0 Gentle reminder

2018-12-03 Thread Ippez Robert
+1
Shruthi M R, Please point us to the list of new features and enhancements
in this release. Thank you

On Tue, Dec 4, 2018 at 10:44 AM Mexina Daniel  wrote:

> +1
>
> On December 4, 2018 at 1:07 PM Shruthi M R <
> shru...@confluxtechnologies.com> wrote:
>
> Hello Fineract community,
>
> Kindly vote.
>
> Thank You,
>
> *Shruthi M R*
> Skype: Shruthi Rajaram | Mobile: +91-8277012716
>
> On Fri, Nov 30, 2018 at 5:25 PM Shruthi M R <
> shru...@confluxtechnologies.com>
> wrote:
>
> Hello Fineract community,
>
> We have created the Apache Fineract 1.2.0 release, with the artifacts
> below up for a vote.
>
> These are the goals of this release:
>
>- Share the new features and bug fixes that have been developed so far
>by external contributors, the community engineer, and previous GSOC
>interns
>
> *For more information including release notes, please see:*
> *
> https://cwiki.apache.org/confluence/display/FINERACT/1.2.0+-+Apache+Fineract
> <
> https://cwiki.apache.org/confluence/display/FINERACT/1.2.0+-+Apache+Fineract
> >*
>
> *Source & Binary files:*
> *https://dist.apache.org/repos/dist/dev/fineract/1.2.0/
> *
> Source:
>
>
> https://dist.apache.org/repos/dist/dev/fineract/1.2.0/apache-fineract-1.2.0-src.tar.gz
> <
> https://dist.apache.org/repos/dist/dev/fineract/1.2.0/apache-fineract-1.2.0-src.tar.gz
> >
>
> Binary/War :
>
>
> https://dist.apache.org/repos/dist/dev/fineract/1.2.0/apache-fineract-1.2.0-binary.tar.gz
>
> *Commit to be voted on:*
> https://github.com/apache/fineract/commits/1.2.0
>
> *Source build verification steps can be found at:*
> Refer 'README.md' in apache-fineract-1.2.0-src.tar.gz
>
> *Binary Deployment steps can be found at:*
>
>
> https://cwiki.apache.org/confluence/display/FINERACT/Fineract+Installation+on+Ubuntu+Server
>
> *KEYS file containing PGP Keys we use to sign the release: *
> https://dist.apache.org/repos/dist/dev/fineract/KEYS
>
> Vote will be open for 72 hours.
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Let me know if there are any discrepancies in the signing process.
>
> Here's my +1
>
> Thank You,
>
> *Shruthi M R*
> Skype: Shruthi Rajaram | Mobile: +91-8277012716
>
>
> Mexina Daniel
>
> Singo Africa Limited
> Block G, Mbezi Beach B | 7 Nakawale Road | P.O BOX 78908 | 14121 Dar es
> salaam
>
> +255 71 211 0791 | +255 22 261 8511
>
> amala.co.tz | singo.africa
>
>
>


-- 
Ippez Roberts
Founder/C.E.O - Swift3 Technologies (U) Ltd
"Redefining Next Generation I/O Systems"
P.O.Box 155, Moyo
UGANDA.
Tel: +256777421862/775686538
Skype ID: ippez.robert1
Email: ippezrob...@gmail.com


Re: [VOTE] APACHE FINERACT 1.2.0 Gentle reminder

2018-12-03 Thread Mexina Daniel
+1

> 
> On December 4, 2018 at 1:07 PM Shruthi M R 
>  wrote:
> 
> Hello Fineract community,
> 
> Kindly vote.
> 
> Thank You,
> 
> *Shruthi M R*
> Skype: Shruthi Rajaram | Mobile: +91-8277012716
> 
> On Fri, Nov 30, 2018 at 5:25 PM Shruthi M R 
> 
> wrote:
> 
> > > 
> > Hello Fineract community,
> > 
> > We have created the Apache Fineract 1.2.0 release, with the 
> > artifacts
> > below up for a vote.
> > 
> > These are the goals of this release:
> > 
> > * Share the new features and bug fixes that have been developed 
> > so far
> >   by external contributors, the community engineer, and 
> > previous GSOC
> >   interns
> > 
> > *For more information including release notes, please see:*
> > 
> > *https://cwiki.apache.org/confluence/display/FINERACT/1.2.0+-+Apache+Fineract
> > 
> > *
> > 
> > *Source & Binary files:*
> > *https://dist.apache.org/repos/dist/dev/fineract/1.2.0/
> > *
> > Source:
> > 
> > 
> > https://dist.apache.org/repos/dist/dev/fineract/1.2.0/apache-fineract-1.2.0-src.tar.gz
> > 
> > 
> > 
> > Binary/War :
> > 
> > 
> > https://dist.apache.org/repos/dist/dev/fineract/1.2.0/apache-fineract-1.2.0-binary.tar.gz
> > 
> > *Commit to be voted on:*
> > https://github.com/apache/fineract/commits/1.2.0
> > 
> > *Source build verification steps can be found at:*
> > Refer 'README.md' in apache-fineract-1.2.0-src.tar.gz
> > 
> > *Binary Deployment steps can be found at:*
> > 
> > 
> > https://cwiki.apache.org/confluence/display/FINERACT/Fineract+Installation+on+Ubuntu+Server
> > 
> > *KEYS file containing PGP Keys we use to sign the release: *
> > https://dist.apache.org/repos/dist/dev/fineract/KEYS
> > 
> > Vote will be open for 72 hours.
> > 
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> > 
> > Let me know if there are any discrepancies in the signing process.
> > 
> > Here's my +1
> > 
> > Thank You,
> > 
> > *Shruthi M R*
> > Skype: Shruthi Rajaram | Mobile: +91-8277012716
> > 
> > > 


Mexina Daniel

Singo Africa Limited
Block G, Mbezi Beach B | 7 Nakawale Road | P.O BOX 78908 | 14121 Dar es
salaam

+255 71 211 0791 | +255 22 261 8511

amala.co.tz https://amala.co.tz/  | singo.africa https://singo.africa

 


Re: [VOTE] APACHE FINERACT 1.2.0 Gentle reminder

2018-12-03 Thread Shruthi M R
Hello Fineract community,

Kindly  vote.

Thank You,

*Shruthi M R*
 Skype: Shruthi Rajaram | Mobile: +91-8277012716


On Fri, Nov 30, 2018 at 5:25 PM Shruthi M R 
wrote:

> Hello Fineract community,
>
> We have created the Apache Fineract 1.2.0 release, with the artifacts
> below up for a vote.
>
> These are the goals of this release:
>- Share the new features and bug fixes that have been developed so far
> by external contributors, the community engineer, and previous GSOC
> interns
>
> *For more information including release notes, please see:*
> *https://cwiki.apache.org/confluence/display/FINERACT/1.2.0+-+Apache+Fineract
> *
>
> *Source & Binary files:*
> *https://dist.apache.org/repos/dist/dev/fineract/1.2.0/
> *
> Source:
>
> https://dist.apache.org/repos/dist/dev/fineract/1.2.0/apache-fineract-1.2.0-src.tar.gz
> 
>
> Binary/War :
>
> https://dist.apache.org/repos/dist/dev/fineract/1.2.0/apache-fineract-1.2.0-binary.tar.gz
>
> *Commit to be voted on:*
> https://github.com/apache/fineract/commits/1.2.0
>
> *Source build verification steps can be found at:*
> Refer 'README.md' in apache-fineract-1.2.0-src.tar.gz
>
> *Binary Deployment steps can be found at:*
>
> https://cwiki.apache.org/confluence/display/FINERACT/Fineract+Installation+on+Ubuntu+Server
>
> *KEYS file containing PGP Keys we use to sign the release: *
> https://dist.apache.org/repos/dist/dev/fineract/KEYS
>
> Vote will be open for 72 hours.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Let me know if there are any discrepancies in the signing process.
>
>
> Here's my +1
>
> Thank You,
>
> *Shruthi M R*
>  Skype: Shruthi Rajaram | Mobile: +91-8277012716
>


Re: DISCUSS: Architecture/Design for Enabling External Apps to securely access data on Apache Fineract CN

2018-12-03 Thread Ed Cable
Hi Markus,

Thanks for sharing this insight on the list. I will pass this on to the
teams that are going to start doing some work with some external front-ends
and will make sure they ask questions and interact with you on-list.

Ed

On Mon, Dec 3, 2018 at 6:43 AM Markus Geiss  wrote:

> Hey Fineracters,
>
> we have chosen to use a clean and clear separation of concerns. This mean
> we will use separate data stores and services from the back office to serve
> front office/client facing apps. This also includes separate user
> management
> for those apps and a special API user to sync between both solutions.
>
> Depending on the use case we are going to use an offline-first solution
> based on on CouchDB/PouchDB to synchronize data to the devices,
> or offer a specialized service for real time processing. If the former is
> used we are going to use CouchDB sync gateway to keep the data
> back and front office services in sync.
>
> In both cases there will be a sort of mediator service to sync data between
> the separated front the back office services. For this we are using
> both integrations, direct API access and event based messaging.
>
> Given Fineract CN already comes with Active MQ it is simple to integrate
> any type of foreign component via the build in pub/sub model.
>
> Cheers
>
> Markus
>
> .:: YAGNI likes a DRY KISS ::.
>
>
> On Fri, Nov 30, 2018 at 2:35 PM Ed Cable  wrote:
>
> > Markus and others,
> >
> > I wanted to bring this back to top of mind. There are a number of efforts
> > in the community moving forward where external, client-facing apps might
> > soon be moving into actual production usage. Discussion on this thread
> > should be valuable happening in parallel to the thread that James started
> > on architecture/design for payments integration via Mojaloop.
> >
> > Markus - at this point, are you able to share what secure
> > architecture/design pattern you all chose in which to implement external
> > apps that is secure and not giving direct access to the financial
> > institution's data.
> >
> > For the community at large, especially those with deep experience
> > implementing these systems, we welcome your valuable input to help get
> this
> > right for Fineract CN.
> >
> > Ed
> >
> > On Tue, Mar 20, 2018 at 11:26 PM Sendoro Juma 
> > wrote:
> >
> > > My comments below is related to item no.2 not 3
> > >
> > > - Original Message -
> > > From: "Sendoro Juma" 
> > > To: "dev" 
> > > Cc: "mifos-developer" 
> > > Sent: Wednesday, March 21, 2018 8:07:34 AM
> > > Subject: Re: Self-Service Access for Client-Facing Apps on Apache
> > Fineract
> > > CN
> > >
> > > Hello Ed, Dev
> > >
> > > On item no. 3 on registration verification
> > >
> > > I think mobile phone verification is even more important than email
> > > nowadays, so it can be both email and phone.. it should be added and I
> > > suggest to be a MUST.
> > >
> > > Regards
> > > Sendoro
> > >
> > > - Original Message -
> > > From: "Ed Cable" 
> > > To: "dev" 
> > > Cc: "mifos-developer" 
> > > Sent: Wednesday, March 21, 2018 5:40:22 AM
> > > Subject: Re: Self-Service Access for Client-Facing Apps on Apache
> > Fineract
> > > CN
> > >
> > > Hi all,
> > >
> > > As a follow-up to this thread, Sundari has fleshed out some more
> details
> > > supporting the use cases Nayan had proposed for a client-facing digital
> > > credit app at
> > >
> > >
> https://cwiki.apache.org/confluence/display/FINERACT/Digital+Credit+App
> > >
> > > Markus, Myrle, or others - it'd be great to get your input as to how
> > you'd
> > > securely enable clients to access the data needed in such an app.
> > >
> > > Ed
> > >
> > > On Fri, Jan 26, 2018 at 6:20 PM, Ed Cable  wrote:
> > >
> > > > Hi Markus,
> > > >
> > > > Thanks for your replies.
> > > >
> > > > For the rest of the community,
> > > >
> > > > While I know that with the previous iteration of self-service apps,
> we
> > > > focused on implementing the back-end first and then allowing
> front-end
> > > use
> > > > cases to follow, a good approach this time around would be to get
> some
> > > > solid client-facing use cases identified and then design the back-end
> > and
> > > > integration with the data to support those use cases. Nayan from
> RuPie
> > > has
> > > > shared some initial use cases he has. I'm working with a Mifos
> > volunteer,
> > > > Sundari Swami, to flesh these out further but wanted to share the
> > initial
> > > > use cases Nayan had presented to stimulate further discussion on what
> > the
> > > > best approach to supporting a client-facing app on Apache Fineract CN
> > > that
> > > > would support adequately:
> > > >
> > > > From customer side
> > > >
> > > > UC 1. Client signup with basic data, and spot verification either
> with
> > > OTP
> > > > to mobile number or Aadhaar verification
> > > > UC 2. Customer can enter customer's other details like address,
> family,
> > > > work, income/expense details, once this data is verified from back
> > > office,
> 

Re: DISCUSS: Architecture/Design for Enabling External Apps to securely access data on Apache Fineract CN

2018-12-03 Thread Markus Geiss
Hey Fineracters,

we have chosen to use a clean and clear separation of concerns. This mean
we will use separate data stores and services from the back office to serve
front office/client facing apps. This also includes separate user management
for those apps and a special API user to sync between both solutions.

Depending on the use case we are going to use an offline-first solution
based on on CouchDB/PouchDB to synchronize data to the devices,
or offer a specialized service for real time processing. If the former is
used we are going to use CouchDB sync gateway to keep the data
back and front office services in sync.

In both cases there will be a sort of mediator service to sync data between
the separated front the back office services. For this we are using
both integrations, direct API access and event based messaging.

Given Fineract CN already comes with Active MQ it is simple to integrate
any type of foreign component via the build in pub/sub model.

Cheers

Markus

.:: YAGNI likes a DRY KISS ::.


On Fri, Nov 30, 2018 at 2:35 PM Ed Cable  wrote:

> Markus and others,
>
> I wanted to bring this back to top of mind. There are a number of efforts
> in the community moving forward where external, client-facing apps might
> soon be moving into actual production usage. Discussion on this thread
> should be valuable happening in parallel to the thread that James started
> on architecture/design for payments integration via Mojaloop.
>
> Markus - at this point, are you able to share what secure
> architecture/design pattern you all chose in which to implement external
> apps that is secure and not giving direct access to the financial
> institution's data.
>
> For the community at large, especially those with deep experience
> implementing these systems, we welcome your valuable input to help get this
> right for Fineract CN.
>
> Ed
>
> On Tue, Mar 20, 2018 at 11:26 PM Sendoro Juma 
> wrote:
>
> > My comments below is related to item no.2 not 3
> >
> > - Original Message -
> > From: "Sendoro Juma" 
> > To: "dev" 
> > Cc: "mifos-developer" 
> > Sent: Wednesday, March 21, 2018 8:07:34 AM
> > Subject: Re: Self-Service Access for Client-Facing Apps on Apache
> Fineract
> > CN
> >
> > Hello Ed, Dev
> >
> > On item no. 3 on registration verification
> >
> > I think mobile phone verification is even more important than email
> > nowadays, so it can be both email and phone.. it should be added and I
> > suggest to be a MUST.
> >
> > Regards
> > Sendoro
> >
> > - Original Message -
> > From: "Ed Cable" 
> > To: "dev" 
> > Cc: "mifos-developer" 
> > Sent: Wednesday, March 21, 2018 5:40:22 AM
> > Subject: Re: Self-Service Access for Client-Facing Apps on Apache
> Fineract
> > CN
> >
> > Hi all,
> >
> > As a follow-up to this thread, Sundari has fleshed out some more details
> > supporting the use cases Nayan had proposed for a client-facing digital
> > credit app at
> >
> > https://cwiki.apache.org/confluence/display/FINERACT/Digital+Credit+App
> >
> > Markus, Myrle, or others - it'd be great to get your input as to how
> you'd
> > securely enable clients to access the data needed in such an app.
> >
> > Ed
> >
> > On Fri, Jan 26, 2018 at 6:20 PM, Ed Cable  wrote:
> >
> > > Hi Markus,
> > >
> > > Thanks for your replies.
> > >
> > > For the rest of the community,
> > >
> > > While I know that with the previous iteration of self-service apps, we
> > > focused on implementing the back-end first and then allowing front-end
> > use
> > > cases to follow, a good approach this time around would be to get some
> > > solid client-facing use cases identified and then design the back-end
> and
> > > integration with the data to support those use cases. Nayan from RuPie
> > has
> > > shared some initial use cases he has. I'm working with a Mifos
> volunteer,
> > > Sundari Swami, to flesh these out further but wanted to share the
> initial
> > > use cases Nayan had presented to stimulate further discussion on what
> the
> > > best approach to supporting a client-facing app on Apache Fineract CN
> > that
> > > would support adequately:
> > >
> > > From customer side
> > >
> > > UC 1. Client signup with basic data, and spot verification either with
> > OTP
> > > to mobile number or Aadhaar verification
> > > UC 2. Customer can enter customer's other details like address, family,
> > > work, income/expense details, once this data is verified from back
> > office,
> > > customer can't edit any of these data
> > > UC 3. Apply for loans
> > > UC 4. Repay EMI
> > > UC 5. Preclose his/her loans
> > > UC 6. Log support request
> > > UC 7. Upload documents like photo of electricity bills, voter id,
> > passport
> > > etc, once documents are verified and accepted from back office customer
> > > cab't edit , delete the verified documents, but customer can upload new
> > > documents
> > >
> > > From organization point of view
> > >
> > > UC 1, Offer loan products based below criteria
> > >
> > >
> > >- Location ( 

Getting next expected working date

2018-12-03 Thread Ippez Robert
Hi Dev,
Hope everyone is okay. Can some one please help how to the get the next
expected working date from Fineract back-end and display it at front-end?

Things to Note are *Working Days  *table and *Holidays *table. For example
an institution B has *Monday*, *Wednesday* and *Saturday* as their working
days in a week. So from front end how can i fetch the next working day and
date?.

*Example*:- Today being a *Monday*, its a working day say for an
institution B, The next expected day is *Wednesday* and date is *5 Dec 2018*
but if *Wednesday* *5/12/2018* is a holiday, it should return *Saturday 8
Dec 2018* as next working date.

Thanks
Regards

-- 
Ippez Roberts
Skype ID: ippez.robert1
Email: ippezrob...@gmail.com