Re: Discussing Mojaloop and Fineract Integration

[James Dailey]

Hi all

To bring this discussion back to the list.  We had a call today - and some
ideas and questions may be relevant for the entire list.

First, I'm articulating a vision whereby Mojaloop is used as the "switch"
between multiple instances of Fineract 1.x/Mifos in various
configurations.  Mifos can be configured as a "microfinance institution" or
more like a savings cooperative, or like a digital bank (for our purposes,
a configuration where there are neither field operations nor teller
operations, only digital accounts that can interact with others
digitally).  We discussed the different types or styles of institutions:
from a purely digital first to a multi-tenant instance for multiple small
microfinance orgs.  Essentially Fineract/Mifos is the Account system and
Mojaloop connects an instance to the larger ecosystem of account providers.

Second, I'm emphasizing that Mojaloop is an instantiation of the
LevelOneProject.org, which implements key principles such as PUSH payments,
open loop, interoperability, and so on.  It is a modern payments approach.
It is not blockchain.  It is intended to include banks, telecom providers,
and any other provider of digital transaction accounts.  Ubiquity of
payments is a fundamental building block for a digital economy.
Microfinance is hampered by the high cost of setting up payment interfaces
and payment scheme fees - Mojaloop is intended to cut down on those
barriers to entry.

Third, while the Mojaloop team was implementing their core services and
ledger approaches, a related team was working on APIs that could connect
for better interoperability.  Those APIs are now available to the Mifos
team - see https://drive.google.com/open?id=0ByeK44WJrHIvOGs0UkZUUHFzdnBCe
nRLX0dzcHZUUGlaSlV3

Fourth, we discussed some first steps, which we think include setting up an
instance of mojaloop to test against and to map the existing mifos APIs
against the mojaloop APIs.

Fifth, we discussed on some email exchanges about how settlement and
cryptographic escrow works.

Resources in process - need to be moved:
https://drive.google.com/open?id=0ByeK44WJrHIvOGs0UkZUUHFzdnBCe
nRLX0dzcHZUUGlaSlV3
https://goo.gl/1sR2dq (move this confluence?)

More later...

James D.


On Wed, Mar 7, 2018 at 11:17 AM Ed Cable  wrote:

> By the way,
>
> Matt Bohan from Gates Foundation shared v1 of  API documentation we were
> awaiting.
>
> It can be downloaded from here: ​​https://drive.google.com/open?id=
> 0ByeK44WJrHIvOGs0UkZUUHFzdnBCenRLX0dzcHZUUGlaSlV3
>
> Ed
>
>
>

Re: Mifos Payment Gateway

[Vladimir Fomene]

Hello Ed,
Hope this email finds you well. Anytime today will work for me.

Best,
Vladimir Fomene

On 7 March 2018 at 22:49, Ed Cable  wrote:

> Thank you Steve for your thorough review. Apologies for the delay. I
> wanted to get the payment gateway group together for another call so we can
> identify the best path forward in the four areas you specified, check in on
> the progress Antony has made with his code and how we can incorporate
> Vladimir's data model. I also want to discuss if we should try to scope out
> another project for GSOC centered around this - I think we have the needed
> clarity now but wanted to ship somethign to the community prior to after
> this summer. Perhaps we could aim for an alpha version prior to GSOC and
> have the GSOC student work on the beta.
>
> Would this Friday at 1400GMT work for everyone?
>
> We can use Hangouts Meet for the call. Folks can join through:
> https://meet.google.com/ajy-twnd-irs
>
> On Wed, Jan 31, 2018 at 10:59 AM, Steve Conrad  wrote:
>
>> Hi everyone -
>>
>> I have been spending some time over the past few weeks trying to
>> understand
>> the current status of the Mifos Payment Gateway and determine what things
>> still need to be done. I wanted to summarize my understanding of where the
>> gateway is at.
>>
>> I spoke with Avik to talk through the requirements and what work has been
>> done so far. Vladimir Fomene worked to develop a data model and some basic
>> functionality around inbound (loan repayments) and outbound
>> (disbursements)
>> transactions. At the same time, Antony Omeri was developing a parallel
>> model and platform.Over the past couple of months Antony has developed
>> much
>> of the core functionality and integrated it into the Fineract platform,
>> including using ActiveMQ for messaging.
>>
>> You can see a demo here of Antony's work. More functionality has been
>> implemented since this was recorded, including porting from RabbitMQ to
>> ActiveMQ
>> https://www.youtube.com/watch?time_continue=824=xqWIveT57vo
>>
>> And the repo is here:
>> https://github.com/OmexIT/fineract
>>
>> It seems to me that the best course forward is to continue to build on
>> Antony's platform. However, there are elements of Vladimir's data model
>> that I think we should consider integrating into Antony's platform -
>> particularly the ability to configure connections between MFIs and
>> MMPs/aggregators. We also need to think through functionality for error
>> handling and rolling back transactions. Beyond that, there are additional
>> use cases around batch disbursals, reconciliation, etc.
>>
>> If there are developers who are interested in working on bringing this
>> project to completion, I see at least 4 areas that need work:
>>1) Expanding the schema to allow configuration parameters between an
>> MFI
>> and MMP (the API credentials, etc for a particular MFI connection to a
>> provider/aggregator)
>>2) Implementing a couple of specific payment providers to prove out the
>> functionality - possibly Beyonic and something like RazorPay
>>3) Implementing some kind of UI that we can use as a test platform -
>> testing disbursals and repayments
>>4) Implementing use cases that have been defined but not yet developed
>> -
>> batch disbursals, reconciliation, etc.
>>
>> Thanks,
>> Steve
>>
>
>
>
> --
> *Ed Cable*
> President/CEO, Mifos Initiative
> edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
> <(484)%20477-8649>
>
> *Collectively Creating a World of 3 Billion Maries | *http://mifos.org
>   
>
>

Re: Reg End of day

[Santosh Math]

Hi Hari haran,

Could you give some details about end of day operations?



On Fri, Mar 9, 2018 at 11:17 AM, Hari Haran  wrote:

> Hi,
>
> How end of day operations handled in mifos?
>
> --
>
>
> --
> Regards,
> Hariharan.G
> Technical Consultant | Habile Technologies
> www.habiletechnologies.com | (O): +91 44 4202 0550 | (M): + 91 90030 25156
> Skype: hari.mitteam | https://www.facebook.com/HabileTechnologies
> 
>
> --
> DISCLAIMER:
> All emails and any files transmitted with them are confidential and
> intended solely for the use of the individual or entity to whom they are
> addressed. If you have received an email in error please notify your system
> manager. The message in the email you have received contains confidential
> information and is intended only for the individual named. If you are not
> the named addressee you should not disseminate, distribute or copy the
> email. Please notify the sender immediately by email if you have received
> an email by mistake and delete the email from your system. If you are not
> the intended recipient you are notified that disclosing, copying,
> distributing or taking any action in reliance on the contents of the
> information is strictly prohibited.
>



-- 
Thanks & Regards

Santosh Math

*QA Engineer*

*Conflux Technologies Pvt Ltd *
| *Office*: +91-080-41208662 |

*Address*: #304, 2nd Floor, 7th Main Road, HRBR Layout 1st Block,
Bengaluru, Karnataka, 560043 INDIA

Reg End of day

[Hari Haran]

Hi,

How end of day operations handled in mifos?

-- 


--
Regards,
Hariharan.G
Technical Consultant | Habile Technologies
www.habiletechnologies.com | (O): +91 44 4202 0550 | (M): + 91 90030 25156
Skype: hari.mitteam | https://www.facebook.com/HabileTechnologies


--
DISCLAIMER:
All emails and any files transmitted with them are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received an email in error please notify your system
manager. The message in the email you have received contains confidential
information and is intended only for the individual named. If you are not
the named addressee you should not disseminate, distribute or copy the
email. Please notify the sender immediately by email if you have received
an email by mistake and delete the email from your system. If you are not
the intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of the
information is strictly prohibited.

fetching past date state of loans

[Sam Pach]

Hi All,


 We have a requirement to compile reports up-till a specified date (mostly
month end).

This report would contain Pos/DPD/interest on a past date for all the loans
in the system.

Is there an api we can leverage for getting historical data or build an
architecture to at least start supporting this going forward ?

Thanks for the help in advance.





regards,

sam

Re: Discussing Mojaloop and Fineract Integration

[lamine . sano]

You fired first!  I was answering your previous email.
It makes much more sense to me now.
I was pretty sure about the crypto escrow requirement of ILP.

Thanks for the clarification.


On Thu, 8 Mar 2018 at 8:15 PM James Dailey  wrote:

