Timing TBD (early May would make it quarterly, and thus quarterly would be "early" Feb, May, Aug, Nov )
MEETING NOTES
Release 1.9 can be done . Aleks agrees to do release management with a code snapshot date of Feb 8th. Artifacts available for review shortly thereafter.
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
Documentation needs additional review in the release process
Link from wiki doc to Ascii doc
Ed to review the documentation artifacts
Aleks to add section in documentation about utility for upgrading (to liquibase) which also means making change to "how to upgrade" documentation
Agreement on priorities for the year - see ROADMAP
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 toolset
then can use OpenPolicy Agent, a very popular security framework for Kubernetes, or similar
advantage is that it is highly flexible.
access control 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 improve performance because of extensive use of AppUser and the implied joins that it creates