I'm cc'ing @Pranjal Goswami <pranjal.b.gosw...@gmail.com> who originally designed the notifications framework.
Here's one of the original design docs on the notification storage and topic subscription. https://docs.google.com/presentation/d/1jzqEQxxRYa1ZvN_SXLRwDgXBux1cb3_IMBWbdS7rRV0/edit?usp=sharing Once it's fully implemented, it will and has to date served as a foundational component to generating both staff and customer facing notifications which can be displayed in the Web UI as well as mobile apps. As a bit more background and context, I'm forwarding a previous thread from 2020 in which we were trying to extend the notifications framework to generate FCM notifications via mobile apps. ============================= Email from July 2020 Pranjal, Courage, Nazeer and others I'm responding on top of this thread as both Devansh and Shashank are blocked in trying to move forward with the portions of their projects related to consuming FCM notifications. From our previous meeting, we had somehow concluded that the PR at https://github.com/apache/fineract/pull/421 was for FCM notifications support but in talking with Nazeer it was only for SMS campaigns. Nazeer - are you able to clarify on that PR. If it doesn' have the support for FCM notifications, can we outline the work involved in providing server-side support to generate the FCM notifications. Thanks all. Once we come to more clarity i'll take this to the list. If a call is quickest way to tackle this, let's get one scheduled. Thanks, Ed On Fri, Jun 5, 2020 at 4:22 PM Ed Cable <edca...@mifos.org> wrote: Hi all, Just to follow up on the second leg of the meeting we had to discuss the notifications sub-system being used for the Request to Pay API for the mobile wallet as well as a general update about the mobile wallet use case in the near term to have it work in the new lab environment. https://us02web.zoom.us/rec/share/5-oyIZrd1mZLYNLutAL8avU5H9zPX6a8gClL-fEPyh5OYllEDFBX8_ENod_Zeup_?startTime=1591200315000 >From the discussion, it appears the current manner in which notifications are generated and stored in Fineract 1.x will work for the request to pay API. However we must ensure that the self-service users (which should be in the same users table but just denoted as "self-service") are subscribed to this topic to receive the notification. All students working on the customer-facing apps for Fineract 1.x, should familiarize themselves with the notifications system (see previous design and how it works) as the client-side integration should also be complete for mifos mobile and mobile wallet. If you have any questions, please share them publicly on the mifos and fineract dev list and discourse forum as it's a valuable discussion for community. @Ebenezer Graham <ebenezergraha...@gmail.com> can we grab some time to discuss integration with the Fineract CN notifications microservices. We identified some small action items to take to make the current mobile wallet work for the prior 2 Mojaloop use cases and soon the 3rd Mojaloop use case in our lab environment. We need to: 1) Provide Shivansh and Devansh with both the updated environment details of the Fineract, Payment Hub instances in the new lab environment as well as the updated API endpoints. 2) Confirm where the MSISDN is being stored as an additional attribute for Fineract. 3) Ensure that the Interop users/customers that are created in the Fineract instances have an associated self-service user account and to add these credentials to the lab environment Google sheet. https://docs.google.com/spreadsheets/d/1b8BRajrpNacFNEH6gGENDVWIGusLc0pGRd6MnKbqTKM/edit?usp=sharing Once the above is in place, we should be able to have the initial 2 mojaloop use cases of peer to peer transfer and payment via QR code work with actual authenticated self-service users (not just hard-coded JSON user data). On Tue, Jun 2, 2020 at 9:19 AM Ed Cable <edca...@mifos.org> wrote: Hi everyone, Thank you for those who were able to join, especially to Pranjal for joining short notice. We made some good progress in the discussion but will continue this conversation once Istvan can join during part of our call tomorrow that was scheduled for Open Banking fintech app requirements. Here's a summary of what we concluded and outstanding questions/next steps: *Fineract 1.x* - Creation and Storage of Notifications on Back-End - - Per the design of Pranjal and implementation by Courage and Adhiyan, the notifications subsystem for creating and storing notifications through the publisher/subscriber/topic model is complete and more recently has been updated by Nazeer to work with FCM messaging - - Slides on Design of Notification Subsystem: https://docs.google.com/presentation/d/1jzqEQxxRYa1ZvN_SXLRwDgXBux1cb3_IMBWbdS7rRV0/edit?usp=sharing - Link to PR updating notifications for Fineract - https://github.com/apache/fineract/pull/421 - Receiving notifications through channel apps - - Working for Community App - Works for Mifos Mobile and for Mobile Wallet - - PR for MIfos MObile for FCM Messaging - https://github.com/openMF/mifos-mobile/pull/1180 - Questions/Concerns - - Based on Pranjal's current understanding of Request to Pay use case, he believes for notifications like payment requests that are high priority, time-critical, and actionable, we should enhance notifications to generate and store them in a different manner than the current generic system for information updates - - Istvan, within Zeebe, how many times will we re-try sending out the payment request notification if the payer doesn't take action? - Would the flow be Mojaloop API to Connector in Payment Hub to Fineract and then to Channel? *Fineract CN* - Creation and Storage of Notifications on Back-End - - Separate notifications framework created by @Ebenezer Graham <ebenezergraha...@gmail.com> who i'm looping into this discussion. *Other Questions* - *Mobile Wallet Authentication via Self-Service Users* - - Shivansh shared that for the integration that he and Naman did last year to support the peer to peer and merchant proximity use cases that they had to this all with just hard-coded JSON users based on the 4 demo user accounts and that they weren't aware of how they would be able to actually authenticate via self-service users to initiate these transactions. - So we both need to for the interim, ensure we can support doing these transactions in the mobile wallet via self-service APIs but then once we've fully mapped the entire app to use Open Banking APIs, do the transacstions via that manner. - @Istvan Molnar <istvan.mol...@dpc.hu> for our demo web app which allowed a customer to scan a QR code and make payment to a merchant, I thought we were using self-service API, I guess that was only for a staff person that was acting like a customer. - - We need to have this transaction actually be supported from our self-service API (in interim) and then open banking API. - I'm glad this call flagged this as it's an important distinction that I didn't realize we weren't yet supporting because for our lab environment, the P2P and proximity payment are supposed to be customer-initiated scenarios, not staff ones. - *This all speaks to the importance and criticality of having our lab environment use the community-developed channel apps and not just reference demo apps as we need to try to closely model real-world scenarios.* Thanks, Ed On Mon, Jun 1, 2020 at 11:44 AM Ed Cable <edca...@mifos.org> wrote: Hi Mobile Wallet and Mobile Banking teams, As part of the ongoing work with supporting the Mojaloop request to pay API, we will finally get the opportunity to work more closely with the DPC team to incorporate our community-developed channel apps into the lab environment. Primarily, we need to be able to demonstrate the end to end scenario where notification generated by the payer needs is received by the payee so they can take action to initiate payment based on the request. I'm setting up a call with our mentors and interns for the mobile banking and mobile wallet apps to discuss a few of the following points with Istvan, Kristofz, and Zoltan: - What are the endpoints for the communications? - How are notifications being generated? In Fineract or in the app? - What form factor can notifications be received via? In app through FCM, via SMS? - How are channel apps invoking the credentials? I'm going to send out an invite for 1500GMT on Tuesday. Cheers, Ed On Wed, May 18, 2022, 08:10 Arnold Galovics <galovicsarn...@gmail.com> wrote: > Hi guys, > > Thanks for the feedback. I can only agree with you, we don't want to lose > features that are potentially used. > > I was probably not crystal clear when I mentioned the term "notification > topic". I was mainly referring to the "topic" and "topic_subscriber" tables > which are currently not exposed through APIs but only used for our internal > purpose. However, after spending some time on understanding what the > purpose was behind this, I figured out that these tables and their related > functionality is not even needed to maintain the completeness of our > feature set so I was able to replace it fairly easily and get rid of the > related code. > > I'm still polishing the PR, but you can look at it here: > https://github.com/apache/fineract/pull/2330 > > Just as a side note, these 2 tables are also used in conjunction with the > UI notifications (on the top of the UI) and I realized that the UI > notification feature is not even working without a running ActiveMQ broken > because the logic is buggy. > > I managed to fix that as well as part of the cleanup and I introduced a > new test-case to verify this logic. > > Summary: > - ~1500 less lines of unnecessary code > - A simplified notification implementation > - New test case to verify UI notifications > > Best, > Arnold > > > On Wed, May 18, 2022 at 5:02 PM James Dailey <jamespdai...@gmail.com> > wrote: > >> Yes, we have to be careful about removing things, that is probably an >> unspoken principle on this project as we don't know how it's being used. >> (unfortunately) >> However, if it makes sense from an architectural perspective to >> rationalize the notification and event handling frameworks, then I would >> suggest that we find a way to migrate this behavior. >> ... and wondering if this belongs in its own extension or outside >> component. >> >> It may be "half-implemented" but that doesn't mean it isn't being used. >> ;) >> >> >> On Wed, May 18, 2022 at 7:43 AM Bharath Gowda <bgo...@mifos.org> wrote: >> >>> Hi Arnold, >>> >>> I have some organizations using the notification feature effectively for >>> sanctioning or disbursing the loan accounts based on the notifications >>> which they receive. It is mainly useful when there are different levels of >>> approvals for the loan cycle. >>> >>> (user configuration document for this feature is here >>> <https://docs.mifos.org/mifosx/user-manual/for-administrators-mifos-x-platform/configure-notifications> >>> ) >>> >>> Regards, >>> Bharath >>> Lead Implementation Analyst | Mifos Initiative >>> Skype: live:cbharath4| Mobile: +91.7019635592 >>> http://mifos.org <http://facebook.com/mifos> >>> <http://www.twitter.com/mifos> >>> >>> >>> On Wed, May 18, 2022 at 3:29 PM Aleksandar Vidakovic < >>> chee...@monkeysintown.com> wrote: >>> >>>> ... thanks Adam... learned again. >>>> >>>> On Wed, May 18, 2022 at 10:28 AM Ádám Sághy <adamsa...@gmail.com> >>>> wrote: >>>> >>>>> Hi guys, >>>>> >>>>> So lets see what i know about this functionality: >>>>> >>>>> - The Fineract is the publisher and also a listener for the >>>>> Notification events. >>>>> >>>>> - Fineract is publishing notifications in the following situations: >>>>> "ACTIVATE_CLIENT" >>>>> "ACTIVATE_CENTER" >>>>> "ACTIVATE_GROUP" >>>>> "READ_SAVINGSACCOUNT" >>>>> "READ_DIVIDEND_SHAREPRODUCT" >>>>> "APPROVE_FIXEDDEPOSITACCOUNT" >>>>> "APPROVE_RECURRINGDEPOSITACCOUNT" >>>>> "ACTIVATE_FIXEDDEPOSITACCOUNT" >>>>> "ACTIVATE_RECURRINGDEPOSITACCOUNT >>>>> "ACTIVATE_SAVINGSACCOUNT" >>>>> "READ_SAVINGSACCOUNT" >>>>> "APPROVE_LOAN", >>>>> "DISBURSE_LOAN" >>>>> "READ_LOAN" >>>>> "READ_Rescheduled Loans" >>>>> "READ_LOAN" >>>>> "READ_LOANPRODUCT" >>>>> "APPROVE_SAVINGSACCOUNT" >>>>> "READ_SAVINGSACCOUNT" >>>>> "APPROVE_SHAREACCOUNT" >>>>> “ACTIVATE_SHAREACCOUNT” >>>>> >>>>> - There is a topic subsciption functionality also where appusers can >>>>> subscribe for events and they got notified when that event occured. >>>>> - When a user is created based on the roles, the fineract might >>>>> subscribe automatically for topics >>>>> >>>>> - Fineract listener are listening for these kind of events and when it >>>>> happens it will create a notification entry into the database for the >>>>> subscribed users. >>>>> - When a subscribed user logs into the Fineract, they will get the >>>>> notification (on the UI for example a popup). >>>>> >>>>> I hope it helps to visualize this functionality a little bit better >>>>> and decide on its future. >>>>> >>>>> Regards, >>>>> Adam >>>>> >>>>> On 18 May 2022, at 09:56, Aleksandar Vidakovic < >>>>> chee...@monkeysintown.com> wrote: >>>>> >>>>> ... other question: does it do anything? I'll have another look at it >>>>> today, but it seems non-functional. >>>>> >>>>> It's going to be hard to reach in general a consensus if people are >>>>> not participating... same argument could be made for introducing >>>>> Liquibase; >>>>> I'm sure that others invested time in Flyway, but we still replaced it. >>>>> >>>>> Just my 2 cents. >>>>> >>>>> On Wed, May 18, 2022 at 9:43 AM Awasum Yannick <awa...@apache.org> >>>>> wrote: >>>>> >>>>>> Hello Aleks and Arnold, >>>>>> >>>>>> I won't remove that feature given we don't know who may or may not be >>>>>> using it. >>>>>> >>>>>> There are people using Fineract who are not even on this dev list or >>>>>> participating in conversations. >>>>>> >>>>>> I would be careful with what I remove even if it looks unusable to me. >>>>>> >>>>>> On Wed, May 18, 2022, 02:11 Aleksandar Vidakovic < >>>>>> chee...@monkeysintown.com> wrote: >>>>>> >>>>>>> I would say: +1 >>>>>>> >>>>>>> On Tue, May 17, 2022 at 10:01 PM Arnold Galovics <arn...@apache.org> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi guys, >>>>>>>> >>>>>>>> I'm exploring the current event handling frameworks available in >>>>>>>> Fineract - Hooks, Business events and Notification events - and I was >>>>>>>> wondering if anybody is using the so called "topic subscriptions" in >>>>>>>> Fineract within the Notification events module. >>>>>>>> >>>>>>>> As far as I can tell, it's a half-complete implementation but I see >>>>>>>> that upon creating a new user and assigning it to an office, it >>>>>>>> automatically subscribes the user to a particular topic but the notion >>>>>>>> of >>>>>>>> "subscribing to a topic" doesn't really have any meaning at this point. >>>>>>>> >>>>>>>> If nobody is using the feature, I'll just remove it to get rid of >>>>>>>> some of the weight we've been carrying. >>>>>>>> >>>>>>>> Let me know. >>>>>>>> >>>>>>>> Best, >>>>>>>> Arnold >>>>>>>> >>>>>>> >>>>>