> Lamine
>
> Ok, I think I was wrong in part.  In the press release Ripple Labs wrote:
>
> "ILP enables transactions across any number of different ledgers and
> exchanges using cryptographic escrow and a specialized two-phase commit
> protocol."
> https://ripple.com/insights/implementing-the-interledger-protocol/
> So, thinking about this more... in ILP there is a concept of cryptographic
> escrow, which I believe is more about the transport layer of the payment
> than the API calls.  That is, ILP allows for multi-hop transactions and the
> cryptographic escrow concept is implemented down in that layer - in that
> funds are "locked" in the source system and the "locked funds" concept is
> embedded in the ILP so that the final receiving system knows that the funds
> are good.  For a single hop, which is what a single Mojaloop "switch" would
> entail, the escrow concept is rather less important, although I suppose
> related to the latency between the two edge systems.  If you daisy chained
> multiple mojaloop central ledgers with the DFSPs, then you would need the
> cryptographic escrow fully.
>
> In a message based transaction system, the funds are determined to be
> there, then the system pulls or pushes those funds and the receiving
> institution takes a small risk that funds are not actually there a few
> seconds later. That's the status quo in ATM and Card based systems.  In a
> classic SWIFT/sending a wire case, the funds actually leave the system
> before the receiving institution gets them. This is closer to what mojaloop
> has implemented functionally.
>
> Finally, Settlement of course is separate and I already mentioned is
> outside of mojaloop, with the exception of calculating the settlement
> positions.
>
> Thanks for asking!
> James
>
>
> On Thu, Mar 8, 2018 at 11:57 AM James Dailey 
> wrote:
>
>> Lamine
>>
>> Yes.  See also https://interledger.org/rfcs/0003-interledger-protocol/
>> (latest is version 9 of draft ILP-RFC-3) The scope is intentionally
>> limited, does not include escrow in the protocol, and to quote:
>> "The Interledger Protocol provides for *routing* payments across
>> different digital asset ledgers while isolating senders and receivers from
>> the risk of intermediary failures. Secure multi-hop payments and automatic
>> routing enables a global network of networks for different types of value
>> that can connect any sender with any receiver."
>>
>> While XRP has required escrow... I don't think that ILP requires an
>> escrow setup.  Settlement can occur via trusted net mechanisms (i.e. within
>> a range of exposures and timing of settlement relates to that).
>>
>> Mojaloop includes a central ledger and "settlement mechanism"- see this
>> diagram
>> https://github.com/mojaloop/docs/blob/master/CentralLedger/central_ledger_block_diagram.png
>>  (let
>> me know if it is not visible, I've noticed some issues in the past).
>> Settlement is actually done outside of the system - it is assumed that this
>> system informs that settlement participants of the net positions for this
>> payment scheme.
>>
>> Please let me know if you think I'm off-base, and I'll also put this on
>> list with my notes from today.
>>
>> James
>>
>> On Thu, Mar 8, 2018 at 11:42 AM Lamine Sano-Ouattara <
>> lamine.s...@gmail.com> wrote:
>>
>>> Hi James,
>>>
>>> I was on the call earlier, and I wanted to get a clarification
>>> pertaining to the API flow we went over together.
>>> From my understanding of ILP, which is a Ripple developed protocol, it
>>> requires the involved ledgers to have some basic escrow semantics in order
>>> to work and eliminate the counterparty risk in a transaction.  If the
>>> escrow functionality does not exist natively, it has to be implemented at
>>> the local ledger level for ILP to work.
>>>
>>> Furthermore, ILP has recently been joined the Hyperledger umbrella of
>>> blockchain projects under codename Quilt.  The ILP standard is defined in
>>> RFC 791 - https://tools.ietf.org/html/rfc791.
>>>
>>> Where I am getting confused concerning Mojaloop implementation of ILP is
>>> that I did not perceive the escrow mechanism in the API calls, or was it
>>> assumed to happen in the background?  Or is Mojaloop implementing its own
>>> ledger facility to clear and settle transactions beween DFSP?
>>>
>>>
>>> Thanks.
>>>
>>>
>>> Kind Regards,
>>>
>>> --Lamine Sano-Ouattara
>>>
>>> An army of sheep led by a lion would defeat an army of lions led by a
>>> sheep.
>>>
>>> On Wed, Mar 7, 2018 at 7:17 PM, Ed Cable  wrote:
>>>
 By the way,

 Matt Bohan from Gates Foundation shared v1 of  API documentation we were
 awaiting.

 It can be downloaded from here: ​​

Re: Discussing Mojaloop and Fineract Integration

[James Dailey]

Lamine

Ok, I think I was wrong in part.  In the press release Ripple Labs wrote:

"ILP enables transactions across any number of different ledgers and
exchanges using cryptographic escrow and a specialized two-phase commit
protocol."
https://ripple.com/insights/implementing-the-interledger-protocol/
So, thinking about this more... in ILP there is a concept of cryptographic
escrow, which I believe is more about the transport layer of the payment
than the API calls.  That is, ILP allows for multi-hop transactions and the
cryptographic escrow concept is implemented down in that layer - in that
funds are "locked" in the source system and the "locked funds" concept is
embedded in the ILP so that the final receiving system knows that the funds
are good.  For a single hop, which is what a single Mojaloop "switch" would
entail, the escrow concept is rather less important, although I suppose
related to the latency between the two edge systems.  If you daisy chained
multiple mojaloop central ledgers with the DFSPs, then you would need the
cryptographic escrow fully.

In a message based transaction system, the funds are determined to be
there, then the system pulls or pushes those funds and the receiving
institution takes a small risk that funds are not actually there a few
seconds later. That's the status quo in ATM and Card based systems.  In a
classic SWIFT/sending a wire case, the funds actually leave the system
before the receiving institution gets them. This is closer to what mojaloop
has implemented functionally.

Finally, Settlement of course is separate and I already mentioned is
outside of mojaloop, with the exception of calculating the settlement
positions.

Thanks for asking!
James


On Thu, Mar 8, 2018 at 11:57 AM James Dailey  wrote:

> Lamine
>
> Yes.  See also https://interledger.org/rfcs/0003-interledger-protocol/
> (latest is version 9 of draft ILP-RFC-3) The scope is intentionally
> limited, does not include escrow in the protocol, and to quote:
> "The Interledger Protocol provides for *routing* payments across
> different digital asset ledgers while isolating senders and receivers from
> the risk of intermediary failures. Secure multi-hop payments and automatic
> routing enables a global network of networks for different types of value
> that can connect any sender with any receiver."
>
> While XRP has required escrow... I don't think that ILP requires an escrow
> setup.  Settlement can occur via trusted net mechanisms (i.e. within a
> range of exposures and timing of settlement relates to that).
>
> Mojaloop includes a central ledger and "settlement mechanism"- see this
> diagram
> https://github.com/mojaloop/docs/blob/master/CentralLedger/central_ledger_block_diagram.png
>  (let
> me know if it is not visible, I've noticed some issues in the past).
> Settlement is actually done outside of the system - it is assumed that this
> system informs that settlement participants of the net positions for this
> payment scheme.
>
> Please let me know if you think I'm off-base, and I'll also put this on
> list with my notes from today.
>
> James
>
> On Thu, Mar 8, 2018 at 11:42 AM Lamine Sano-Ouattara <
> lamine.s...@gmail.com> wrote:
>
>> Hi James,
>>
>> I was on the call earlier, and I wanted to get a clarification pertaining
>> to the API flow we went over together.
>> From my understanding of ILP, which is a Ripple developed protocol, it
>> requires the involved ledgers to have some basic escrow semantics in order
>> to work and eliminate the counterparty risk in a transaction.  If the
>> escrow functionality does not exist natively, it has to be implemented at
>> the local ledger level for ILP to work.
>>
>> Furthermore, ILP has recently been joined the Hyperledger umbrella of
>> blockchain projects under codename Quilt.  The ILP standard is defined in
>> RFC 791 - https://tools.ietf.org/html/rfc791.
>>
>> Where I am getting confused concerning Mojaloop implementation of ILP is
>> that I did not perceive the escrow mechanism in the API calls, or was it
>> assumed to happen in the background?  Or is Mojaloop implementing its own
>> ledger facility to clear and settle transactions beween DFSP?
>>
>>
>> Thanks.
>>
>>
>> Kind Regards,
>>
>> --Lamine Sano-Ouattara
>>
>> An army of sheep led by a lion would defeat an army of lions led by a
>> sheep.
>>
>> On Wed, Mar 7, 2018 at 7:17 PM, Ed Cable  wrote:
>>
>>> By the way,
>>>
>>> Matt Bohan from Gates Foundation shared v1 of  API documentation we were
>>> awaiting.
>>>
>>> It can be downloaded from here: ​​
>>>
>>> https://drive.google.com/open?id=0ByeK44WJrHIvOGs0UkZUUHFzdnBCenRLX0dzcHZUUGlaSlV3
>>>
>>> Ed
>>>
>>> On Wed, Mar 7, 2018 at 11:14 AM, Ed Cable  wrote:
>>>
>>> > Steve, Isaac, and others that would like to join.
>>> >
>>> > Would this Thursday at 1700GMT (900PST) work for this meeting?
>>> >
>>> > If so, please register at https://attendee.gototraining.com/r/
>>> > 

Re: Discussing Mojaloop and Fineract Integration

[James Dailey]

Lamine

Yes.  See also https://interledger.org/rfcs/0003-interledger-protocol/
(latest is version 9 of draft ILP-RFC-3) The scope is intentionally
limited, does not include escrow in the protocol, and to quote:
"The Interledger Protocol provides for *routing* payments across different
digital asset ledgers while isolating senders and receivers from the risk
of intermediary failures. Secure multi-hop payments and automatic routing
enables a global network of networks for different types of value that can
connect any sender with any receiver."

While XRP has required escrow... I don't think that ILP requires an escrow
setup.  Settlement can occur via trusted net mechanisms (i.e. within a
range of exposures and timing of settlement relates to that).

Mojaloop includes a central ledger and "settlement mechanism"- see this
diagram
https://github.com/mojaloop/docs/blob/master/CentralLedger/central_ledger_block_diagram.png
(let
me know if it is not visible, I've noticed some issues in the past).
Settlement is actually done outside of the system - it is assumed that this
system informs that settlement participants of the net positions for this
payment scheme.

Please let me know if you think I'm off-base, and I'll also put this on
list with my notes from today.

James

On Thu, Mar 8, 2018 at 11:42 AM Lamine Sano-Ouattara 
wrote:

> Hi James,
>
> I was on the call earlier, and I wanted to get a clarification pertaining
> to the API flow we went over together.
> From my understanding of ILP, which is a Ripple developed protocol, it
> requires the involved ledgers to have some basic escrow semantics in order
> to work and eliminate the counterparty risk in a transaction.  If the
> escrow functionality does not exist natively, it has to be implemented at
> the local ledger level for ILP to work.
>
> Furthermore, ILP has recently been joined the Hyperledger umbrella of
> blockchain projects under codename Quilt.  The ILP standard is defined in
> RFC 791 - https://tools.ietf.org/html/rfc791.
>
> Where I am getting confused concerning Mojaloop implementation of ILP is
> that I did not perceive the escrow mechanism in the API calls, or was it
> assumed to happen in the background?  Or is Mojaloop implementing its own
> ledger facility to clear and settle transactions beween DFSP?
>
>
> Thanks.
>
>
> Kind Regards,
>
> --Lamine Sano-Ouattara
>
> An army of sheep led by a lion would defeat an army of lions led by a
> sheep.
>
> On Wed, Mar 7, 2018 at 7:17 PM, Ed Cable  wrote:
>
>> By the way,
>>
>> Matt Bohan from Gates Foundation shared v1 of  API documentation we were
>> awaiting.
>>
>> It can be downloaded from here: ​​
>>
>> https://drive.google.com/open?id=0ByeK44WJrHIvOGs0UkZUUHFzdnBCenRLX0dzcHZUUGlaSlV3
>>
>> Ed
>>
>> On Wed, Mar 7, 2018 at 11:14 AM, Ed Cable  wrote:
>>
>> > Steve, Isaac, and others that would like to join.
>> >
>> > Would this Thursday at 1700GMT (900PST) work for this meeting?
>> >
>> > If so, please register at https://attendee.gototraining.com/r/
>> > 4087378790399458305
>> >
>> > Otherwise, we'll find a more suitable time.
>> >
>> >
>> > On Thu, Mar 1, 2018 at 2:24 AM, Isaac Kamga 
>> wrote:
>> >
>> >> Welcome aboard Steve.
>> >>
>> >> On Wed, Feb 28, 2018 at 10:39 PM, Steve Conrad 
>> >> wrote:
>> >>
>> >> > I'd like to be involved in this project and am happy to begin work
>> on in
>> >> > integration proof of concept.
>> >> > Steve
>> >> >
>> >> >
>> >> > On Wed, Feb 28, 2018 at 1:08 PM, Ed Cable  wrote:
>> >> >
>> >> >> So as not to lose the momentum from the webinar that was held last
>> >> month -
>> >> >> http://mifos.org/blog/intro-to-mojaloop/.
>> >> >>
>> >> >> I want to start a thread discussing Fineract/Mifos integration with
>> >> >> Mojaloop and to schedule a call to bring together any of the
>> interested
>> >> >> parties from the community - this can be both those interested in
>> >> adoption
>> >> >> of Mojaloop but primarily around technical contributors or partners
>> who
>> >> >> want to assist with the integration between Fineract and Mojaloop.
>> >> >>
>> >> >> One objective of this integration is to help provide a lab
>> environment
>> >> and
>> >> >> proof of concept integration to demonstrate what can be done between
>> >> >> Fineract and Mojaloop.
>> >> >>
>> >> >> Isaac has begun condensing down some of the Mojaloop docs into the
>> >> salient
>> >> >> points for our integration at https://goo.gl/1sR2dq
>> >> >>
>> >> >> I'd like to target a call for mid next week midday GMT.
>> >> >>
>> >> >> I aim to equip an individual contributor to begin working on this
>> >> straight
>> >> >> away but if not, scope out the integration to sufficient detail as a
>> >> >> project for a GSOC intern.
>> >> >>
>> >> >>
>> >> >> *Ed Cable*
>> >> >> President/CEO, Mifos Initiative
>> >> >> edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
>> >> >> 

Re: Discussing Mojaloop and Fineract Integration

[Lamine Sano-Ouattara]

Hi James,

I was on the call earlier, and I wanted to get a clarification pertaining
to the API flow we went over together.
>From my understanding of ILP, which is a Ripple developed protocol, it
requires the involved ledgers to have some basic escrow semantics in order
to work and eliminate the counterparty risk in a transaction.  If the
escrow functionality does not exist natively, it has to be implemented at
the local ledger level for ILP to work.

Furthermore, ILP has recently been joined the Hyperledger umbrella of
blockchain projects under codename Quilt.  The ILP standard is defined in
RFC 791 - https://tools.ietf.org/html/rfc791.

Where I am getting confused concerning Mojaloop implementation of ILP is
that I did not perceive the escrow mechanism in the API calls, or was it
assumed to happen in the background?  Or is Mojaloop implementing its own
ledger facility to clear and settle transactions beween DFSP?


Thanks.


Kind Regards,

--Lamine Sano-Ouattara

An army of sheep led by a lion would defeat an army of lions led by a sheep.

On Wed, Mar 7, 2018 at 7:17 PM, Ed Cable  wrote:

> By the way,
>
> Matt Bohan from Gates Foundation shared v1 of  API documentation we were
> awaiting.
>
> It can be downloaded from here: ​​
> https://drive.google.com/open?id=0ByeK44WJrHIvOGs0UkZUUHFzdnBCe
> nRLX0dzcHZUUGlaSlV3
>
> Ed
>
> On Wed, Mar 7, 2018 at 11:14 AM, Ed Cable  wrote:
>
> > Steve, Isaac, and others that would like to join.
> >
> > Would this Thursday at 1700GMT (900PST) work for this meeting?
> >
> > If so, please register at https://attendee.gototraining.com/r/
> > 4087378790399458305
> >
> > Otherwise, we'll find a more suitable time.
> >
> >
> > On Thu, Mar 1, 2018 at 2:24 AM, Isaac Kamga 
> wrote:
> >
> >> Welcome aboard Steve.
> >>
> >> On Wed, Feb 28, 2018 at 10:39 PM, Steve Conrad 
> >> wrote:
> >>
> >> > I'd like to be involved in this project and am happy to begin work on
> in
> >> > integration proof of concept.
> >> > Steve
> >> >
> >> >
> >> > On Wed, Feb 28, 2018 at 1:08 PM, Ed Cable  wrote:
> >> >
> >> >> So as not to lose the momentum from the webinar that was held last
> >> month -
> >> >> http://mifos.org/blog/intro-to-mojaloop/.
> >> >>
> >> >> I want to start a thread discussing Fineract/Mifos integration with
> >> >> Mojaloop and to schedule a call to bring together any of the
> interested
> >> >> parties from the community - this can be both those interested in
> >> adoption
> >> >> of Mojaloop but primarily around technical contributors or partners
> who
> >> >> want to assist with the integration between Fineract and Mojaloop.
> >> >>
> >> >> One objective of this integration is to help provide a lab
> environment
> >> and
> >> >> proof of concept integration to demonstrate what can be done between
> >> >> Fineract and Mojaloop.
> >> >>
> >> >> Isaac has begun condensing down some of the Mojaloop docs into the
> >> salient
> >> >> points for our integration at https://goo.gl/1sR2dq
> >> >>
> >> >> I'd like to target a call for mid next week midday GMT.
> >> >>
> >> >> I aim to equip an individual contributor to begin working on this
> >> straight
> >> >> away but if not, scope out the integration to sufficient detail as a
> >> >> project for a GSOC intern.
> >> >>
> >> >>
> >> >> *Ed Cable*
> >> >> President/CEO, Mifos Initiative
> >> >> edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
> >> >> <(484)%20477-8649>
> >> >>
> >> >> *Collectively Creating a World of 3 Billion Maries | *
> http://mifos.org
> >> >>   
> >> >>
> >> >
> >> >
> >>
> >
> >
> >
> > --
> > *Ed Cable*
> > President/CEO, Mifos Initiative
> > edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
> > <(484)%20477-8649>
> >
> > *Collectively Creating a World of 3 Billion Maries | *http://mifos.org
> >   
> >
> >
>
>
> --
> *Ed Cable*
> President/CEO, Mifos Initiative
> edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
>
> *Collectively Creating a World of 3 Billion Maries | *http://mifos.org
>   
>

Re: Planned Features for Fineract 1.2 Release

[Ed Cable]

Fineract Committers,

We need to merge the pull requests at https://issues.apache.org/jira
/projects/FINERACT/versions/12342856 into develop branch so we can push
this to our staging server and QA can begin. Could I please get some help
with the review and merge of these PRs.

Thanks,

Ed



On Fri, Mar 2, 2018 at 9:47 AM, Ed Cable  wrote:

> Hi all,
>
> Just so we can keep in line with the target that we had given initially
> around dates for the 1.2 release, here's a pseudo-announcement of the
> release.
>
> The features that were ready as of the cut-off dates during our planning
> period have been tagged and put in this fix version:
>
> https://issues.apache.org/jira/projects/FINERACT/versions/12342856
>
> They include the Swagger API Documentation by Chirag Sanyam and GSIM/GLIM
> enhancements by Nikhil.
>
> Apart from small issues or enhancements that I might have missed that are
> already complete, for 1.2 we won't be shipping any major work apart from
> there.
>
> We're getting our boards configured to visualize the planning for each
> release and are now starting the planning for 1.3 so if you have work that
> you're planning to contribute, please make sure it has a corresponding JIRA
> ticket.
>
> Thanks,
>
> Ed
>
> On Tue, Feb 27, 2018 at 9:22 AM, Ed Cable  wrote:
>
>> Myrle,
>>
>> Thanks for adding that clarity as my initial email was probably
>> confusing. We are moving to time-driven releases and the initial planning
>> period I mentioned was to determine which features or work was ready to be
>> integrated and could be included in the cut-off date for that time-driven
>> release.
>>
>> I have set up a scrum board and requested karma to grant Robert access so
>> he can assist in planning out the next release, Apache Fineract 1.2
>>
>> Ed
>>
>> On Wed, Feb 14, 2018 at 4:01 AM, Sendoro Juma 
>> wrote:
>>
>>> Dear Myrle,
>>>
>>> I see your point:
>>>
>>> I think primarily we should agree that it is time-driven:
>>>
>>> Features listed or to be listed should be taken only as way of making
>>> focus and pushing for tasks to be completed in-time as per release
>>> schedule, should they fall short of time... we should move on... with our
>>> primary commitment which is time.
>>>
>>> How about that?
>>>
>>> Best Regards
>>> Sendoro
>>>
>>>
>>>
>>> - Original Message -
>>> From: "Myrle Krantz" 
>>> To: "dev" 
>>> Sent: Wednesday, February 14, 2018 1:55:03 PM
>>> Subject: Re: Planning Apache Fineract 1.2 Release
>>>
>>> Our release can either be feature-driven or time-driven.  Not both.
>>> If it's feature-driven, we don't release until the features are in
>>> there.  If it's time-driven, we release on a certain date, based on
>>> what's made it in.
>>>
>>> Are we in agreement that we wish to make a time-driven release?  Then
>>> we should be adding a feature to the list for a given release when
>>> that feature is integrated, and not before.
>>>
>>> Best Regards,
>>> Myrle
>>>
>>>
>>> On Wed, Feb 14, 2018 at 12:41 PM, Sendoro Juma 
>>> wrote:
>>> > Hello Ed,
>>> >
>>> > +1 on all you mentioned!
>>> >
>>> > I would propose additional point which you have kind of mention it
>>> already on item related to API Swagger, but just as emphasize
>>> >
>>> > - APIs related issues/Enhancements that has been discovered by Mobile
>>> or Web client application side.
>>> >
>>> > This is so,  because we might take longer in addressing issues already
>>> known from client application side; buy just because of missing visibility;
>>> > So having this branch in Wiki page will remind us.
>>> >
>>> >
>>> > Best Regards
>>> >
>>> > - Original Message -
>>> > From: "Sendoro Juma" 
>>> > To: "dev" 
>>> > Cc: "robertjakech Jakech" 
>>> > Sent: Wednesday, February 14, 2018 1:38:01 PM
>>> > Subject: Re: Planning Apache Fineract 1.2 Release
>>> >
>>> > Hello Ed,
>>> >
>>> > +1 on all mentioned!
>>> >
>>> > I would propose additional point which you have kind of mention
>>> already on API Swagger it, but just as emphasize
>>> >
>>> > - APIs related issues/Enhancements that has been discovered by Mobile
>>> or Web Client Application side.
>>> >
>>> > This is so,  because we might take longer in addressing should known
>>> from client application side by juts because of missing visibility;
>>> > So having this branch in Wiki page will remind us.
>>> >
>>> >
>>> > Best Regards
>>> > Sendoro
>>> >
>>> >
>>> >
>>> > - Original Message -
>>> > From: "Ed Cable" 
>>> > To: "dev" , "robertjakech Jakech" <
>>> robertjak...@gmail.com>
>>> > Sent: Wednesday, February 14, 2018 9:41:07 AM
>>> > Subject: Planning Apache Fineract 1.2 Release
>>> >
>>> > That is a great suggestion Phil and of course any synchronous meeting
>>> would
>>> > only complement the discussion on the list and 

Re: Mifos Payment Gateway

[Antony Omeri]

Hi Ed,

At this point:
- I have migrated to Actvemq
- also handled incoming payments,
- done with adding infrastructure for outgoing payment.


The only thing remaining is developing UI and also a way to integrate to
accounting.
We also need enough testing. Incase of questions am available online

Kind Regard


On 8 Mar 2018 19:58, "Ed Cable"  wrote:

Antony,

In lieu of a meeting, could you update the community on the progress of
your code - when it's at a point to be merged, we'd like to get it merged
in and then be able to create corresponding tickets for others to continue
work in the near term and then also scope out additional tickets that could
comprise a GSOC project.

Steve - if I give you the proper karma, do you want to work with Antony and
Vladimir to create the appropriate tickets on JIRA?

Ed

On Thu, Mar 8, 2018 at 8:54 AM, Ed Cable  wrote:

> Thank you for the suggestion Myrle. Provided Steve is fine with it we can
> attempt to gather some feedback asynchronously; however we didn't get any
> responses from his questions from a month back but I will put more
> structure around those questions and try to get those that would have
> otherwise been participating on the call to discuss this across the list.
>
> If that doesn't yield much participation we will carry out a meeting and
> will as always share notes and a recording of said meeting.
>
> Ed
>
> On Thu, Mar 8, 2018 at 2:27 AM, Myrle Krantz  wrote:
>
>> Hey Ed,
>>
>> Would it be possible to discuss this on the list rather than making a
>> meeting?  You have specific questions you want to approach, you can
>> start by creating a ticket or tickets with Steve's suggested
>> sub-tasks, and then ask for feedback on the mailing list.
>>
>> This way people can participate no matter where they are in the world,
>> no matter what their working schedule is, and no matter how good their
>> internet connections are.  And you don't have to wait till Friday to
>> start.
>>
>> This is called asynchronous communication.  Here's a good blog post on it.
>> http://stormyscorner.com/2015/01/7-reasons-asynchronous-comm
>> unication-is-better-than-synchronous-communication-in-open-source.html
>>
>> Best Regards,
>> Myrle
>>
>>
>> On Wed, Mar 7, 2018 at 11:49 PM, Ed Cable  wrote:
>> > Thank you Steve for your thorough review. Apologies for the delay. I
>> wanted
>> > to get the payment gateway group together for another call so we can
>> > identify the best path forward in the four areas you specified, check
>> in on
>> > the progress Antony has made with his code and how we can incorporate
>> > Vladimir's data model. I also want to discuss if we should try to scope
>> out
>> > another project for GSOC centered around this - I think we have the
>> needed
>> > clarity now but wanted to ship somethign to the community prior to after
>> > this summer. Perhaps we could aim for an alpha version prior to GSOC and
>> > have the GSOC student work on the beta.
>> >
>> > Would this Friday at 1400GMT work for everyone?
>> >
>> > We can use Hangouts Meet for the call. Folks can join through:
>> > https://meet.google.com/ajy-twnd-irs
>> >
>> > On Wed, Jan 31, 2018 at 10:59 AM, Steve Conrad 
>> wrote:
>> >
>> >> Hi everyone -
>> >>
>> >> I have been spending some time over the past few weeks trying to
>> understand
>> >> the current status of the Mifos Payment Gateway and determine what
>> things
>> >> still need to be done. I wanted to summarize my understanding of where
>> the
>> >> gateway is at.
>> >>
>> >> I spoke with Avik to talk through the requirements and what work has
>> been
>> >> done so far. Vladimir Fomene worked to develop a data model and some
>> basic
>> >> functionality around inbound (loan repayments) and outbound
>> (disbursements)
>> >> transactions. At the same time, Antony Omeri was developing a parallel
>> >> model and platform.Over the past couple of months Antony has developed
>> much
>> >> of the core functionality and integrated it into the Fineract platform,
>> >> including using ActiveMQ for messaging.
>> >>
>> >> You can see a demo here of Antony's work. More functionality has been
>> >> implemented since this was recorded, including porting from RabbitMQ to
>> >> ActiveMQ
>> >> https://www.youtube.com/watch?time_continue=824=xqWIveT57vo
>> >>
>> >> And the repo is here:
>> >> https://github.com/OmexIT/fineract
>> >>
>> >> It seems to me that the best course forward is to continue to build on
>> >> Antony's platform. However, there are elements of Vladimir's data model
>> >> that I think we should consider integrating into Antony's platform -
>> >> particularly the ability to configure connections between MFIs and
>> >> MMPs/aggregators. We also need to think through functionality for error
>> >> handling and rolling back transactions. Beyond that, there are
>> additional
>> >> use cases around batch disbursals, reconciliation, etc.
>> >>

Re: Architecture Proposal | Fineract CN SMS & Email Notifications

[Rahul Goel]

Confluence Id : rahul.usi...@gmail.com

On Thu, Mar 8, 2018 at 4:18 PM, Myrle Krantz  wrote:

> Rahul,
>
> I think this is an excellent proposal.  Might it make sense to begin a
> new area in confluence to begin work in a more content-managed manner?
>
> If you have a confluence id, let me know what it is, and I'll give you
> permissions, and point you to where it belongs in the current
> confluence structure.
>
> Best Regards,
> Myrle
>
>
> On Thu, Mar 8, 2018 at 6:43 AM, Rahul Goel  wrote:
> > Hi
> >
> > I would like to propose my idea for implementation for *SMS & Email
> > Notifications Service*.
> >
> > *As per my current understanding :*
> > This single service is responsible for preparing and delivery of
> SMS/Email.
> > MFI staff can enable notifications which member chooses when creating
> their
> > account. Apart from this, this service will contain integrations with
> > third-party like Twilio.
> > Basically this service will be responsible for campaigns, delivery of
> > Notifications and vendor integrations.
> >
> > *What I propose :*
> >
> > We should break this service into further smaller microservices as
> follows:
> >
> >1. *Prepare-Notification-Service*
> >   - This service will listen to different events and will act
> >   accordingly, gathering information from other microservices such as
> >   accounting, office, customer etc for data and validations
> > purposes and will
> >   decide which set of users to send notification, thereby selection
> >   corresponding notification template  and then sending request
> either
> >   single, bulk API of conveyor service or publish to specific queues
> whose
> >   consumer will be again the conveyor service.
> >   - In case of campaigns, this service will filter out the users to
> >   whom the campaign is to be targeted, preparing all the other
> relevant
> >   information required for campaign handling and in the end for
> >   notifications, it will talk to conveyor service
> >2. *Conveyor-Service*
> >   - As the name suggests, this service will act as a conveyor only.
> It
> >   will talk to template service(talked about this below) for
> sms/email
> >   notification final content.
> >   - It will contain integration with third party vendors like Twilio.
> >   - If in future we consider PUSH Notifications for desktop/mobile
> >   devices, it will integrate that too.
> >   - It will control notification logs like whether an EMAIL/SMS was
> >   delivered or not, implement retry mechanism if required.
> >   - It will control which vendor to use for communication purposes.
> If
> >   for example one vendor is down for some reason, this service
> > will redirect
> >   all notifications request to some other vendor available at that
> time
> >   - It can be scaled independently if required.
> >   - This service basically deals with actual sending of the
> >   notifications.
> >3. *Template-Service*
> >   - As the name suggests this service will be responsible for
> SMS/EMAIL
> >   templating.
> >   - It will talk to only conveyor-service
> >   - It will contain basic templates in db and will return final
> >   prepared template, For example
> >  - pre-defined template is:
> >  *Hi {{userName}}, your account No {{accountNumber}} has been
> >  debited with {{currencyCode}} {{amount}}.*
> >  - It will return: *Hi Rahul, your account No 123456789 has been
> >  debited with INR 1000.*
> >   - Conveyor-service will provide provide relevant payload and
> >   templateId as received from notification service or directly
> through API.
> >   - The final template prepared by this service will be used by
> >   conveyor-service to send the desired notification.
> >   - If we want to change the template of any type of notification in
> >   future then that would be possible through this service APIs
> without
> >   affecting any other service or code.
> >
> > I would like to hear community member's thoughts and viewpoints on this
> > proposal. I am open to all kind of suggestions.
> >
> >
> > --
> > RAHUL GOEL
>



-- 
RAHUL GOEL
+91-9873124753

Re: Mifos Payment Gateway

[Ed Cable]

Antony,

In lieu of a meeting, could you update the community on the progress of
your code - when it's at a point to be merged, we'd like to get it merged
in and then be able to create corresponding tickets for others to continue
work in the near term and then also scope out additional tickets that could
comprise a GSOC project.

Steve - if I give you the proper karma, do you want to work with Antony and
Vladimir to create the appropriate tickets on JIRA?

Ed

On Thu, Mar 8, 2018 at 8:54 AM, Ed Cable  wrote:

> Thank you for the suggestion Myrle. Provided Steve is fine with it we can
> attempt to gather some feedback asynchronously; however we didn't get any
> responses from his questions from a month back but I will put more
> structure around those questions and try to get those that would have
> otherwise been participating on the call to discuss this across the list.
>
> If that doesn't yield much participation we will carry out a meeting and
> will as always share notes and a recording of said meeting.
>
> Ed
>
> On Thu, Mar 8, 2018 at 2:27 AM, Myrle Krantz  wrote:
>
>> Hey Ed,
>>
>> Would it be possible to discuss this on the list rather than making a
>> meeting?  You have specific questions you want to approach, you can
>> start by creating a ticket or tickets with Steve's suggested
>> sub-tasks, and then ask for feedback on the mailing list.
>>
>> This way people can participate no matter where they are in the world,
>> no matter what their working schedule is, and no matter how good their
>> internet connections are.  And you don't have to wait till Friday to
>> start.
>>
>> This is called asynchronous communication.  Here's a good blog post on it.
>> http://stormyscorner.com/2015/01/7-reasons-asynchronous-comm
>> unication-is-better-than-synchronous-communication-in-open-source.html
>>
>> Best Regards,
>> Myrle
>>
>> On Wed, Mar 7, 2018 at 11:49 PM, Ed Cable  wrote:
>> > Thank you Steve for your thorough review. Apologies for the delay. I
>> wanted
>> > to get the payment gateway group together for another call so we can
>> > identify the best path forward in the four areas you specified, check
>> in on
>> > the progress Antony has made with his code and how we can incorporate
>> > Vladimir's data model. I also want to discuss if we should try to scope
>> out
>> > another project for GSOC centered around this - I think we have the
>> needed
>> > clarity now but wanted to ship somethign to the community prior to after
>> > this summer. Perhaps we could aim for an alpha version prior to GSOC and
>> > have the GSOC student work on the beta.
>> >
>> > Would this Friday at 1400GMT work for everyone?
>> >
>> > We can use Hangouts Meet for the call. Folks can join through:
>> > https://meet.google.com/ajy-twnd-irs
>> >
>> > On Wed, Jan 31, 2018 at 10:59 AM, Steve Conrad 
>> wrote:
>> >
>> >> Hi everyone -
>> >>
>> >> I have been spending some time over the past few weeks trying to
>> understand
>> >> the current status of the Mifos Payment Gateway and determine what
>> things
>> >> still need to be done. I wanted to summarize my understanding of where
>> the
>> >> gateway is at.
>> >>
>> >> I spoke with Avik to talk through the requirements and what work has
>> been
>> >> done so far. Vladimir Fomene worked to develop a data model and some
>> basic
>> >> functionality around inbound (loan repayments) and outbound
>> (disbursements)
>> >> transactions. At the same time, Antony Omeri was developing a parallel
>> >> model and platform.Over the past couple of months Antony has developed
>> much
>> >> of the core functionality and integrated it into the Fineract platform,
>> >> including using ActiveMQ for messaging.
>> >>
>> >> You can see a demo here of Antony's work. More functionality has been
>> >> implemented since this was recorded, including porting from RabbitMQ to
>> >> ActiveMQ
>> >> https://www.youtube.com/watch?time_continue=824=xqWIveT57vo
>> >>
>> >> And the repo is here:
>> >> https://github.com/OmexIT/fineract
>> >>
>> >> It seems to me that the best course forward is to continue to build on
>> >> Antony's platform. However, there are elements of Vladimir's data model
>> >> that I think we should consider integrating into Antony's platform -
>> >> particularly the ability to configure connections between MFIs and
>> >> MMPs/aggregators. We also need to think through functionality for error
>> >> handling and rolling back transactions. Beyond that, there are
>> additional
>> >> use cases around batch disbursals, reconciliation, etc.
>> >>
>> >> If there are developers who are interested in working on bringing this
>> >> project to completion, I see at least 4 areas that need work:
>> >>1) Expanding the schema to allow configuration parameters between
>> an MFI
>> >> and MMP (the API credentials, etc for a particular MFI connection to a
>> >> provider/aggregator)
>> >>2) Implementing a couple of 

Re: Mifos Payment Gateway

[Ed Cable]

Thank you for the suggestion Myrle. Provided Steve is fine with it we can
attempt to gather some feedback asynchronously; however we didn't get any
responses from his questions from a month back but I will put more
structure around those questions and try to get those that would have
otherwise been participating on the call to discuss this across the list.

If that doesn't yield much participation we will carry out a meeting and
will as always share notes and a recording of said meeting.

Ed

On Thu, Mar 8, 2018 at 2:27 AM, Myrle Krantz  wrote:

> Hey Ed,
>
> Would it be possible to discuss this on the list rather than making a
> meeting?  You have specific questions you want to approach, you can
> start by creating a ticket or tickets with Steve's suggested
> sub-tasks, and then ask for feedback on the mailing list.
>
> This way people can participate no matter where they are in the world,
> no matter what their working schedule is, and no matter how good their
> internet connections are.  And you don't have to wait till Friday to
> start.
>
> This is called asynchronous communication.  Here's a good blog post on it.
> http://stormyscorner.com/2015/01/7-reasons-asynchronous-
> communication-is-better-than-synchronous-communication-in-open-source.html
>
> Best Regards,
> Myrle
>
> On Wed, Mar 7, 2018 at 11:49 PM, Ed Cable  wrote:
> > Thank you Steve for your thorough review. Apologies for the delay. I
> wanted
> > to get the payment gateway group together for another call so we can
> > identify the best path forward in the four areas you specified, check in
> on
> > the progress Antony has made with his code and how we can incorporate
> > Vladimir's data model. I also want to discuss if we should try to scope
> out
> > another project for GSOC centered around this - I think we have the
> needed
> > clarity now but wanted to ship somethign to the community prior to after
> > this summer. Perhaps we could aim for an alpha version prior to GSOC and
> > have the GSOC student work on the beta.
> >
> > Would this Friday at 1400GMT work for everyone?
> >
> > We can use Hangouts Meet for the call. Folks can join through:
> > https://meet.google.com/ajy-twnd-irs
> >
> > On Wed, Jan 31, 2018 at 10:59 AM, Steve Conrad 
> wrote:
> >
> >> Hi everyone -
> >>
> >> I have been spending some time over the past few weeks trying to
> understand
> >> the current status of the Mifos Payment Gateway and determine what
> things
> >> still need to be done. I wanted to summarize my understanding of where
> the
> >> gateway is at.
> >>
> >> I spoke with Avik to talk through the requirements and what work has
> been
> >> done so far. Vladimir Fomene worked to develop a data model and some
> basic
> >> functionality around inbound (loan repayments) and outbound
> (disbursements)
> >> transactions. At the same time, Antony Omeri was developing a parallel
> >> model and platform.Over the past couple of months Antony has developed
> much
> >> of the core functionality and integrated it into the Fineract platform,
> >> including using ActiveMQ for messaging.
> >>
> >> You can see a demo here of Antony's work. More functionality has been
> >> implemented since this was recorded, including porting from RabbitMQ to
> >> ActiveMQ
> >> https://www.youtube.com/watch?time_continue=824=xqWIveT57vo
> >>
> >> And the repo is here:
> >> https://github.com/OmexIT/fineract
> >>
> >> It seems to me that the best course forward is to continue to build on
> >> Antony's platform. However, there are elements of Vladimir's data model
> >> that I think we should consider integrating into Antony's platform -
> >> particularly the ability to configure connections between MFIs and
> >> MMPs/aggregators. We also need to think through functionality for error
> >> handling and rolling back transactions. Beyond that, there are
> additional
> >> use cases around batch disbursals, reconciliation, etc.
> >>
> >> If there are developers who are interested in working on bringing this
> >> project to completion, I see at least 4 areas that need work:
> >>1) Expanding the schema to allow configuration parameters between an
> MFI
> >> and MMP (the API credentials, etc for a particular MFI connection to a
> >> provider/aggregator)
> >>2) Implementing a couple of specific payment providers to prove out
> the
> >> functionality - possibly Beyonic and something like RazorPay
> >>3) Implementing some kind of UI that we can use as a test platform -
> >> testing disbursals and repayments
> >>4) Implementing use cases that have been defined but not yet
> developed -
> >> batch disbursals, reconciliation, etc.
> >>
> >> Thanks,
> >> Steve
> >>
> >
> >
> >
> > --
> > *Ed Cable*
> > President/CEO, Mifos Initiative
> > edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
> > <(484)%20477-8649>
> >
> > *Collectively Creating a World of 3 Billion Maries | *http://mifos.org
> > 

