Hi Felix, My POV was directed for the whole community . . . and was not a "counterpoint" to anyone. Maybe an extension of thought and method? (why the broader Fineract mission is good for unbanked and a "how to" example.).
On Sun, Aug 31, 2025 at 7:41 AM Felix van Hove <fvanh...@gmx.de.invalid> wrote: > Paul, I've thought a long time on your email. I think I find it > difficult to answer, because - to a certain extend - I agree with you > and James. It might be good to position Fineract broadly like this. > > But a discussion on a roadmap, with all parties involved, is of > importance. To ask on the mailing list "Who is willing to fix a buggy > feature X? Who will support it in the future?" and decommission it > afterwards, because no one showed up, - appears too simple to me. > > Though I think I had more confidence in this happening, if I saw *any* > new feature being proposed during my time, serving the same people that > the Collection Sheet serves. > > Felix > > > > On 30/08/2025 22:49, Paul wrote: > > Great feedback, Felix, Zayyad. > > I would like to share a perspective from history and why the big picture > > approach and broader mission is so important. > > > > There was a phrase in use when I was a baby. "Separate, but Equal." This > > was a phrase used to justify keeping US school systems segregated by > race. > > "Separate but Equal" was a lie. The systems were never equal in funding, > > quality or anything else. > > Finance and access is the same. > > > > *What does that have to do with Fineract?* > > Mission solely dedicated to the unbanked shrinks the number of people > > willing to join the community. > > Others may be sympathetic, but won't directly participate by > contributing. > > I happen to be interested in the unbanked and personally support that > > mission. > > > > HOWEVER, my main interest in Fineract is to support a commercial > enterprise > > Open Source core banking system. A core banking system which integrates > > embedds services anywhere, not just microfinance and money transfers. > > > > When the Fineract mission was focused on the unbanked, it was seriously > > under participated IMO. With its slight change in mission which is still > > inclusive of the underbanked, participation is increasing and releases > are > > beginning to become more regular. The unbanked needs to be supported > with a > > system capable of full integration with the rest of the world, not a > > "separate but equal system". > > > > I hope my history story makes sense to at least support my POV. > > > > *How Fineract works for the unbanked with its current mission > statement. * > > > > MIFOS is solely dedicated to the underserved and has the frontend to do > so. > > In my opinion, if collection sheets are still used in working with > > unbanked, then MIFOS community should adopt and help maintain them them > as > > a current, modern, secure function so that the MIFOS frontend works with > > the Fineract backend. MIFOS like all other users of Fineract get the > > benefit of a stronger core banking system and vendors with dedicated > > purpose work together to maintain their particular core channels within > > Fineract. > > > > The image is a generalization to convey the concept. (It may not be > precise > > as to the vendors and players, but should reinforce my POV.) > > So, you, your interest or company wants a function or to maintain an > > existing function? GREAT! > > Step up! Own that solution within Fineract. > > [image: image.png] > > I speak solely for myself and my POV, but this approach will generate 10X > > deeper support than segregated methods. > > > > In the past, there was insufficient community, but I think there was also > > "community orchestration" missing to a degree. > > > > *Fail Model:* > > Hoping it all gets done and telling the community at large "do something" > > doesn't work. > > > > *Success Model: * > > When a platform is useful across a whole ecosystem, then it can be > jointly > > maintained with nominal management. People are willing to help. Just like > > musicians want to play music, they want to work together. In RARE > > circumstances, the community is so SINGLE minded, the build, like JAZZ, > > happens spontaneously and all agree, its really cool. > > > > *However, the bulk of the world needs direction and orchestration* to > "make > > music" of product delivery. Because of those many different interests, > > Fineract needs process to harmonize and create results. > > > > In the end, there also must be a binary decision, "yes or no" to support > an > > issue. It comes down to; " will a community member support a function > > important to their channel?" > > > > I'm not a developer, my useful skills are domain knowledge and > > instructional orchestration (process). So I challenge all community > members > > to find a channel required to fulfill your channel or interest and > > volunteer to "own it" through a date certain. Better yet, form a small > team > > of like minds and assure that function is ALWAYS current and secure. > > > > This is a challenge to all community members and targeting no one. > > > > Paul > > > > On Sat, Aug 30, 2025 at 3:34 PM James Dailey <jdai...@apache.org> wrote: > > > >> Zayyad, Felix and others - > >> > >> Indeed. And all of this was laid out for many years as the strategy. > >> > >> When I was on the Board of Mifos (the non profit, not the project) we > >> decided to contribute the MifosX code to the ASF to ensure both: > >> a) a broader financial services industry approach, and > >> b) a more established foundational home for the core of the project. > >> > >> There were other reasons, but those remain primary in my mind. > >> > >> The concept was that Mifos org, which is a Vendor in the ASF parlance, > >> would continue its Financial Inclusion mission and make sure that the > >> releases that were coming out of the project would retain the flavor and > >> intent of the original mifos project (which I started and designed in > >> 2001). The Mifos AdminUI /CommunityApp open source front end UI gave > it a > >> place in the ecosystem and a way to ensure that alignment. > >> > >> But, importantly, when we made this decision, we deliberately wanted to > >> see more financial institutions and fintechs use the backend system, AND > >> vitally, to help maintain it, with contributions upstream. That is the > >> sign of a healthy open source project. > >> > >> I don't speak for Mifos, but I believe that the vision at Mifos remains > >> about financial inclusion. But the vision of Fineract and the mission > of > >> the project is different. We actually VOTED on this revised statement > as a > >> community, I think five years ago. > >> > >> So, if you are seeing a difference between Mifos and Fineract, then we > >> have succeeded in an important goal. The two are NOT THE SAME. This is > >> NOT mifos. > >> > >> This has been called out in many many Reports to the ASF Board. See the > >> wiki pages for those. The key theme is Vendor neutrality - we do not > >> privilege any vendor. > >> > >> And, I would argue that this is the right healthy direction for this > >> Fineract project. Microfinance serves an important role in the world, > and > >> continues despite many expecting it to decline or go away. And, the > >> mission of the original concept of Mifos was not about Microfinance but > >> about financial inclusion. However that happens. > >> > >> And, fundamentally, I personally remain focused on this - disrupting the > >> financial industry with open source software that can functionally be > the > >> basis of any bank or fintech globally. It should lower the cost of > >> financial inclusion, it should do that via any kind of institution at a > >> structural level. Unbanked and underbanked are included. > >> > >> So, if you are not seeing what you want here, then you can invest more > >> time and resources to make it more of what you want, but I would also > >> suggest that the fundamental thing is to have healthy vendors that move > the > >> project forward with lots of "built on top of" functionality that serve > a > >> wide range of financial institutions. If those components are also open > >> source, that's ok, but it isn't essential. > >> > >> ** Deprecation process ** > >> Deprecating features is a natural part of any system evolution - we need > >> to prune the tree from time to time. If users are demanding those > features > >> then they should speak up - as this thread illustrated - and mechanisms > >> need to be put in place to "protect them". Here of course, I am > referring > >> to my last email and testing, to start with. > >> > >> And, we should do a better job of documenting the product roadmap, and > >> having clear discussions about deprecating features - Before they are > >> deprecated. > >> > >> That starts with you listing your required feature set and documenting > it > >> somewhere perhaps - or relying on the Vendor to speak up for your > interests > >> if you don't. > >> > >> And, this is a good discussion to have. Perhaps a community call on > this > >> topic would be welcomed in coming weeks. > >> > >> James > >> > >> > >> > >> On Sat, Aug 30, 2025 at 3:13 AM Zayyad A. Said < > >> zay...@intrasofttechnologies.com> wrote: > >> > >>> Hello Fineract community, > >>> > >>> I concur with the observations below from Felix. > >>> > >>> We have been implementing Mifos since 2011 and we have seen the project > >>> transitioning from Mifos 2.x to Mifos X and now with the new > developments. > >>> The current focus seems to have shifted from the original mission of > >>> "Creating a world of 3 Billion Maries where each of the 2 billion poor > and > >>> unbanked has access to the financial resources needed to create a > better > >>> life for themselves and their family." > >>> > >>> Group lending has been used for decades and Mifos was originally > intended > >>> for and served the model, the new features being introduced are geared > >>> towards commercial use. We saw this coming and we had to maintain old > fork > >>> for our MFI clients where we continue to improve based on their needs. > >>> > >>> While I have no problem with having new features, I seem not to > >>> understand why we want to deprecate features of group lending that are > >>> still being used even if with the minority of users globally yet they > do no > >>> harm to the security and overall performance of the project. > >>> > >>> I suggest the leadership to rethink the idea of deprecating collection > >>> sheet functionality and other key features used in group lending. > >>> > >>> Best Regards, > >>> > >>> Zayyad A. Said > >>> Intrasoft Technologies Limited > >>> > >>> ********* > >>> > >>> *Zayyad A. Said | Chief Executive Officer* > >>> > >>> Suite H32, Delamere Flats - Milimani Road, Nairobi. > >>> > >>> Cell No.: +254 716 615274 | Skype: *zsaid2011* > >>> > >>> Email: zay...@intrasofttechnologies.com > >>> > >>> Schedule Meetings: https://calendly.com/zayyadsaid > >>> > >>> <https://calendly.com/zayyadsaid> > >>> > >>> > >>> *" You can achieve what you want if you just help enough others get > what > >>> they want.."* > >>> > >>> *Note: Save the environment, please don't print this email unless its > >>> really necessary for you to do that.* > >>> > >>> On Sat, Aug 30, 2025, 11:20 Felix van Hove <fvanh...@gmx.de.invalid> > >>> wrote: > >>> > >>>> Let me chip in with a more personal perspective. > >>>> > >>>> I'm following the development of the Mifos web app and - to a certain > >>>> extend - Fineract for a couple of months only. My impression from the > >>>> influx of new features in Fineract is that these are predominantly not > >>>> for microfinance or small entities, which Mifos once set out to > support. > >>>> In fact - Fineract only states that its efforts are also "including > the > >>>> unbanked and underbanked" - not its focus. > >>>> > >>>> I see the deprecation of the Collection Sheet feature in this context. > >>>> How many new features have been added in the last 12 months that help > >>>> the "unbanked"? How many have been added that help larger commercial > >>>> entities and are of no benefit for "the unbanked"? > >>>> > >>>> My personal contributions depend solely on Mifos/Fineract supporting > >>>> efforts for financial inclusion. I regard it as of utter importance > >>>> respective features don't come as a plugin, but first class citizens. > >>>> > >>>> My knowledge regarding fintech is very limited. If I'm wrong or > >>>> misrespresent things, please tell me. > >>>> > >>>> Felix > >>>> > >>>> On 29/08/2025 21:01, James Dailey wrote: > >>>>> Devs - Are we done with this? > >>>>> > >>>>> First, I am NOT ruling out this functionality as important but if no > >>>> one is > >>>>> actually demanding it, and no one is willing to maintain it, then it > >>>>> doesn't get maintained. That is the nature of open source projects. > >>>>> > >>>>> Second, it can happen that an outside vendor (e.g. Mifos) that relies > >>>>> on this Collection Sheet functionality (or any functionality) > >>>> inadvertently > >>>>> drops that from their front end release. Because the tests at > >>>> Fineract do > >>>>> not cover this fully, no one at the Vendor and no one at the Fineract > >>>>> project will see the functionality fail in a build until a customer > or > >>>>> implementer notices. So, tests are vital for ensuring ongoing > >>>>> maintainability. > >>>>> > >>>>> Third, if this type of thing isn't "naturally" part of the core - > then > >>>> it > >>>>> will make a lot more sense to have it be an outside extension - in > >>>> which > >>>>> case the tests have to be written for the API calls, and a Vendor > >>>> should > >>>>> try to get such tests contributed. I could be wrong about this, I > >>>> would > >>>>> be happy to debate where this belongs. > >>>>> > >>>>> @Edward Cable <edca...@mifos.org> - what is the assessment and > status > >>>> of > >>>>> needed functionality and where do you think it should live? > >>>>> > >>>>> Thanks, > >>>>> James > >>>>> > >>>>> On Mon, Aug 18, 2025 at 8:21 AM James Dailey <jdai...@apache.org> > >>>> wrote: > >>>>> > >>>>>> Sifiso - > >>>>>> > >>>>>> Do we have a way to reach the tens of thousands of institutions you > >>>>>> believe are there? > >>>>>> > >>>>>> My belief (just anecdotal information) is that it’s more like a few > >>>>>> hundred institutions and that out of that number, less than 10% are > >>>> on a > >>>>>> recent release. And, of that smaller number, few, if any, are still > >>>> using > >>>>>> Collection Sheets. I could be wrong - I’d like the data! I’d say > >>>> that > >>>>>> vendors can show up with their data here to help make this vendor > >>>> neutral > >>>>>> space more informed. > >>>>>> > >>>>>> If group lending and group-member lending and collection sheets are > >>>> still > >>>>>> needed, then perhaps those project volunteers can contribute the > >>>> needed > >>>>>> updates to keep the functionality useful. > >>>>>> > >>>>>> Thanks > >>>>>> Thanks > >>>>>> > >>>>>> > >>>>>> On Mon, Aug 18, 2025 at 6:48 AM Sifiso Mtetwa < > >>>> sif...@skyburgsystems.org> > >>>>>> wrote: > >>>>>> > >>>>>>> Hi guys, > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> This is an interesting topic. I have been wondering why, in > general, > >>>> we > >>>>>>> seem to be deprecating more and more system functions. The > individual > >>>>>>> collection sheet has served us well over the years and still does, > If > >>>>>>> anything we could improve on its functionality by maybe adding a > bulk > >>>>>>> collection sheet template with little detail compared to a full > loan > >>>>>>> repayment bulk import template. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Fineract is used by tens of thousands of organisations throughout > the > >>>>>>> world and most of them are not on this listing and may not have a > >>>> voice to > >>>>>>> air their concerns. Maybe we can find a way of exposing this thread > >>>> to > >>>>>>> include more voters. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Regards, > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> *From:* James Dailey [mailto:jdai...@apache.org] > >>>>>>> *Sent:* Saturday, 16 August 2025 02:53 > >>>>>>> *To:* dev@fineract.apache.org > >>>>>>> *Subject:* Re: Collection Sheet Deprecation was [Re: Questions and > >>>>>>> Observations on FINERACT-2290 (Collection Sheet API Refactor)] > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Ed > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I agree this needs to be discussed but it is important to > acknowledge > >>>>>>> that THIS Fineract listserv is the only official (and required) > >>>> discussion > >>>>>>> space. It is not the intention to bury anything in “an email > >>>> thread”. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> When I started up Mifos we spent a lot of time looking at > Collection > >>>>>>> Sheets and designing process flows around them. I fully know that > >>>> this > >>>>>>> design direction was important back then in 2002-2006. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> However if there is no one here asking for them to be retained > >>>> besides > >>>>>>> you, then that is a sign that they have perhaps reached an end of > >>>> their > >>>>>>> utility. Or, that the users are not actually here, which is a > >>>> different > >>>>>>> problem. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> So,… If there is a group using collection sheets in production AND > >>>> they > >>>>>>> are not on some permanent forked (old) version, then now is the > time > >>>> to > >>>>>>> speak up. Here. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Generally, I’m fairly certain we can refactor this with an eye > toward > >>>>>>> extracting it from the core. Repeating the logic in two places > >>>> makes no > >>>>>>> sense either. Collection sheets are kind of assembled from > >>>>>>> constituent loans and savings. The balances and due payments > should > >>>> be > >>>>>>> calculated in the underlying components. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> As the system gets restructured we need to decide to keep this at > >>>> all, to > >>>>>>> keep it in a new place, or as some external concept/plug in. Why > >>>> wouldn’t > >>>>>>> we want a separate component? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Cheers > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, Aug 14, 2025 at 4:16 PM Ed Cable <edca...@mifos.org> > wrote: > >>>>>>> > >>>>>>> I'll leave the other thread for discussion of the API versioning > and > >>>>>>> refactoring related to Collection Sheet API but wanted to create a > >>>> separate > >>>>>>> thread regarding the deprecation of the Collection Sheet. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> In general, for this and removal of any functionality, it's > something > >>>>>>> that needs to be discussed openly with the community and with a > vote > >>>> and > >>>>>>> not a decision buried in a mailing list thread. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> For the collection sheet specifically, more thought has to be given > >>>> to > >>>>>>> its deprecation as the centrality and highly coupled nature of the > >>>>>>> collection sheet is being understated as it isn't merely a report > >>>> that's to > >>>>>>> be printed or a form filled out via a mobile application. It's a > >>>>>>> significant portion of the user interface and highly coupled to > many > >>>> of the > >>>>>>> microfinance features around groups/centers/meeting scheduling, > staff > >>>>>>> assignment, etc. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I do agree that from a UI perspective, the collection sheet and > other > >>>>>>> microfinance-centric functionalities and flows should be viewable > >>>> based on > >>>>>>> a configurable setting. As it doesn't lend itself to the optimal > user > >>>>>>> experience for a large portion of current Fineract user base. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I also am supportive of a strategy of slimming Fineract to its core > >>>>>>> services and functionality above core Fineract services and APIs > can > >>>> be > >>>>>>> extracted out. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> So I do think we should give thoughtful consideration to what > >>>> abstracting > >>>>>>> out the collection sheet and corresponding microfinance > >>>> functionality would > >>>>>>> look like and what that effort would entail to abstract it out > >>>> without > >>>>>>> adversely impacting the original user base of the software but it's > >>>> not as > >>>>>>> simple as deprecating these API. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I welcome others' thoughts and inputs as I know even with > >>>> microfinance > >>>>>>> itself, the methodology has evolved and group lending and the > >>>> concept of a > >>>>>>> collection sheet isn't as central as it once was > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Ed > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Wed, Aug 13, 2025 at 6:36 PM Kapil Panchal < > >>>>>>> kapil.panchal.developm...@gmail.com> wrote: > >>>>>>> > >>>>>>> Hi James, > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I can proceed by marking this feature as @Deprecated and/or > >>>> performing a > >>>>>>> safe refactor to remove the API. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> For API versioning I agree to Aleksandar Vidakovic's proposal on > >>>> adapting > >>>>>>> to the SpringBoot v7/Spring Framework v4. If I may, Aleksandar > >>>>>>> Vidakovic takes the lead on this project and I can help to support > >>>> the > >>>>>>> conversion? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> Kapil > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, Aug 14, 2025 at 5:07 AM James Dailey <jdai...@apache.org> > >>>> wrote: > >>>>>>> > >>>>>>> Hi Kapil > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I might suggest looking at this as an opportunity to remove the > >>>>>>> collection sheet entirely from the Fineract namespace. It’s a > legacy > >>>>>>> concept I and others designed a long time ago, originally in 2002 > >>>> based on > >>>>>>> collection sheets we gathered from a dozen countries. It is > strongly > >>>> tied > >>>>>>> to concepts in microfinance field operations, and especially when > >>>> there was > >>>>>>> no data connectivity. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> It belongs perhaps as a sort of external microservice - data > loading > >>>> via > >>>>>>> a bulk import could still be enabled. > >>>>>>> > >>>>>>> The API versioning is a good idea but needs to be more holistic > >>>> across > >>>>>>> the platform I think. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Mon, Aug 11, 2025 at 4:43 AM Ádám Sághy <adamsa...@gmail.com> > >>>> wrote: > >>>>>>> > >>>>>>> Hi Kapil, > >>>>>>> > >>>>>>> Thank you for raising the concerns below. I’ll need some additional > >>>>>>> details to fully understand your points: > >>>>>>> > >>>>>>> 1. *Collection Sheet API* – You mentioned it appears > >>>> non-functional > >>>>>>> and contains several logical errors. > >>>>>>> > >>>>>>> o If it’s indeed not working, that’s a separate, high-priority > >>>>>>> discussion. > >>>>>>> > >>>>>>> o Could you clarify which logical errors you were referring to, > >>>> and > >>>>>>> what specifically makes you think it’s non-functional? > >>>>>>> > >>>>>>> 2. *Service annotations* – You noted that service methods are > >>>> not > >>>>>>> annotated with @Service and that beans are defined manually. > >>>>>>> > >>>>>>> o Are you referring to the > >>>>>>> CollectionSheetWritePlatformServiceJpaRepositoryImpl bean being > >>>> defined > >>>>>>> via configuration? > >>>>>>> > >>>>>>> 3. *Repository wrappers annotated with **@Service* – You > >>>> mentioned > >>>>>>> that this mandates full unit test coverage but that they should > >>>> ideally be > >>>>>>> annotated with @Component. > >>>>>>> > >>>>>>> o Could you point out the exact classes you had in mind? > >>>>>>> > >>>>>>> As for the other points, I agree we can refactor and remove > redundant > >>>>>>> logic—please feel free to suggest specific improvements or start > >>>> work on > >>>>>>> them immediately! > >>>>>>> > >>>>>>> However, be careful by moving anything into the fineract-core… We > are > >>>>>>> aiming to keep it as small as possible as everything is built on > top > >>>> of > >>>>>>> this module! If collection sheet are used for loans and savings - > for > >>>>>>> example - than the recommended move is NOT to move this logic into > >>>> core! > >>>>>>> > >>>>>>> Either: > >>>>>>> > >>>>>>> - we split the logic into fineract-loan and fineract-savings > >>>>>>> > >>>>>>> - Move the logic into a new module > >>>>>>> > >>>>>>> - Leave it in fineract-provider for now > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Shall you have any questions, please let us know! > >>>>>>> > >>>>>>> Regards, > >>>>>>> Adam > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On 2025. Aug 11., at 12:09, Kapil Panchal < > >>>>>>> kapil.panchal.developm...@gmail.com> wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Hi Adam, > >>>>>>> > >>>>>>> I’m currently working on *FINERACT-2290* and have a few questions > >>>> before > >>>>>>> I submit a pull request. > >>>>>>> > >>>>>>> The *Collection Sheet API* in its current state appears > >>>> non-functional > >>>>>>> and contains several logical errors. It seems there was an earlier > >>>> attempt > >>>>>>> to convert from a JSON string request parameter to a class-based > >>>> request > >>>>>>> object, but: > >>>>>>> > >>>>>>> Certain fields are missing. > >>>>>>> > >>>>>>> The serializer is not correctly populating the objects, which > causes > >>>> the > >>>>>>> conditional checks to be bypassed and results in incorrect (false) > >>>>>>> responses. > >>>>>>> > >>>>>>> This change set is *high risk* because it touches most of the loan > >>>> and > >>>>>>> savings product logic. I’ve had to refactor almost all major > methods. > >>>>>>> Extensive integration and end-to-end testing will be required to > >>>> ensure > >>>>>>> there are no regressions, especially in edge cases. At present, > >>>> there are > >>>>>>> no unit or integration tests for this functionality, and test > >>>> creation is > >>>>>>> outside the current ticket scope. I’ve been iterating on this for a > >>>> while, > >>>>>>> and only today have I reached a stable state after several > >>>> experimental and > >>>>>>> build-breaking attempts. > >>>>>>> > >>>>>>> *Key Observations:* > >>>>>>> > >>>>>>> Service methods are not annotated with @Service; instead, beans are > >>>>>>> defined manually. > >>>>>>> > >>>>>>> Repository wrappers are annotated with @Service. This mandates full > >>>> unit > >>>>>>> test coverage for these methods, but they should ideally be > >>>> annotated with > >>>>>>> @Component. > >>>>>>> > >>>>>>> I agree with prior discussions on separating bean validation — > >>>> having a > >>>>>>> dedicated @Component validation class allows the request object to > >>>> handle > >>>>>>> checks independent of database queries. > >>>>>>> > >>>>>>> Validation components can also perform database-related > validations; > >>>>>>> these can be injected into service classes for cleaner > architecture. > >>>>>>> > >>>>>>> Such validation components should be placed in *Fineract-Core* so > >>>> they > >>>>>>> are reusable across modules, reducing future refactoring needs. > >>>>>>> > >>>>>>> The current design of having commands in *Fineract-Core* and > >>>>>>> handlers/services/repositories in respective modules is good — it > >>>> cleanly > >>>>>>> decouples command definition from execution. > >>>>>>> > >>>>>>> There is extensive use of this. in singleton contexts (API, > Service, > >>>>>>> Repository). While not harmful, it’s unnecessary boilerplate. > >>>>>>> > >>>>>>> Multiple redundant intermediate DTOs exist where the request DTO > >>>> itself > >>>>>>> could be reused for data transfer. > >>>>>>> > >>>>>>> I found redundant logic — e.g., a for loop with a break statement > >>>> that > >>>>>>> effectively executes only once; this can be simplified. > >>>>>>> > >>>>>>> Some JDBC template queries use reserved SQL keywords, causing > >>>> exceptions. > >>>>>>> Refactoring these queries resolves the issue and returns proper > >>>> response > >>>>>>> objects. > >>>>>>> > >>>>>>> *Suggestions:* > >>>>>>> > >>>>>>> *Where appropriate, large tickets should be broken into subtasks to > >>>>>>> manage complexity and reviewability.* > >>>>>>> > >>>>>>> It may help to have a dedicated *developer-only Slack channel *for > >>>>>>> technical discussions. This could complement other community spaces > >>>> if > >>>>>>> there’s a need to keep certain conversations more focused. > >>>>>>> > >>>>>>> What are your thoughts on the above? > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Kapil > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> > >>>>>>> *Ed Cable* > >>>>>>> > >>>>>>> President/CEO, Mifos Initiative > >>>>>>> > >>>>>>> edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> *Collectively Creating a World of 3 Billion Maries | * > >>>> http://mifos.org > >>>>>>> <http://facebook.com/mifos> <http://www.twitter.com/mifos> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>> > >>>> > > > > -- -- Paul
