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? ]

• Date , Timezone, handling 
  • DIscussion : https://lists.apache.org/thread/3snx9tvmhj08mr9m1y1521c8h5lj1dq5
• Event Framework 
  • Tickets:   
  • Avro scheme https://github.com/apache/fineract/tree/develop/fineract-avro-schemas 
• SpringBatch and COB
  • Discussion: https://lists.apache.org/thread/yw1dkvb1blw3ko9y02nh2mwkz2s96jqc
  • Tickets 
    
• Chargebacks and fee reversals 
• Business Date handling
• Bug fixes
• Idempotency 

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 
•  
•