Re: [Mifos-developer] GSOC 2018

[Myrle Krantz]

Hey Piyadassi,

Thanks for your persistence.

If you want to pull just the one service, go into it's directory, set
up a git remote to point to the apache repository, and pull from that
upstream.

For example:
% cd fineract-cn-service-starter
% git remote --verbose

Is there a remote pointing to apache?  If not:
% git remote add upstream https://github.com/apache/fineract-cn-service-starter

% git pull upstream develop
% ./gradlew publishToMavenLocal
% cd ../fineract-cn-demo-server
% ./gradlew assemble

Best regards,
Myrle


On Thu, Mar 8, 2018 at 12:30 PM, Piyadassi Shakya
 wrote:
> Hi Myrle,
> Don't we need the initial-setup.sh file for this method? or how do we
> execute it??
>
> With Regards
> Piyadassi
>
> On Thu, Mar 8, 2018 at 4:30 PM, Myrle Krantz  wrote:
>
>> Piyadassi, Rajan,
>>
>> I've merged the PR from Viswa that Mark pointed out (Many thanks to
>> both of you.  : o)
>>
>> So try repulling repo: https://github.com/apache/
>> fineract-cn-service-starter
>>
>> Best Regards,
>> Myrle
>>
>> On Thu, Mar 8, 2018 at 10:51 AM, Piyadassi Shakya
>>  wrote:
>> > Hi Rajan
>> > did you build all the 33 repository or how did it work? I have not been
>> > able to run the demo-server as well.
>>

