You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Arnold Galovics <ar...@apache.org> on 2022/05/17 20:00:38 UTC
Notification topic subscription feature abandoned?
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
Re: Notification topic subscription feature abandoned?
Posted by Ed Cable <ed...@mifos.org>.
I'm cc'ing @Pranjal Goswami <pr...@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 <ed...@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 <eb...@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 <ed...@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
<eb...@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 <is...@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 <ed...@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 <ga...@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 <ja...@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 <bg...@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 <
>>> cheetah@monkeysintown.com> wrote:
>>>
>>>> ... thanks Adam... learned again.
>>>>
>>>> On Wed, May 18, 2022 at 10:28 AM Ádám Sághy <ad...@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 <
>>>>> cheetah@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 <aw...@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 <
>>>>>> cheetah@monkeysintown.com> wrote:
>>>>>>
>>>>>>> I would say: +1
>>>>>>>
>>>>>>> On Tue, May 17, 2022 at 10:01 PM Arnold Galovics <ar...@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
>>>>>>>>
>>>>>>>
>>>>>
Re: Notification topic subscription feature abandoned?
Posted by Ádám Sághy <ad...@gmail.com>.
Hi Pranjal,
Thanks for the quick reply! Yes, you have answered my question!
Thanks,
Adam
> On 19 May 2022, at 18:14, Pranjal Goswami <pr...@gmail.com> wrote:
>
> Hi Arnold,
>
> I agree with you. It was over-engineering from the design perspective. The initial discussions in 2016 indicated such scenarios might come up. However, in hindsight it might seem unnecessary. We saw a lot of utility in our own application and hence included it in this project.
>
> Hi Adam,
>
> Good to meet you too!
> ActiveMQ was introduced majorly for two reasons.
>
> 1. Make the notification processing (generating message, recipients and actually sending it) asynchronous and detached from the Notification generation process.
> Keeping it synchronous would mean that the notification generation and delivery procedure could hurt the API latency.
> Could have achieved the same by starting a new Thread - but using a message broker is a standard way.
>
> 2. Foresight. In case we break down services to separate applications/services, ActiveMQ could be a way to broker the messages.
>
> That said, did I understand your question correctly? Or was the question - why specifically ActiveMQ?
>
> Let me know.
> Thanks
>
> On Thu, 19 May 2022 at 21:25, Ádám Sághy <adamsaghy@gmail.com <ma...@gmail.com>> wrote:
> Hi Pranjal,
>
> Its good to meet you! Since you offered your help, I was wondering whether you could help me to get a better insight about what was the reason to use activeMq in the Notification sub-system.
>
> Regards,
> Adam
>
>> On 19 May 2022, at 17:48, Arnold Galovics <arnold@apache.org <ma...@apache.org>> wrote:
>>
>> Hi Pranjal,
>>
>> Got it and I concluded the same from the presentation Ed shared.
>>
>> Frankly speaking, I'm still not convinced that the "pre-computation of recipients" is actually needed. I think that asking the question of "who are the recipients for this notification" every time is reasonable. And since the notification sending is happening on an asynchronous execution thread, it won't affect any of the real-time functionalities.
>>
>> I'd say if I have to put the complexity and the performance benefit onto balance, I'd say with the current implementation it hangs more towards complexity.
>>
>> If there's a performance issue in the future, we can still revisit.
>>
>> Hope that makes sense.
>> Best,
>> Arnold
>>
>> On Thu, May 19, 2022 at 5:37 PM Pranjal Goswami <pranjal.b.goswami@gmail.com <ma...@gmail.com>> wrote:
>> Hi Arnold,
>>
>> Introduction: I designed the Notification sub-system based on what we used at Superset <https://joinsuperset.com/>.
>>
>> You are indeed partly right. The notification generation and delivery do not need to depend on topics and topic_subscribers.
>>
>> However, the topics and topic_subscribers are meant to avoid computation of the list of recipients of the said notifications. Let me explain using a couple of examples.
>>
>> In the context of Superset, a tool to manage recruitments for colleges, if we want to send a notification to all students of Humanities major, we will have to get the list of user IDs of the said predicate.
>>
>> Now, I can do something like:
>> SELECT ids from users where (.... some joins ....) user.major = 'Humanities' and then pass the list of IDs
>>
>> OR
>>
>> Have a pre-computed list of user IDs for this frequently used group. This saves me the compute time for getting the query results. The real benefits come when the real-time fetch of the user IDs using the query logic is convoluted.
>>
>> In the context of Mifos, it could be notifying all Loan Officers of a branch.
>>
>> The second advantage is the notification being visible to someone who joins the group later. This is not implemented yet.
>> Let's say you sent a notification to all the loan officers and a loan officer joined the next day and should be shown the same message when he logs in. Then posting a notification to a topic would make sense. This would make even more sense if we have a message board or a notice board implemented for important announcements to the members.
>>
>> In conclusion, if the feature is being used just with a notification for a list of User IDs, we don't need topics and subscribers. In case we are running into cases where we would like to not compute the recipient list again and again (sort of a cache for recipients of a logical group) then we can promote the use of topic and topic_subscribers.
>>
>> Let me know if there are any questions.
>>
>> Thanks
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, 19 May 2022 at 12:35, Arnold Galovics <arnold@apache.org <ma...@apache.org>> wrote:
>> Hi Ed,
>>
>> Wow, that's great you were able to grab the docs and the email thread.
>> I checked both and it confirms my theory. The topic and topic_subscriber tables were unnecessary in the picture to achieve the behavior we wanted.
>>
>> @Victor: thanks for the info.
>>
>> Best,
>> Arnold
>>
>> On Wed, May 18, 2022 at 5:22 PM VICTOR MANUEL ROMERO RODRIGUEZ <victor.romero@fintecheando.mx <ma...@fintecheando.mx>> wrote:
>> Hello Arnold,
>>
>> For the classical UI some events were not passed to the UI (details URL) because the Event property names were not matching.
>>
>> I think it is still open ..
>>
>> https://github.com/openMF/community-app/pull/3441 <https://github.com/openMF/community-app/pull/3441>
>>
>> Regards
>>
>> Victor
>>
>> El mié, 18 may 2022 a las 10:10, Arnold Galovics (<galovicsarnold@gmail.com <ma...@gmail.com>>) escribió:
>> 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 <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 <jamespdailey@gmail.com <ma...@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 <bgowda@mifos.org <ma...@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://mifos.org/> <http://facebook.com/mifos> <http://www.twitter.com/mifos>
>>
>>
>> On Wed, May 18, 2022 at 3:29 PM Aleksandar Vidakovic <cheetah@monkeysintown.com <ma...@monkeysintown.com>> wrote:
>> ... thanks Adam... learned again.
>>
>> On Wed, May 18, 2022 at 10:28 AM Ádám Sághy <adamsaghy@gmail.com <ma...@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 <cheetah@monkeysintown.com <ma...@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 <awasum@apache.org <ma...@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 <cheetah@monkeysintown.com <ma...@monkeysintown.com>> wrote:
>>> I would say: +1
>>>
>>> On Tue, May 17, 2022 at 10:01 PM Arnold Galovics <arnold@apache.org <ma...@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
>>
>>
>>
>> --
>> Regards,
>> Pranjal Goswami
>>
>
>
>
> --
> Regards,
> Pranjal Goswami
>
Re: Notification topic subscription feature abandoned?
Posted by Pranjal Goswami <pr...@gmail.com>.
Hi Arnold,
I agree with you. It was over-engineering from the design perspective. The
initial discussions in 2016 indicated such scenarios might come up.
However, in hindsight it might seem unnecessary. We saw a lot of utility in
our own application and hence included it in this project.
Hi Adam,
Good to meet you too!
ActiveMQ was introduced majorly for two reasons.
1. Make the notification processing (generating message, recipients and
actually sending it) asynchronous and detached from the Notification
generation process.
Keeping it synchronous would mean that the notification generation and
delivery procedure could hurt the API latency.
Could have achieved the same by starting a new Thread - but using a message
broker is a standard way.
2. Foresight. In case we break down services to separate
applications/services, ActiveMQ could be a way to broker the messages.
That said, did I understand your question correctly? Or was the question - *why
specifically ActiveMQ?*
Let me know.
Thanks
On Thu, 19 May 2022 at 21:25, Ádám Sághy <ad...@gmail.com> wrote:
> Hi Pranjal,
>
> Its good to meet you! Since you offered your help, I was wondering whether
> you could help me to get a better insight about what was the reason to use
> activeMq in the Notification sub-system.
>
> Regards,
> Adam
>
> On 19 May 2022, at 17:48, Arnold Galovics <ar...@apache.org> wrote:
>
> Hi Pranjal,
>
> Got it and I concluded the same from the presentation Ed shared.
>
> Frankly speaking, I'm still not convinced that the "pre-computation of
> recipients" is actually needed. I think that asking the question of "who
> are the recipients for this notification" every time is reasonable. And
> since the notification sending is happening on an asynchronous execution
> thread, it won't affect any of the real-time functionalities.
>
> I'd say if I have to put the complexity and the performance benefit onto
> balance, I'd say with the current implementation it hangs more towards
> complexity.
>
> If there's a performance issue in the future, we can still revisit.
>
> Hope that makes sense.
> Best,
> Arnold
>
> On Thu, May 19, 2022 at 5:37 PM Pranjal Goswami <
> pranjal.b.goswami@gmail.com> wrote:
>
>> Hi Arnold,
>>
>> Introduction: I designed the Notification sub-system based on what we
>> used at Superset <https://joinsuperset.com/>.
>>
>> You are indeed partly right. The notification generation and delivery do
>> not need to depend on topics and topic_subscribers.
>>
>> However, the topics and topic_subscribers are meant to avoid computation
>> of the list of recipients of the said notifications. Let me explain using a
>> couple of examples.
>>
>> In the context of Superset, a tool to manage recruitments for colleges,
>> if we want to send a notification to all students of Humanities major, we
>> will have to get the list of user IDs of the said predicate.
>>
>> Now, I can do something like:
>> *SELECT ids from users where (.... some joins ....) user.major =
>> 'Humanities' * and then pass the list of IDs
>>
>> OR
>>
>> Have a pre-computed list of user IDs for this frequently used group. This
>> saves me the compute time for getting the query results. The real benefits
>> come when the real-time fetch of the user IDs using the query logic is
>> convoluted.
>>
>> In the context of Mifos, it could be notifying all Loan Officers of a
>> branch.
>>
>> The second advantage is the notification being visible to someone who
>> joins the group later. This is not implemented yet.
>> Let's say you sent a notification to all the loan officers and a loan
>> officer joined the next day and should be shown the same message when he
>> logs in. Then posting a notification to a topic would make sense. This
>> would make even more sense if we have a message board or a notice board
>> implemented for important announcements to the members.
>>
>> In conclusion, if the feature is being used just with a notification for
>> a list of User IDs, we don't need topics and subscribers. In case we are
>> running into cases where we would like to not compute the recipient list
>> again and again (sort of a cache for recipients of a logical group) then we
>> can promote the use of topic and topic_subscribers.
>>
>> Let me know if there are any questions.
>>
>> Thanks
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, 19 May 2022 at 12:35, Arnold Galovics <ar...@apache.org> wrote:
>>
>>> Hi Ed,
>>>
>>> Wow, that's great you were able to grab the docs and the email thread.
>>> I checked both and it confirms my theory. The topic and topic_subscriber
>>> tables were unnecessary in the picture to achieve the behavior we wanted.
>>>
>>> @Victor: thanks for the info.
>>>
>>> Best,
>>> Arnold
>>>
>>> On Wed, May 18, 2022 at 5:22 PM VICTOR MANUEL ROMERO RODRIGUEZ <
>>> victor.romero@fintecheando.mx> wrote:
>>>
>>>> Hello Arnold,
>>>>
>>>> For the classical UI some events were not passed to the UI (details
>>>> URL) because the Event property names were not matching.
>>>>
>>>> I think it is still open ..
>>>>
>>>> https://github.com/openMF/community-app/pull/3441
>>>>
>>>> Regards
>>>>
>>>> Victor
>>>>
>>>> El mié, 18 may 2022 a las 10:10, Arnold Galovics (<
>>>> galovicsarnold@gmail.com>) escribió:
>>>>
>>>>> 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 <ja...@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 <bg...@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 <
>>>>>>> cheetah@monkeysintown.com> wrote:
>>>>>>>
>>>>>>>> ... thanks Adam... learned again.
>>>>>>>>
>>>>>>>> On Wed, May 18, 2022 at 10:28 AM Ádám Sághy <ad...@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 <
>>>>>>>>> cheetah@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 <aw...@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 <
>>>>>>>>>> cheetah@monkeysintown.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> I would say: +1
>>>>>>>>>>>
>>>>>>>>>>> On Tue, May 17, 2022 at 10:01 PM Arnold Galovics <
>>>>>>>>>>> arnold@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
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>
>> --
>> Regards,
>> *Pranjal Goswami*
>>
>>
>
--
Regards,
*Pranjal Goswami*
Re: Notification topic subscription feature abandoned?
Posted by Ádám Sághy <ad...@gmail.com>.
Hi Pranjal,
Its good to meet you! Since you offered your help, I was wondering whether you could help me to get a better insight about what was the reason to use activeMq in the Notification sub-system.
Regards,
Adam
> On 19 May 2022, at 17:48, Arnold Galovics <ar...@apache.org> wrote:
>
> Hi Pranjal,
>
> Got it and I concluded the same from the presentation Ed shared.
>
> Frankly speaking, I'm still not convinced that the "pre-computation of recipients" is actually needed. I think that asking the question of "who are the recipients for this notification" every time is reasonable. And since the notification sending is happening on an asynchronous execution thread, it won't affect any of the real-time functionalities.
>
> I'd say if I have to put the complexity and the performance benefit onto balance, I'd say with the current implementation it hangs more towards complexity.
>
> If there's a performance issue in the future, we can still revisit.
>
> Hope that makes sense.
> Best,
> Arnold
>
> On Thu, May 19, 2022 at 5:37 PM Pranjal Goswami <pranjal.b.goswami@gmail.com <ma...@gmail.com>> wrote:
> Hi Arnold,
>
> Introduction: I designed the Notification sub-system based on what we used at Superset <https://joinsuperset.com/>.
>
> You are indeed partly right. The notification generation and delivery do not need to depend on topics and topic_subscribers.
>
> However, the topics and topic_subscribers are meant to avoid computation of the list of recipients of the said notifications. Let me explain using a couple of examples.
>
> In the context of Superset, a tool to manage recruitments for colleges, if we want to send a notification to all students of Humanities major, we will have to get the list of user IDs of the said predicate.
>
> Now, I can do something like:
> SELECT ids from users where (.... some joins ....) user.major = 'Humanities' and then pass the list of IDs
>
> OR
>
> Have a pre-computed list of user IDs for this frequently used group. This saves me the compute time for getting the query results. The real benefits come when the real-time fetch of the user IDs using the query logic is convoluted.
>
> In the context of Mifos, it could be notifying all Loan Officers of a branch.
>
> The second advantage is the notification being visible to someone who joins the group later. This is not implemented yet.
> Let's say you sent a notification to all the loan officers and a loan officer joined the next day and should be shown the same message when he logs in. Then posting a notification to a topic would make sense. This would make even more sense if we have a message board or a notice board implemented for important announcements to the members.
>
> In conclusion, if the feature is being used just with a notification for a list of User IDs, we don't need topics and subscribers. In case we are running into cases where we would like to not compute the recipient list again and again (sort of a cache for recipients of a logical group) then we can promote the use of topic and topic_subscribers.
>
> Let me know if there are any questions.
>
> Thanks
>
>
>
>
>
>
>
>
>
> On Thu, 19 May 2022 at 12:35, Arnold Galovics <arnold@apache.org <ma...@apache.org>> wrote:
> Hi Ed,
>
> Wow, that's great you were able to grab the docs and the email thread.
> I checked both and it confirms my theory. The topic and topic_subscriber tables were unnecessary in the picture to achieve the behavior we wanted.
>
> @Victor: thanks for the info.
>
> Best,
> Arnold
>
> On Wed, May 18, 2022 at 5:22 PM VICTOR MANUEL ROMERO RODRIGUEZ <victor.romero@fintecheando.mx <ma...@fintecheando.mx>> wrote:
> Hello Arnold,
>
> For the classical UI some events were not passed to the UI (details URL) because the Event property names were not matching.
>
> I think it is still open ..
>
> https://github.com/openMF/community-app/pull/3441 <https://github.com/openMF/community-app/pull/3441>
>
> Regards
>
> Victor
>
> El mié, 18 may 2022 a las 10:10, Arnold Galovics (<galovicsarnold@gmail.com <ma...@gmail.com>>) escribió:
> 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 <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 <jamespdailey@gmail.com <ma...@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 <bgowda@mifos.org <ma...@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://mifos.org/> <http://facebook.com/mifos> <http://www.twitter.com/mifos>
>
>
> On Wed, May 18, 2022 at 3:29 PM Aleksandar Vidakovic <cheetah@monkeysintown.com <ma...@monkeysintown.com>> wrote:
> ... thanks Adam... learned again.
>
> On Wed, May 18, 2022 at 10:28 AM Ádám Sághy <adamsaghy@gmail.com <ma...@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 <cheetah@monkeysintown.com <ma...@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 <awasum@apache.org <ma...@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 <cheetah@monkeysintown.com <ma...@monkeysintown.com>> wrote:
>> I would say: +1
>>
>> On Tue, May 17, 2022 at 10:01 PM Arnold Galovics <arnold@apache.org <ma...@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
>
>
>
> --
> Regards,
> Pranjal Goswami
>
Re: Notification topic subscription feature abandoned?
Posted by Arnold Galovics <ar...@apache.org>.
Hi Pranjal,
Got it and I concluded the same from the presentation Ed shared.
Frankly speaking, I'm still not convinced that the "pre-computation of
recipients" is actually needed. I think that asking the question of "who
are the recipients for this notification" every time is reasonable. And
since the notification sending is happening on an asynchronous execution
thread, it won't affect any of the real-time functionalities.
I'd say if I have to put the complexity and the performance benefit onto
balance, I'd say with the current implementation it hangs more towards
complexity.
If there's a performance issue in the future, we can still revisit.
Hope that makes sense.
Best,
Arnold
On Thu, May 19, 2022 at 5:37 PM Pranjal Goswami <pr...@gmail.com>
wrote:
> Hi Arnold,
>
> Introduction: I designed the Notification sub-system based on what we used
> at Superset <https://joinsuperset.com/>.
>
> You are indeed partly right. The notification generation and delivery do
> not need to depend on topics and topic_subscribers.
>
> However, the topics and topic_subscribers are meant to avoid computation
> of the list of recipients of the said notifications. Let me explain using a
> couple of examples.
>
> In the context of Superset, a tool to manage recruitments for colleges, if
> we want to send a notification to all students of Humanities major, we will
> have to get the list of user IDs of the said predicate.
>
> Now, I can do something like:
> *SELECT ids from users where (.... some joins ....) user.major =
> 'Humanities' * and then pass the list of IDs
>
> OR
>
> Have a pre-computed list of user IDs for this frequently used group. This
> saves me the compute time for getting the query results. The real benefits
> come when the real-time fetch of the user IDs using the query logic is
> convoluted.
>
> In the context of Mifos, it could be notifying all Loan Officers of a
> branch.
>
> The second advantage is the notification being visible to someone who
> joins the group later. This is not implemented yet.
> Let's say you sent a notification to all the loan officers and a loan
> officer joined the next day and should be shown the same message when he
> logs in. Then posting a notification to a topic would make sense. This
> would make even more sense if we have a message board or a notice board
> implemented for important announcements to the members.
>
> In conclusion, if the feature is being used just with a notification for a
> list of User IDs, we don't need topics and subscribers. In case we are
> running into cases where we would like to not compute the recipient list
> again and again (sort of a cache for recipients of a logical group) then we
> can promote the use of topic and topic_subscribers.
>
> Let me know if there are any questions.
>
> Thanks
>
>
>
>
>
>
>
>
>
> On Thu, 19 May 2022 at 12:35, Arnold Galovics <ar...@apache.org> wrote:
>
>> Hi Ed,
>>
>> Wow, that's great you were able to grab the docs and the email thread.
>> I checked both and it confirms my theory. The topic and topic_subscriber
>> tables were unnecessary in the picture to achieve the behavior we wanted.
>>
>> @Victor: thanks for the info.
>>
>> Best,
>> Arnold
>>
>> On Wed, May 18, 2022 at 5:22 PM VICTOR MANUEL ROMERO RODRIGUEZ <
>> victor.romero@fintecheando.mx> wrote:
>>
>>> Hello Arnold,
>>>
>>> For the classical UI some events were not passed to the UI (details
>>> URL) because the Event property names were not matching.
>>>
>>> I think it is still open ..
>>>
>>> https://github.com/openMF/community-app/pull/3441
>>>
>>> Regards
>>>
>>> Victor
>>>
>>> El mié, 18 may 2022 a las 10:10, Arnold Galovics (<
>>> galovicsarnold@gmail.com>) escribió:
>>>
>>>> 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 <ja...@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 <bg...@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 <
>>>>>> cheetah@monkeysintown.com> wrote:
>>>>>>
>>>>>>> ... thanks Adam... learned again.
>>>>>>>
>>>>>>> On Wed, May 18, 2022 at 10:28 AM Ádám Sághy <ad...@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 <
>>>>>>>> cheetah@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 <aw...@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 <
>>>>>>>>> cheetah@monkeysintown.com> wrote:
>>>>>>>>>
>>>>>>>>>> I would say: +1
>>>>>>>>>>
>>>>>>>>>> On Tue, May 17, 2022 at 10:01 PM Arnold Galovics <
>>>>>>>>>> arnold@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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>
> --
> Regards,
> *Pranjal Goswami*
>
>
Re: Notification topic subscription feature abandoned?
Posted by Pranjal Goswami <pr...@gmail.com>.
Hi Arnold,
Introduction: I designed the Notification sub-system based on what we used
at Superset <https://joinsuperset.com/>.
You are indeed partly right. The notification generation and delivery do
not need to depend on topics and topic_subscribers.
However, the topics and topic_subscribers are meant to avoid computation of
the list of recipients of the said notifications. Let me explain using a
couple of examples.
In the context of Superset, a tool to manage recruitments for colleges, if
we want to send a notification to all students of Humanities major, we will
have to get the list of user IDs of the said predicate.
Now, I can do something like:
*SELECT ids from users where (.... some joins ....) user.major =
'Humanities' * and then pass the list of IDs
OR
Have a pre-computed list of user IDs for this frequently used group. This
saves me the compute time for getting the query results. The real benefits
come when the real-time fetch of the user IDs using the query logic is
convoluted.
In the context of Mifos, it could be notifying all Loan Officers of a
branch.
The second advantage is the notification being visible to someone who joins
the group later. This is not implemented yet.
Let's say you sent a notification to all the loan officers and a loan
officer joined the next day and should be shown the same message when he
logs in. Then posting a notification to a topic would make sense. This
would make even more sense if we have a message board or a notice board
implemented for important announcements to the members.
In conclusion, if the feature is being used just with a notification for a
list of User IDs, we don't need topics and subscribers. In case we are
running into cases where we would like to not compute the recipient list
again and again (sort of a cache for recipients of a logical group) then we
can promote the use of topic and topic_subscribers.
Let me know if there are any questions.
Thanks
On Thu, 19 May 2022 at 12:35, Arnold Galovics <ar...@apache.org> wrote:
> Hi Ed,
>
> Wow, that's great you were able to grab the docs and the email thread.
> I checked both and it confirms my theory. The topic and topic_subscriber
> tables were unnecessary in the picture to achieve the behavior we wanted.
>
> @Victor: thanks for the info.
>
> Best,
> Arnold
>
> On Wed, May 18, 2022 at 5:22 PM VICTOR MANUEL ROMERO RODRIGUEZ <
> victor.romero@fintecheando.mx> wrote:
>
>> Hello Arnold,
>>
>> For the classical UI some events were not passed to the UI (details
>> URL) because the Event property names were not matching.
>>
>> I think it is still open ..
>>
>> https://github.com/openMF/community-app/pull/3441
>>
>> Regards
>>
>> Victor
>>
>> El mié, 18 may 2022 a las 10:10, Arnold Galovics (<
>> galovicsarnold@gmail.com>) escribió:
>>
>>> 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 <ja...@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 <bg...@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 <
>>>>> cheetah@monkeysintown.com> wrote:
>>>>>
>>>>>> ... thanks Adam... learned again.
>>>>>>
>>>>>> On Wed, May 18, 2022 at 10:28 AM Ádám Sághy <ad...@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 <
>>>>>>> cheetah@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 <aw...@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 <
>>>>>>>> cheetah@monkeysintown.com> wrote:
>>>>>>>>
>>>>>>>>> I would say: +1
>>>>>>>>>
>>>>>>>>> On Tue, May 17, 2022 at 10:01 PM Arnold Galovics <
>>>>>>>>> arnold@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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
--
Regards,
*Pranjal Goswami*
Re: Notification topic subscription feature abandoned?
Posted by Arnold Galovics <ar...@apache.org>.
Hi Ed,
Wow, that's great you were able to grab the docs and the email thread.
I checked both and it confirms my theory. The topic and topic_subscriber
tables were unnecessary in the picture to achieve the behavior we wanted.
@Victor: thanks for the info.
Best,
Arnold
On Wed, May 18, 2022 at 5:22 PM VICTOR MANUEL ROMERO RODRIGUEZ <
victor.romero@fintecheando.mx> wrote:
> Hello Arnold,
>
> For the classical UI some events were not passed to the UI (details
> URL) because the Event property names were not matching.
>
> I think it is still open ..
>
> https://github.com/openMF/community-app/pull/3441
>
> Regards
>
> Victor
>
> El mié, 18 may 2022 a las 10:10, Arnold Galovics (<
> galovicsarnold@gmail.com>) escribió:
>
>> 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 <ja...@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 <bg...@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 <
>>>> cheetah@monkeysintown.com> wrote:
>>>>
>>>>> ... thanks Adam... learned again.
>>>>>
>>>>> On Wed, May 18, 2022 at 10:28 AM Ádám Sághy <ad...@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 <
>>>>>> cheetah@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 <aw...@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 <
>>>>>>> cheetah@monkeysintown.com> wrote:
>>>>>>>
>>>>>>>> I would say: +1
>>>>>>>>
>>>>>>>> On Tue, May 17, 2022 at 10:01 PM Arnold Galovics <ar...@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
>>>>>>>>>
>>>>>>>>
>>>>>>
Re: Notification topic subscription feature abandoned?
Posted by VICTOR MANUEL ROMERO RODRIGUEZ <vi...@fintecheando.mx>.
Hello Arnold,
For the classical UI some events were not passed to the UI (details
URL) because the Event property names were not matching.
I think it is still open ..
https://github.com/openMF/community-app/pull/3441
Regards
Victor
El mié, 18 may 2022 a las 10:10, Arnold Galovics (<ga...@gmail.com>)
escribió:
> 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 <ja...@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 <bg...@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 <
>>> cheetah@monkeysintown.com> wrote:
>>>
>>>> ... thanks Adam... learned again.
>>>>
>>>> On Wed, May 18, 2022 at 10:28 AM Ádám Sághy <ad...@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 <
>>>>> cheetah@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 <aw...@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 <
>>>>>> cheetah@monkeysintown.com> wrote:
>>>>>>
>>>>>>> I would say: +1
>>>>>>>
>>>>>>> On Tue, May 17, 2022 at 10:01 PM Arnold Galovics <ar...@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
>>>>>>>>
>>>>>>>
>>>>>
Re: Notification topic subscription feature abandoned?
Posted by Arnold Galovics <ga...@gmail.com>.
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 <ja...@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 <bg...@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 <
>> cheetah@monkeysintown.com> wrote:
>>
>>> ... thanks Adam... learned again.
>>>
>>> On Wed, May 18, 2022 at 10:28 AM Ádám Sághy <ad...@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 <
>>>> cheetah@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 <aw...@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 <
>>>>> cheetah@monkeysintown.com> wrote:
>>>>>
>>>>>> I would say: +1
>>>>>>
>>>>>> On Tue, May 17, 2022 at 10:01 PM Arnold Galovics <ar...@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
>>>>>>>
>>>>>>
>>>>
Re: Notification topic subscription feature abandoned?
Posted by James Dailey <ja...@gmail.com>.
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 <bg...@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 <
> cheetah@monkeysintown.com> wrote:
>
>> ... thanks Adam... learned again.
>>
>> On Wed, May 18, 2022 at 10:28 AM Ádám Sághy <ad...@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 <
>>> cheetah@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 <aw...@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 <
>>>> cheetah@monkeysintown.com> wrote:
>>>>
>>>>> I would say: +1
>>>>>
>>>>> On Tue, May 17, 2022 at 10:01 PM Arnold Galovics <ar...@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
>>>>>>
>>>>>
>>>
Re: Notification topic subscription feature abandoned?
Posted by Bharath Gowda <bg...@mifos.org>.
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 <
cheetah@monkeysintown.com> wrote:
> ... thanks Adam... learned again.
>
> On Wed, May 18, 2022 at 10:28 AM Ádám Sághy <ad...@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 <ch...@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 <aw...@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 <
>>> cheetah@monkeysintown.com> wrote:
>>>
>>>> I would say: +1
>>>>
>>>> On Tue, May 17, 2022 at 10:01 PM Arnold Galovics <ar...@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
>>>>>
>>>>
>>
Re: Notification topic subscription feature abandoned?
Posted by Aleksandar Vidakovic <ch...@monkeysintown.com>.
... thanks Adam... learned again.
On Wed, May 18, 2022 at 10:28 AM Ádám Sághy <ad...@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 <ch...@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 <aw...@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 <
>> cheetah@monkeysintown.com> wrote:
>>
>>> I would say: +1
>>>
>>> On Tue, May 17, 2022 at 10:01 PM Arnold Galovics <ar...@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
>>>>
>>>
>
Re: Notification topic subscription feature abandoned?
Posted by Ádám Sághy <ad...@gmail.com>.
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 <ch...@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 <awasum@apache.org <ma...@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 <cheetah@monkeysintown.com <ma...@monkeysintown.com>> wrote:
> I would say: +1
>
> On Tue, May 17, 2022 at 10:01 PM Arnold Galovics <arnold@apache.org <ma...@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
Re: Notification topic subscription feature abandoned?
Posted by Aleksandar Vidakovic <ch...@monkeysintown.com>.
... 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 <aw...@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 <
> cheetah@monkeysintown.com> wrote:
>
>> I would say: +1
>>
>> On Tue, May 17, 2022 at 10:01 PM Arnold Galovics <ar...@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
>>>
>>
Re: Notification topic subscription feature abandoned?
Posted by Awasum Yannick <aw...@apache.org>.
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 <ch...@monkeysintown.com>
wrote:
> I would say: +1
>
> On Tue, May 17, 2022 at 10:01 PM Arnold Galovics <ar...@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
>>
>
Re: Notification topic subscription feature abandoned?
Posted by Aleksandar Vidakovic <ch...@monkeysintown.com>.
I would say: +1
On Tue, May 17, 2022 at 10:01 PM Arnold Galovics <ar...@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
>