• Created by Unknown User (jdailey), last updated on Jan 26, 2023 2 minute read

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

THURSDAY Jan 26, 2023 

     0830 PST / 1130 EST / 1730 CEST / 2200 IST 

ZOOM:
https://us02web.zoom.us/j/81248285235?pwd=cjBROTM2T0hHNTdLbU5qeGs2a1ZHUT09


Agenda 

Releases

GitActions 


Release 1.8


Project Roadmap January 2023 (DRAFT) 


Release 1.9  [ Proposal for end of February 2023? ]



Release 1.10 or 1.11? 

  • Batch jobs improvements 
  • Tenant separation and security improvements 
  • Scalability 


--------- 


 NOTES: 

  • Release 1.9 can be done . Aleks can do release management 
  • Documentation needs additional review 
    • Link from wiki doc to Ascii doc 
    • Ed to review the documentation artifacts 
    • Aleks to add section in documentation about utility for upgrading ( backwards compatible)  
    • Aleks highlights that the upgrade documentation should be modified 
  • Timing of 1.9 release?  
    • Better to be out sooner than later 
    • Going through a release will hopefully enhance our bug identification and improve stability. 
    • Release review period will likely identify issues. We will broadcast more thoroughly.  
    • "Code freeze" Feb 8th (dev branch remains active)  - Aleks 
  • Agreement on priorities
    • Quality and security improvements are needed - looking for additional tooling for detecting issues and/or new framework ?  
      • Side discussion by Aleks about using domain specific query building 
      • Was mentioned before, suggest we get to:  QueryDSL or JOOQ (licensing checks out we think) 
    • Already doing something around priority of build on top, so ok for that, but need more documentation.
  • Side discussion around how to do the secure access control model 
    • Security concept proposed by volunteers (at IBM, not members of fineract yet) 
      • Context:  Fineract uses a fairly traditional security model, with access controls and data control mechanisms (like 90% of spring applications out there) 
      • But, when Fineract gets implemented in production somewhere, they (the implementer) tries to implement a security and Auth model on top of this, usually a laborious hack to link this up 
      • So, one recommendation is to REMOVE all security related aspects within Fineract and implement security outside that enforces inside 
        • Factor the security elements out 
        • Implement a model of security and document it , via Security Votas  
        • then can use OpenPolicy Agent, a very popular security framework for Kubernetes, or similar
        • advantage is that it is highly flexible.  
        • communication takes place at an implementation and client level 
        • This would be very complicated to remove (e.g. appUser is utilized throughout, at database layer and Spring) 
        • This would have performance implications and make performance faster b/c of need to use AppUser join everywhere 
  • Improvements list - adding to it 
    • see ROADMAP document 
  • Documentation of the project in automated tool (ASCII doc) → https://fineract.apache.org/docs/current/ 
    • using new approach of in the git next to the code 
    • Business vs technical mishmash 
    • Searchers need Developer tools (how to extend, how to set up, what database, etc) 
    • or User documentation - what does this do?  What is loan product flow?  User interface flow. 
      • Should explain the business logic (can create loan products, change parameters, etc. )
      • Capabilities description 
    • API documentation ideally should be self-documenting / using open-api descriptors (because of lack of type safety, needs manual maintenance of this) 
      • swagger descriptor ... not in synch 
  •  
  •  
  • No labels