Re: [Mifos-developer] GSOC 2018

[Piyadassi Shakya]

Hi Myrle,
Don't we need the initial-setup.sh file for this method? or how do we
execute it??

With Regards
Piyadassi

On Thu, Mar 8, 2018 at 4:30 PM, Myrle Krantz  wrote:

> Piyadassi, Rajan,
>
> I've merged the PR from Viswa that Mark pointed out (Many thanks to
> both of you.  : o)
>
> So try repulling repo: https://github.com/apache/
> fineract-cn-service-starter
>
> Best Regards,
> Myrle
>
> On Thu, Mar 8, 2018 at 10:51 AM, Piyadassi Shakya
>  wrote:
> > Hi Rajan
> > did you build all the 33 repository or how did it work? I have not been
> > able to run the demo-server as well.
>

Re: [Mifos-developer] GSOC 2018

[Ippez Robert]

Hi Mark,
I don't how it happened now but some how i was able to run the demo and web
app successfully. I also logged in with success.

Thanks
Regards

Ippez Robert

On Thu, Mar 8, 2018 at 1:45 PM, Myrle Krantz  wrote:

> Piyadassi, Rajan,
>
> I've merged the PR from Viswa that Mark pointed out (Many thanks to
> both of you.  : o)
>
> So try repulling repo: https://github.com/apache/
> fineract-cn-service-starter
>
> Best Regards,
> Myrle
>
> On Thu, Mar 8, 2018 at 10:51 AM, Piyadassi Shakya
>  wrote:
> > Hi Rajan
> > did you build all the 33 repository or how did it work? I have not been
> > able to run the demo-server as well.
>



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

Re: Architecture Proposal | Fineract CN SMS & Email Notifications

[Myrle Krantz]

Rahul,

I think this is an excellent proposal.  Might it make sense to begin a
new area in confluence to begin work in a more content-managed manner?

If you have a confluence id, let me know what it is, and I'll give you
permissions, and point you to where it belongs in the current
confluence structure.

Best Regards,
Myrle


On Thu, Mar 8, 2018 at 6:43 AM, Rahul Goel  wrote:
> Hi
>
> I would like to propose my idea for implementation for *SMS & Email
> Notifications Service*.
>
> *As per my current understanding :*
> This single service is responsible for preparing and delivery of SMS/Email.
> MFI staff can enable notifications which member chooses when creating their
> account. Apart from this, this service will contain integrations with
> third-party like Twilio.
> Basically this service will be responsible for campaigns, delivery of
> Notifications and vendor integrations.
>
> *What I propose :*
>
> We should break this service into further smaller microservices as follows:
>
>1. *Prepare-Notification-Service*
>   - This service will listen to different events and will act
>   accordingly, gathering information from other microservices such as
>   accounting, office, customer etc for data and validations
> purposes and will
>   decide which set of users to send notification, thereby selection
>   corresponding notification template  and then sending request either
>   single, bulk API of conveyor service or publish to specific queues whose
>   consumer will be again the conveyor service.
>   - In case of campaigns, this service will filter out the users to
>   whom the campaign is to be targeted, preparing all the other relevant
>   information required for campaign handling and in the end for
>   notifications, it will talk to conveyor service
>2. *Conveyor-Service*
>   - As the name suggests, this service will act as a conveyor only. It
>   will talk to template service(talked about this below) for sms/email
>   notification final content.
>   - It will contain integration with third party vendors like Twilio.
>   - If in future we consider PUSH Notifications for desktop/mobile
>   devices, it will integrate that too.
>   - It will control notification logs like whether an EMAIL/SMS was
>   delivered or not, implement retry mechanism if required.
>   - It will control which vendor to use for communication purposes. If
>   for example one vendor is down for some reason, this service
> will redirect
>   all notifications request to some other vendor available at that time
>   - It can be scaled independently if required.
>   - This service basically deals with actual sending of the
>   notifications.
>3. *Template-Service*
>   - As the name suggests this service will be responsible for SMS/EMAIL
>   templating.
>   - It will talk to only conveyor-service
>   - It will contain basic templates in db and will return final
>   prepared template, For example
>  - pre-defined template is:
>  *Hi {{userName}}, your account No {{accountNumber}} has been
>  debited with {{currencyCode}} {{amount}}.*
>  - It will return: *Hi Rahul, your account No 123456789 has been
>  debited with INR 1000.*
>   - Conveyor-service will provide provide relevant payload and
>   templateId as received from notification service or directly through 
> API.
>   - The final template prepared by this service will be used by
>   conveyor-service to send the desired notification.
>   - If we want to change the template of any type of notification in
>   future then that would be possible through this service APIs without
>   affecting any other service or code.
>
> I would like to hear community member's thoughts and viewpoints on this
> proposal. I am open to all kind of suggestions.
>
>
> --
> RAHUL GOEL

Re: [Mifos-developer] GSOC 2018

[Myrle Krantz]

Piyadassi, Rajan,

I've merged the PR from Viswa that Mark pointed out (Many thanks to
both of you.  : o)

So try repulling repo: https://github.com/apache/fineract-cn-service-starter

Best Regards,
Myrle

On Thu, Mar 8, 2018 at 10:51 AM, Piyadassi Shakya
 wrote:
> Hi Rajan
> did you build all the 33 repository or how did it work? I have not been
> able to run the demo-server as well.

Re: Mifos Payment Gateway

[Myrle Krantz]

Hey Ed,

Would it be possible to discuss this on the list rather than making a
meeting?  You have specific questions you want to approach, you can
start by creating a ticket or tickets with Steve's suggested
sub-tasks, and then ask for feedback on the mailing list.

This way people can participate no matter where they are in the world,
no matter what their working schedule is, and no matter how good their
internet connections are.  And you don't have to wait till Friday to
start.

This is called asynchronous communication.  Here's a good blog post on it.
http://stormyscorner.com/2015/01/7-reasons-asynchronous-communication-is-better-than-synchronous-communication-in-open-source.html

Best Regards,
Myrle

On Wed, Mar 7, 2018 at 11:49 PM, Ed Cable  wrote:
> Thank you Steve for your thorough review. Apologies for the delay. I wanted
> to get the payment gateway group together for another call so we can
> identify the best path forward in the four areas you specified, check in on
> the progress Antony has made with his code and how we can incorporate
> Vladimir's data model. I also want to discuss if we should try to scope out
> another project for GSOC centered around this - I think we have the needed
> clarity now but wanted to ship somethign to the community prior to after
> this summer. Perhaps we could aim for an alpha version prior to GSOC and
> have the GSOC student work on the beta.
>
> Would this Friday at 1400GMT work for everyone?
>
> We can use Hangouts Meet for the call. Folks can join through:
> https://meet.google.com/ajy-twnd-irs
>
> On Wed, Jan 31, 2018 at 10:59 AM, Steve Conrad  wrote:
>
>> Hi everyone -
>>
>> I have been spending some time over the past few weeks trying to understand
>> the current status of the Mifos Payment Gateway and determine what things
>> still need to be done. I wanted to summarize my understanding of where the
>> gateway is at.
>>
>> I spoke with Avik to talk through the requirements and what work has been
>> done so far. Vladimir Fomene worked to develop a data model and some basic
>> functionality around inbound (loan repayments) and outbound (disbursements)
>> transactions. At the same time, Antony Omeri was developing a parallel
>> model and platform.Over the past couple of months Antony has developed much
>> of the core functionality and integrated it into the Fineract platform,
>> including using ActiveMQ for messaging.
>>
>> You can see a demo here of Antony's work. More functionality has been
>> implemented since this was recorded, including porting from RabbitMQ to
>> ActiveMQ
>> https://www.youtube.com/watch?time_continue=824=xqWIveT57vo
>>
>> And the repo is here:
>> https://github.com/OmexIT/fineract
>>
>> It seems to me that the best course forward is to continue to build on
>> Antony's platform. However, there are elements of Vladimir's data model
>> that I think we should consider integrating into Antony's platform -
>> particularly the ability to configure connections between MFIs and
>> MMPs/aggregators. We also need to think through functionality for error
>> handling and rolling back transactions. Beyond that, there are additional
>> use cases around batch disbursals, reconciliation, etc.
>>
>> If there are developers who are interested in working on bringing this
>> project to completion, I see at least 4 areas that need work:
>>1) Expanding the schema to allow configuration parameters between an MFI
>> and MMP (the API credentials, etc for a particular MFI connection to a
>> provider/aggregator)
>>2) Implementing a couple of specific payment providers to prove out the
>> functionality - possibly Beyonic and something like RazorPay
>>3) Implementing some kind of UI that we can use as a test platform -
>> testing disbursals and repayments
>>4) Implementing use cases that have been defined but not yet developed -
>> batch disbursals, reconciliation, etc.
>>
>> Thanks,
>> Steve
>>
>
>
>
> --
> *Ed Cable*
> President/CEO, Mifos Initiative
> edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
> <(484)%20477-8649>
>
> *Collectively Creating a World of 3 Billion Maries | *http://mifos.org
>   

Re: [Mifos-developer] GSOC 2018

[Piyadassi Shakya]

Hi Rajan
did you build all the 33 repository or how did it work? I have not been
able to run the demo-server as well.



With Regards
Piyadassi


On Tue, Mar 6, 2018 at 5:02 PM, Rajan Maurya 
wrote:

> Hi Myrle,
>
> Myrle, Like you know we don't have any instance to test the Fineract-CN
> API, that's why I ended up to build the Fineract-CN locally for updating
> idealist.
> I cloned the repos and build the web app successfully
> I followed this guideline https://cwiki.apache
> .org/confluence/display/FINERACT/How+To+Build+Apache+Fineract+CN
>
> Issue: I am unable to login into the web app with the given credentials in
> the guide.
>
>
>
> ‌
>
> On Mon, Mar 5, 2018 at 3:37 PM, Myrle Krantz  wrote:
>
>> Hey Ed,
>>
>> Can you please move the Fineract CN content, including the Fineract CN
>> mobile content to Apache infrastructure.  In this case, I'd recommend
>> appropriately tagged Jira tickets.  Also, I assume you know Rajan is
>> going to do that (and the same with Avik, and Gaurav), because he
>> agreed to it to you somewhere other than the public list?  Please move
>> communication like this to the public list.
>>
>> I assume that Rajan will be registering to mentor with Apache, now
>> that he's been invited to be a committer?  Maybe I'm a bit early,
>> since Rajan hasn't accepted the committer status yet. ; o) Rajan, if
>> you need any assistance with that process, feel free to ask...
>>
>> Best Regards,
>> Myrle Krantz
>> PMC Member, Apache Fineract
>>
>>
>> On Mon, Mar 5, 2018 at 9:07 AM, Ed Cable  wrote:
>> > Hello Aksh,
>> >
>> > Rajan is going to be updating the description soon with prospective
>> tasks.
>> > Sorry for that delay.
>> >
>> > Ed
>> >
>> >
>> >
>> > On Sat, Mar 3, 2018 at 4:55 AM, Aksh Gautam  wrote:
>> >
>> >> Hey,
>> >>
>> >> The description of Fineract CN Mobile 2.0 seems to be missing on the
>> PAGE
>> >> > /Google+Summer+of+Code+2018+Ideas#GoogleSummerofCode2018Idea
>> s-FineractCNMobile2.0>
>> >> It would be helpful if description could be updated.
>> >>
>> >> PS: I hope this is not a duplicate email. Since the previous mail
>> failed
>> >> to deliver.
>> >>
>> >> Thanks
>> >> Aksh Gautam
>> >>
>> >> 
>> >> --
>> >> Check out the vibrant tech community on one of the world's most
>> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >> Mifos-developer mailing list
>> >> mifos-develo...@lists.sourceforge.net
>> >> Unsubscribe or change settings at:
>> >> https://lists.sourceforge.net/lists/listinfo/mifos-developer
>> >>
>> >
>> >
>> >
>> > --
>> > *Ed Cable*
>> > President/CEO, Mifos Initiative
>> > edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
>> <(484)%20477-8649>
>> >
>> > *Collectively Creating a World of 3 Billion Maries | *http://mifos.org
>> >   
>>
>
>
>
> --
> *Thanks*
> *Namaste*
>
> Rajan Maurya
> Contact Number : +91 9015090523 <+91%2090150%2090523>
> Github : @Github/therajanmaurya ,
> LinkedIn: @LinkedIn/therajanmaurya
> 
>

Re: [Mifos-developer] GSOC 2018

[Myrle Krantz]

Hey Ed,

Answers inline.

On Tue, Mar 6, 2018 at 7:47 PM, Ed Cable  wrote:
> Myrle,
>
> Thanks for your feedback. For all tasks related to either Fineract CN or
> Fineract that are listed on the ideas page for Mifos, I'll make sure they
> have corresponding issues on the Apache JIRA Infrastructure. I believe that
> is now the case for the Fineract CN tickets but some of them require
> additional detail. Conversation with Rajan about updating the task wasn't
> anything that explicitly occurred off-list. Just in general we've been
> working to update the tasks and Rajan has been waiting to do the same until
> he has some free cycles.

Thank you Ed.  That is exactly what I was looking or.

> As I've done with group loan support, data migration, etc. and a couple
> other forthcoming project areas I've tried to initiate public discussion on
> the lists but haven't yielded much feedback.

That is a problem.  But it's better than not putting it on the list at all.

Do you get more feedback via other methods?

> I'm not sure if Rajan will be mentoring under Apache or Mifos. For now
> though I'm driving all ideas related to Fineract and/or Mifos X and the
> enabling support we're providing to prospective students through the Mifos
> Initiative ideas page because we have better structure there for the
> selection process with a better means to target students, an evaluation
> process we've honed over the years and during the program itself we have
> our formal protocols and procedures for GSOC that work well for us.
>
> I am ensuring though that any of our mentors who are Apache committers and
> could potentially be a mentor under Apache be properly registered there as
> well in the case that a student might apply for one of the projects through
> Apache.

Excellent.

Best Regards,
Myrle

Re: [Mifos-developer] GSOC 2018

[Mark van Veen]

I am afraid but I can't see from the log you sent what the issue is. The
message "Parent ledger 1000 not found" should not prevent the demo server
from startup.

Can you share your log folder under "demo-server/build/libs/logs"?

On Wed, Mar 7, 2018 at 2:56 PM Ippez Robert  wrote:

> Hi Mark,
>
> That was the problem. But now it runs up-to some point where it throws
> errors as below due to *Parent ledger 1000 not found. *and it then
> terminate the process. Any solution to fix this?
>
> *16:52:14.223 [qtp726408598-22] INFO  i.m.c.l.c.ServiceExceptionFilter -
> Responding with a service error ServiceError{code=404, message='Parent
> ledger 1000 not found.'}*
> *E*
> *Time: 1,538.137*
> *There was 1 failure:*
> *1) startDevServer(io.mifos.dev.ServiceRunner)*
> *io.mifos.accounting.api.v1.client.LedgerNotFoundException*
> *at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)*
> *at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
> Source)*
> *at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)*
> *at java.lang.reflect.Constructor.newInstance(Unknown Source)*
> *at
>
> io.mifos.core.api.util.AnnotatedErrorDecoder.constructException(AnnotatedErrorDecoder.java:135)*
> *at
>
> io.mifos.core.api.util.AnnotatedErrorDecoder.lambda$null$1(AnnotatedErrorDecoder.java:61)*
> *at java.util.Optional.flatMap(Unknown Source)*
> *at
>
> io.mifos.core.api.util.AnnotatedErrorDecoder.lambda$decode$2(AnnotatedErrorDecoder.java:61)*
> *at java.util.stream.ReferencePipeline$3$1.accept(Unknown Source)*
> *at java.util.stream.ReferencePipeline$2$1.accept(Unknown Source)*
> *at java.util.Spliterators$ArraySpliterator.tryAdvance(Unknown
> Source)*
> *at java.util.stream.ReferencePipeline.forEachWithCancel(Unknown
> Source)*
> *at java.util.stream.AbstractPipeline.copyIntoWithCancel(Unknown
> Source)*
> *at java.util.stream.AbstractPipeline.copyInto(Unknown Source)*
> *at java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown
> Source)*
> *at java.util.stream.FindOps$FindOp.evaluateSequential(Unknown
> Source)*
> *at java.util.stream.AbstractPipeline.evaluate(Unknown Source)*
> *at java.util.stream.ReferencePipeline.findAny(Unknown Source)*
> *at
>
> io.mifos.core.api.util.AnnotatedErrorDecoder.decode(AnnotatedErrorDecoder.java:63)*
> *at
>
> feign.SynchronousMethodHandler.executeAndDecode(SynchronousMethodHandler.java:138)*
> *at
> feign.SynchronousMethodHandler.invoke(SynchronousMethodHandler.java:76)*
> *at
>
> feign.ReflectiveFeign$FeignInvocationHandler.invoke(ReflectiveFeign.java:103)*
> *at com.sun.proxy.$Proxy214.addSubLedger(Unknown Source)*
> *at
>
> io.mifos.accounting.importer.LedgerImporter.createLedger(LedgerImporter.java:69)*
> *at java.util.ArrayList.forEach(Unknown Source)*
> *at
>
> io.mifos.accounting.importer.LedgerImporter.importCSV(LedgerImporter.java:60)*
> *at
> io.mifos.dev.ServiceRunner.createChartOfAccounts(ServiceRunner.java:461)*
> *at
>
> io.mifos.dev.ServiceRunner.provisionAppsViaSeshatForTenant(ServiceRunner.java:446)*
> *at
> io.mifos.dev.ServiceRunner.provisionAppsViaSeshat(ServiceRunner.java:358)*
> *at
> io.mifos.dev.ServiceRunner.startDevServer(ServiceRunner.java:260)*
> *at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)*
> *at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)*
> *at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> Source)*
> *at java.lang.reflect.Method.invoke(Unknown Source)*
> *at
>
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)*
> *at
>
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)*
> *at
>
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)*
> *at
>
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)*
> *at
>
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)*
> *at
>
> org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:75)*
> *at
>
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)*
> *at
>
> org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:86)*
> *at
>
> org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:84)*
> *at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)*
> *at
>
> org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:252)*
> *at
>
>