Hi Aleks, I respect your decision regarding this matter. Regarding LLM usage this is something that needs community discussion. so created a dedicated thread for dev list in https://lists.apache.org/thread/hj6qwkczmgc4rmhcho7goqdzgd0652mg
For discussions regarding Angular/Ionic specifically i have updated this in before in https://lists.apache.org/thread/c9xwfomky5vj6tpn25d80orcrw8qq24l thead, I realise I should have been more explicit about this, I had created a dedicated issue in GitHub: https://github.com/apache/fineract-backoffice-ui/issues/160 Maybe if you want to suggest any changes and features that needs to be addressed before release vote you can create a blocker issue on https://github.com/apache/fineract-backoffice-ui/issues/377 (This is the release ticket) Regards Aman On Thu, Aug 27, 2026 at 8:51 PM Aleksandar Vidakovic <[email protected]> wrote: > Hi Aman, > > ... thanks for the answer Aman, but I'm not entirely sure if your response > really addresses my main question if we followed these > https://www.apache.org/legal/generative-tooling.html rules. > > I was thinking about this for a bit, so take this with a pinch of salt, > just my 2 cents: > > I really don't know how to apply "sufficiently creative" (my problem, not > yours), how would we quantify this, especially when we don't know which > parts are coming from which source; what is "sufficient", who decides, is > creativity measured in grams, kilograms, lines of code, time spent > thinking?... that is independent of this contribution itself, just that > text doesn't help me... But neither does the assessment that "others do > this too" help me here... again, that might just be me. To be fair: I don't > think that we really discussed extensively how we want to handle the use of > these new tools in the Fineract community. > > Not too long ago we had all these conference discussions and panels and > talks about new legislation popping up everywhere, about who takes > responsibility when software is being developed. I'm still trying to sort > that stuff out for myself, but what I already know is that an LLM (or its > provider) will not take any responsibility nor can they (look at the small > font disclaimers). > > You said yourself that a considerable chunk of the code was generated by > an LLM (correct me if I'm wrong), fair enough, my personal reservations > aside: we do live in this world with these new tools. There would have been > an opportunity to share how all this was put together, but without any > further hints (your setup, the harness you used, the provider, how much did > this cost, are the costs prohibitive for others in the community etc. etc.) > leaves me with no idea how to review this contribution. > > For me the fundamental difference between watching an LLM generating > something and reviewing your own code is that I can relate and choose to > trust your personal contributions (you specifically, but also in general > everyone on this mailing list)... that's the same as you (specifically and > in general) allow me to merge my own code once in a while. > > Not sure if that is enough of an explanation. If you think I went > fundamentally wrong with any of my assumptions then I'm available to > discuss this further on- or offline if needed. I might also have a comment > or two on some of the choices (Angular, Ionic), but that would have been > something for a discussion on a Jira ticket or on the mailing list before > the vote; I couldn't find references on the mailing list that this > happened, but happy to update myself if you send me links if I missed > something. > > Right now for me this is a: > > -1 > > > On Sat, Aug 22, 2026 at 4:28 PM Aman Mittal <[email protected]> > wrote: > >> Hi Aleks, >> First of all thanks for giving your valuable inputs regarding this. I >> will try to answer what i can. >> Yes, I, like a lot of developers are using AI tooling to help with coding >> and I think that designing a UI is a good use of such tools. That said, the >> contributions are mine: I made the architectural and design decisions, I >> reviewed and rewrote what came back (multiple times), and I take ownership >> of the result and can explain why it is built the way it is. >> >> AGENTS.md is context for AI coding agents and human contributors alike — >> commands, conventions, and what an agent should and should not touch. It >> sits alongside CONTRIBUTING.md, STYLE.md and the threat model in >> security.md. Fineract itself added an AGENTS.md in July for the same class >> of reason, scoped to giving automated scanners the security context, and >> many PMCs has done similar work (HBase, Spark, Cassandra, Solr and Ozone >> have all added an AGENTS.md; Ranger added one alongside a >> threat model in RANGER-5652). The one in backoffice-ui is broader in >> scope because this repository has more agent-written code in it. It will >> keep evolving with the project. >> >> Note that i am only active maintainer right now. So it is a limitation >> that there is no second reviewer who can help out reviewing my code. I >> would very much welcome PMC members or committers reviewing here so that we >> can improve the review process. >> >> Committers are not required to use these AI tools, Agents.md is vendor >> neutral context so it can be used with any llm they like >> >> One of the tools are generally used one is the OPEN API generator as >> FINERACT already have excellent swagger specs to automate API callers and >> breakage part i also mentioned that several times in previous or >> independent thread like this >> https://lists.apache.org/thread/c9xwfomky5vj6tpn25d80orcrw8qq24l , Also >> I choose ionic framework so that we can later repurpose the UI for mobile >> development >> >> Regarding Customization there are lot in terms of technical level, but >> for non tech side - We can plan and implement them as i was more focused on >> polishing and future proofing architecture such as >> >> Module Federation - if any vendor wants to develop and integrate any >> other service (microfrontends) >> >> one is regarding theming - You can handle this via >> src/styles/\_ionic-theme.scss , and dark mode can be maintained via >> src/app/core/services/theme.service.ts >> >> also for painless migration i deliberately used adapter pattern in this >> https://github.com/apache/fineract-backoffice-ui/blob/main/DOCS/ADAPTERS.md >> i am also in work where we can add adapter for more components like >> form-fields and such >> >> Also, there are RBAC-related flags which will only show you the >> components for which you have permission. >> >> Regards, >> Aman >> >> On Sat, Aug 22, 2026 at 3:42 AM James Dailey <[email protected]> wrote: >> >>> Hi Aleks - Thanks for your comments and questions. >>> >>> For my part, we have discussed this topic numerous times over the past >>> two years at least and I've reported it in the quarterly Board updates, as >>> well as presented the need in a number of community calls. I also included >>> it in the proposed topics for the GSOC program which was transparently >>> provided and listed, including in Jira tickets. I believe that at this >>> point, we should focus on the role this proposed BackofficeUI should serve >>> in the community. (I wasn't thinking of an FSIP proposal because when I >>> conceptualized the FSIP concept a few years ago, I was thinking of it as >>> only applying to /fineract/. Perhaps that was an oversight on my part.). >>> In any case, let's discuss the role this plays and how to manage a >>> release process. >>> >>> I'll let Aman respond to some of your other concerns and questions. >>> >>> Thanks >>> >>> James >>> >>> >>> On Fri, Aug 21, 2026 at 6:22 AM Aleksandar Vidakovic < >>> [email protected]> wrote: >>> >>>> Hello everyone, >>>> >>>> ... impressive, but maybe I've missed a few things: >>>> >>>> 1. AI Coding and Apache rules >>>> 2. FSIP for significant improvement to agree approach >>>> 3. UI customisation and future maintenance >>>> 4. Documentation with AI improvements >>>> >>>> >>>> ad 1.: Could you tell me what the current rules concerning AI generated >>>> sources are? I know so much that this whole topic is still in flux, but I >>>> think I understood that purely AI generated code is not copyrightable >>>> (again, disclosure, I'm not a lawyer, even less than a web developer)... >>>> did we decide how we want (have) to handle this? If we did then I missed >>>> that vote. Any indication to which extent the source code comes from a >>>> machine vs human? I was fairly sure that Apache had outlined how they could >>>> be used and that the tools and methods must be declared. >>>> >>>> ad 2.: We are called to vote now when the app is pretty much done, but >>>> when did we discuss and decide to have this new web UI in the first place? >>>> The earliest note on the dev list that I could find was this one >>>> https://www.mail-archive.com/[email protected]/msg11962.html, >>>> but by then things were already in the middle of commit mode... wouldn't >>>> this be a prime example for an FSIP? I thought this would be the kind of >>>> thing we propose there... please correct me if I'm wrong or let me know how >>>> this is different. Disclaimer: I don't consider myself a UI/web developer, >>>> so take the following with a pinch of salt... but I think letting multiple >>>> pairs of eyeballs review the proposal could be helpful, maybe that happened >>>> already?... especially to take some (hard) lessons learned with the >>>> current Angular web UI into account and how difficult customization (in >>>> behavior, display and style) is... my first question here would be: why >>>> Angular again? Not that it's a bad framework (and again: no web dev here), >>>> but there wasn't any other alternative choice out there like Svelte, React, >>>> or something else that I don't have on the radar...? Any particular reasons >>>> we go with the same framework again? >>>> >>>> ad 3.: Another question I'd have is how does this new UI help devs with >>>> customizations (without open heart surgery and messing - too much - with >>>> the upstream code)? At least that's a frequent question that reaches me... >>>> in the current web UI we are limited to changing the "theme" (well, some >>>> primary colors), and that's that without starting to edit source files. >>>> Third party integrators want to adapt this to existing environments (maybe >>>> embed in a portal) and be able to decide if they use all or just some of >>>> the components of the UI... is there any documentation that describes how >>>> we can achieve this? The only (somewhat non dev) documentation I could find >>>> is in this folder >>>> https://github.com/apache/fineract-backoffice-ui/tree/main/DOCS ... >>>> did I miss anything else? >>>> >>>> ad 4.: And looking at these documents... it appears to me that some >>>> kind of AI tool(s) were used creating this user interface (at least this >>>> one is an indicator with my limited knowledge >>>> https://github.com/apache/fineract-backoffice-ui/blob/main/AGENTS.md). >>>> Do we have any information about tools/providers? Are committers/developers >>>> required to use such tools or is this meant to be edited the "classic way" >>>> (or both)? Would be interesting to know if this information/setup can be >>>> shared with the community, because apparently the whole file/folder >>>> structure is very clean and you managed to get this off the ground in an >>>> impressively short amount of time... pretty sure that information would be >>>> most appreciated by third party integrators and maintainers alike... this >>>> would ensure that the further development (or customization) of this >>>> project is as efficient and time saving for everyone involved (would solve >>>> one of the most frequent requests). >>>> >>>> As I say the output is impressive, but I have concerns if we are not >>>> following Apache and Fineract processes, this could be a free for all for >>>> all development in the future. >>>> >>>> Cheers, >>>> >>>> Aleks >>>> >>>> On Fri, Aug 21, 2026 at 12:25 PM Aman Mittal < >>>> [email protected]> wrote: >>>> >>>>> I think we should size the VM with some headroom rather than >>>>> optimizing only for the initial Backoffice UI use case. Since we may want >>>>> to deploy other Fineract components in the future, such as Loan >>>>> Origination >>>>> and the Consumer Facing application, it would be better to have a machine >>>>> that can support these without requiring an early resize. >>>>> >>>>> My initial recommendation would be: >>>>> >>>>> - CPU: 16 vCPU >>>>> - RAM: 64 GB >>>>> - SSD: 500 GB >>>>> - OS: Ubuntu 24.04 LTS >>>>> - Architecture: x86_64 >>>>> - Runtime: Docker Compose initially >>>>> - Swap: 8–16 GB >>>>> >>>>> We can start with Docker Compose and keep the deployment reproducible. >>>>> If we later find that Kubernetes provides a significant benefit for this >>>>> shared environment, we can revisit that separately. >>>>> >>>>> For the ASF VM request, we also need to provide a Project >>>>> Administrator and VM maintainers. Since James is the PMC Chair, I think it >>>>> would make sense to nominate James as the Project Administrator. >>>>> >>>>> Proposed: >>>>> >>>>> Project Administrator: >>>>> >>>>> - James >>>>> >>>>> VM Maintainers: >>>>> >>>>> - James >>>>> - Adam Saghy >>>>> - Adam Monsen >>>>> - Victor Romero >>>>> - Ed Cable >>>>> - Terence Monteiro >>>>> - Aleksandar Vidakovic >>>>> - Aman Mittal >>>>> - Attila Budai >>>>> >>>>> This should give us enough coverage for maintaining the VM and its >>>>> deployment. We can add additional maintainers later if needed. >>>>> >>>>> If I have missed anyone who should be included, please reply here and >>>>> we can add them. Likewise, if anyone listed above would prefer not to take >>>>> on VM maintenance responsibilities, there should be sufficient time to opt >>>>> out before we submit the INFRA ticket. >>>>> >>>>> My preference would be to submit the INFRA request with the larger >>>>> capacity and the above maintainer structure, while keeping the initial >>>>> deployment focused on the shared integration/demo environment rather than >>>>> treating it as production infrastructure. >>>>> >>>>> On Thu, Aug 20, 2026 at 8:09 PM Aman Mittal < >>>>> [email protected]> wrote: >>>>> >>>>>> I would also like to propose creating an Apache-hosted VM for >>>>>> Fineract as a shared integration and demonstration environment. >>>>>> >>>>>> The request would follow the ASF VM process: >>>>>> >>>>>> https://infra.apache.org/vm-for-project.html >>>>>> >>>>>> The initial purpose would be to provide a real Fineract environment >>>>>> for Backoffice UI validation and community testing. We could also use it >>>>>> to >>>>>> demonstrate more of Fineract's capabilities by including supporting >>>>>> services such as: >>>>>> >>>>>> - Fineract backend >>>>>> - PostgreSQL >>>>>> - Fineract Backoffice UI >>>>>> - Keycloak, for demonstrating external identity-provider >>>>>> integration >>>>>> - Mailpit, for demonstrating email/OTP flows without sending real >>>>>> emails >>>>>> - Other supporting dependencies as required >>>>>> - Dedicated access to application/service logs for >>>>>> troubleshooting >>>>>> >>>>>> For the deployment model, I am considering running the services using >>>>>> Docker Compose or Kubernetes inside the VM. This would allow us to have >>>>>> service restart/self-healing capabilities and keep the deployment >>>>>> reasonably reproducible without requiring separate VMs for every >>>>>> component. >>>>>> >>>>>> Before I open the INFRA ticket, I would appreciate recommendations >>>>>> from Infra/community on the appropriate VM specifications, particularly: >>>>>> >>>>>> - CPU >>>>>> - RAM >>>>>> - Disk/storage requirements >>>>>> - Whether separate storage should be requested for database data >>>>>> and logs >>>>>> - Recommended approach for Docker/Kubernetes on an ASF project VM >>>>>> - Recommended logging/monitoring setup >>>>>> - Any requirements or restrictions for exposing a demo >>>>>> environment publicly >>>>>> >>>>>> The ASF VM documentation also requires at least three PMC members to >>>>>> act as maintainers for the VM. I would therefore like to ask PMC members >>>>>> to >>>>>> volunteer as maintainers. Committers are also welcome to participate >>>>>> where >>>>>> the project can vouch for them. >>>>>> >>>>>> The intention is to keep this as a *shared integration/demo >>>>>> environment*, not a production hosting environment. It would give us >>>>>> a stable place to validate the Backoffice UI against a real Fineract >>>>>> deployment and allow community members to try the application before and >>>>>> after the first release. >>>>>> >>>>>> If there is agreement on the approach and we have the required >>>>>> maintainers, I can prepare the INFRA ticket with the proposed >>>>>> architecture >>>>>> and requirements. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Aman >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Aug 19, 2026 at 10:56 AM Aman Mittal < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi James, Anu and Victor, >>>>>>> >>>>>>> Thank you, James, for the suggestions, and Victor for clarifying the >>>>>>> relationship between the two UIs. >>>>>>> >>>>>>> James, I agree that for the first release we should have both >>>>>>> automated validation and manual sanity testing against a real Fineract >>>>>>> backend with a known seed dataset. >>>>>>> >>>>>>> The Backoffice UI currently has three layers of automated testing: >>>>>>> >>>>>>> Real-backend Playwright E2E tests - these run against a real >>>>>>> Fineract backend and database and exercise complete user workflows >>>>>>> through >>>>>>> the UI. The E2E setup creates the required prerequisite data through >>>>>>> Fineract APIs, so the same approach can be reused against a deployed >>>>>>> Fineract test instance. >>>>>>> >>>>>>> Mocked-backend Playwright E2E tests - these validate UI behaviour >>>>>>> independently of backend availability, including navigation, RBAC, >>>>>>> access-denied scenarios, permissions and accessibility. >>>>>>> >>>>>>> Unit tests - these cover Angular services, guards, components and >>>>>>> other application-level logic. >>>>>>> >>>>>>> The real-backend E2E workflows can also automatically generate >>>>>>> videos of the executed scenarios. These are retained as GitHub Actions >>>>>>> artifacts, giving reviewers an additional way to verify the actual UI >>>>>>> flows >>>>>>> rather than relying only on pass/fail results. >>>>>>> >>>>>>> For deploying with seed data - the backend provisioning steps are >>>>>>> already documented in CONTRIBUTING.md: >>>>>>> >>>>>>> docker compose -f deploy/docker-compose-e2e.yml up -d --wait >>>>>>> fineract-db >>>>>>> docker exec -i fineract-db psql -U postgres < deploy/init-db.sql >>>>>>> docker compose -f deploy/docker-compose-e2e.yml up -d >>>>>>> fineract-backend >>>>>>> (wait for https://localhost:8443/fineract-provider/actuator/info to >>>>>>> return 200) >>>>>>> >>>>>>> That gives a clean, empty Fineract instance. It does not, on its >>>>>>> own, include any seed data - init-db.sql only creates the tenant >>>>>>> databases. >>>>>>> >>>>>>> The actual business data (offices, clients, loans, groups, staff, >>>>>>> etc.) is currently produced by a library of composable seeding >>>>>>> functions in >>>>>>> e2e/utils/seed-api.ts, used by individual E2E specs to build exactly the >>>>>>> fixtures each one needs. There is not yet a single script that seeds a >>>>>>> general-purpose demo dataset for manual testing. >>>>>>> >>>>>>> I propose building one as part of release preparation - a short >>>>>>> script that composes the existing seed-api.ts functions into a >>>>>>> representative dataset (an office, a few clients, an active loan, a >>>>>>> group, >>>>>>> a couple of staff/roles) against a freshly provisioned instance. That >>>>>>> gives >>>>>>> manual testers, and the community more broadly, a consistent, >>>>>>> reproducible >>>>>>> environment to test against. I can have this ready alongside the release >>>>>>> documentation. >>>>>>> >>>>>>> Once that is in place, the release-candidate validation flow becomes: >>>>>>> >>>>>>> 1. Provision a clean Fineract backend and database (steps above). >>>>>>> 2. Run the demo-seed script. >>>>>>> 3. Start the Backoffice UI against that instance. >>>>>>> 4. Run the real-backend Playwright E2E suite. >>>>>>> 5. Review test results and generated recordings/artifacts. >>>>>>> 6. Perform manual sanity testing against the same seeded environment. >>>>>>> >>>>>>> James, on the test instance specifically: rather than assume the >>>>>>> Infra-ticket route by default, I would like to ask directly - does >>>>>>> anyone >>>>>>> in the community already have a Fineract test instance (or spare >>>>>>> capacity >>>>>>> on one) we could use for this validation, or should we go ahead and file >>>>>>> the Infra ticket to provision one? If it is the latter, I am happy to >>>>>>> file >>>>>>> it. >>>>>>> >>>>>>> Separately, worth noting: the real-backend E2E workflow we already >>>>>>> run in CI (.github/workflows/e2e.yml) is triggered on workflow_dispatch >>>>>>> as >>>>>>> well as push/pull_request, so it already stands up a real Fineract >>>>>>> backend >>>>>>> via docker-compose on demand, with no persistent hosting required. That >>>>>>> workflow could be extended to also serve as an on-demand validation or >>>>>>> custom-demo run - for example, seeding it with the demo dataset above >>>>>>> and >>>>>>> publishing the results and recordings as run artifacts for reviewers to >>>>>>> check. That makes GitHub Actions a viable, immediately-available option >>>>>>> for >>>>>>> release-candidate validation, independent of whether we also pursue a >>>>>>> persistent Infra-hosted instance for longer-lived community testing. >>>>>>> >>>>>>> I think we should validate the backend first before proceeding with >>>>>>> the shared deployment. The Backoffice UI depends on the Fineract backend >>>>>>> and its API contracts, so having a known-good Fineract backend/test >>>>>>> environment available should be the first step. >>>>>>> >>>>>>> Once that is available and validated, we can deploy the Backoffice >>>>>>> UI against it and provide the environment to community members for >>>>>>> additional manual testing of the release candidate. We can do the >>>>>>> real-backend validation locally first, while working with Infra (or an >>>>>>> existing instance, per the question above) on the shared test >>>>>>> environment >>>>>>> in parallel - this gives us a concrete validation path without making >>>>>>> the >>>>>>> first release dependent on the shared environment being available >>>>>>> immediately. >>>>>>> >>>>>>> For reporting issues, the Backoffice UI GitHub Issues tracker is: >>>>>>> >>>>>>> https://github.com/apache/fineract-backoffice-ui/issues >>>>>>> >>>>>>> The distinction between UI and backend issues is already built into >>>>>>> the issue templates, not something we need to manage by hand each time. >>>>>>> The >>>>>>> bug report template explicitly asks the reporter to confirm "This is a >>>>>>> bug >>>>>>> in the UI, not in the Fineract platform" before it can be submitted, and >>>>>>> both the bug report template and the issue chooser (config.yml) redirect >>>>>>> straight to the ASF Jira project ( >>>>>>> https://issues.apache.org/jira/projects/FINERACT) for anything that >>>>>>> is actually a Fineract Core defect - wrong balances, rejected payloads, >>>>>>> scheduler or accounting behaviour. So testers reporting issues during >>>>>>> the >>>>>>> RC validation should already land in the right place by default. >>>>>>> >>>>>>> I would also welcome a few community members to participate in >>>>>>> manual testing of the release candidate. This would give us additional >>>>>>> confidence that the automated tests cover the basic workflows and that >>>>>>> the >>>>>>> UI is usable from a real user's perspective before the final release >>>>>>> vote. >>>>>>> >>>>>>> Regarding Anu's question - to add to Victor's answer: from the >>>>>>> Backoffice UI side we see the two projects the same way, as >>>>>>> complementary/alternative frontends against the same Apache Fineract >>>>>>> backend, not a replacement relationship. Nothing to add beyond what >>>>>>> Victor >>>>>>> already laid out. >>>>>>> >>>>>>> Regards, >>>>>>> Aman >>>>>>> >>>>>>> On Wed, Aug 19, 2026 at 8:51 AM VICTOR MANUEL ROMERO RODRIGUEZ < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hello Anu, >>>>>>>> >>>>>>>> Thanks for the question. The short response is no, >>>>>>>> https://github.com/apache/fineract-backoffice-ui is not replacing >>>>>>>> https://github.com/openMF/web-app. >>>>>>>> >>>>>>>> Apache Fineract is the core (headless) banking platform / backend >>>>>>>> with REST APIs under the umbrella of the Apache Software Foundation. It >>>>>>>> does not ship a full end-user UI by default (until now). >>>>>>>> >>>>>>>> Mifos X WebApp (from the Mifos Initiative) is an independent >>>>>>>> product distribution built to be an UI for Apache Fineract. >>>>>>>> >>>>>>>> The two UIs are therefore independent alternatives that both talk >>>>>>>> to the same Apache Fineract backend. >>>>>>>> >>>>>>>> UI Maintainer / License Purpose >>>>>>>> openMF/web-app Mifos Initiative (MPL 2.0) The long-standing, >>>>>>>> production-ready/oriented Mifos X web application (the main community >>>>>>>> UI >>>>>>>> for staff/operations) >>>>>>>> apache/fineract-backoffice-ui Apache Fineract project (Apache 2.0) A >>>>>>>> newer official Apache back-office UI focused on role-based workflows >>>>>>>> for >>>>>>>> fintechs, community banks, etc. >>>>>>>> Regards >>>>>>>> >>>>>>>> El mar, 18 ago 2026 a las 20:08, Anu Omotayo via dev (< >>>>>>>> [email protected]>) escribió: >>>>>>>> >>>>>>>>> Hello Community, >>>>>>>>> >>>>>>>>> In terms of direction, is >>>>>>>>> https://github.com/apache/fineract-backoffice-ui replacing >>>>>>>>> https://github.com/openMF/web-app please? >>>>>>>>> >>>>>>>>> Apologies I might have missed the information if it was >>>>>>>>> communicated earlier. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Anu Omotayo >>>>>>>>> >>>>>>>>> On Tuesday, August 18, 2026 at 03:02:19 PM GMT+1, James Dailey < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Ok. Let’s make sure we have some sanity checks on this. It will >>>>>>>>> need to be tested manually to gain some confidence with some set of >>>>>>>>> seed >>>>>>>>> data in the backend. Automated tests are preferred but for a first >>>>>>>>> release >>>>>>>>> I think we also need to be sure that the tests are catching basic >>>>>>>>> features. >>>>>>>>> >>>>>>>>> If that’s in place we should have either local tests or then move >>>>>>>>> to create an infra ticket to host a test instance at Apache. >>>>>>>>> >>>>>>>>> We register the errors on github issues. Please provide that link. >>>>>>>>> >>>>>>>>> >>>>>>>>> Can you help by describing “how to deploy” w seed data? >>>>>>>>> >>>>>>>>> Could a few community members offer to test? >>>>>>>>> >>>>>>>>> Sent from Gmail Mobile >>>>>>>>> >>>>>>>>> On Mon, Aug 17, 2026 at 1:26 PM Aman Mittal < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>> Hi James, >>>>>>>>> >>>>>>>>> Thank you for the +1 and for offering help with Infra and the >>>>>>>>> release keys. >>>>>>>>> >>>>>>>>> Yes, I think the first release candidate should be validated >>>>>>>>> against the latest Fineract develop branch rather than being tied >>>>>>>>> permanently to a particular Fineract release version. >>>>>>>>> >>>>>>>>> For the first release, my proposal is: >>>>>>>>> >>>>>>>>> 1. The Fineract Backoffice UI release candidate is built and >>>>>>>>> tested against the latest stable state of Fineract's develop >>>>>>>>> branch. >>>>>>>>> 2. The release candidate is cut from a specific Backoffice UI >>>>>>>>> release commit, so the UI release itself remains reproducible and >>>>>>>>> immutable >>>>>>>>> once voted on. >>>>>>>>> 3. We document the exact Fineract commit/API specification >>>>>>>>> against which the release candidate was validated. This gives us a >>>>>>>>> clear >>>>>>>>> compatibility baseline without requiring the UI release to be >>>>>>>>> versioned in >>>>>>>>> lockstep with every Fineract release. >>>>>>>>> 4. We already have an automated API-spec synchronization >>>>>>>>> workflow that keeps the Backoffice UI aligned with the latest >>>>>>>>> Fineract >>>>>>>>> develop branch. PR #381 is an example: >>>>>>>>> https://github.com/apache/fineract-backoffice-ui/pull/381 >>>>>>>>> >>>>>>>>> The automation resolves the latest Fineract state, updates the API >>>>>>>>> specification/client when the upstream specification changes, and >>>>>>>>> opens a >>>>>>>>> PR for review rather than silently changing main. >>>>>>>>> >>>>>>>>> We have also previously had automated synchronization PRs for >>>>>>>>> upstream API changes/removals, including the MIX report removal: >>>>>>>>> >>>>>>>>> https://github.com/apache/fineract-backoffice-ui/pulls?q=is%3Apr+is%3Aclosed+label%3Aautomated >>>>>>>>> >>>>>>>>> That change was also discussed by the Fineract community in the >>>>>>>>> dev list thread regarding the deprecation and potential removal of >>>>>>>>> the MIX >>>>>>>>> XBRL module (FINERACT-2670): >>>>>>>>> https://lists.apache.org/thread/mtp88gmrl5d3py5b7g3llo1d7lr023wv >>>>>>>>> >>>>>>>>> This is useful for the release model because it demonstrates that >>>>>>>>> the Backoffice UI can track API changes in Fineract develop through an >>>>>>>>> automated, reviewable process rather than assuming that the API >>>>>>>>> remains >>>>>>>>> static. >>>>>>>>> >>>>>>>>> So I would suggest treating the first release as: >>>>>>>>> >>>>>>>>> Fineract Backoffice UI 1.0.0-RC.1 >>>>>>>>> | >>>>>>>>> +-- validated against Fineract develop at commit <specific commit> >>>>>>>>> +-- API contract recorded at that point >>>>>>>>> +-- release candidate tested against that backend >>>>>>>>> +-- compatibility baseline documented in the release notes >>>>>>>>> >>>>>>>>> After the first release, we can decide whether future UI releases >>>>>>>>> should be aligned with Fineract releases or follow an independent >>>>>>>>> release >>>>>>>>> cadence with a documented compatibility matrix. >>>>>>>>> >>>>>>>>> Regarding a prerelease demo instance, I agree that this would be >>>>>>>>> very useful. ASF Infra supports publishing static sites through GitHub >>>>>>>>> Pages: >>>>>>>>> >>>>>>>>> https://infra.apache.org/github-pages.html >>>>>>>>> >>>>>>>>> The Backoffice UI is already a static frontend, so a >>>>>>>>> prerelease/demo build could be published through GitHub Pages and >>>>>>>>> linked >>>>>>>>> from the release candidate discussion. The main requirement is >>>>>>>>> providing it >>>>>>>>> with a reachable Fineract backend/API; GitHub Pages itself can host >>>>>>>>> the UI, >>>>>>>>> but it cannot provide the Fineract backend. >>>>>>>>> >>>>>>>>> This would allow the community to try the UI/UX before the formal >>>>>>>>> release vote and report issues against the release candidate. >>>>>>>>> >>>>>>>>> So, in short: yes, I propose that 1.0.0-RC.1 be validated against >>>>>>>>> the latest stable Fineract develop branch, with the exact backend/API >>>>>>>>> commit recorded as the compatibility baseline. A prerelease GitHub >>>>>>>>> Pages >>>>>>>>> demo backed by a suitable Fineract instance would be a useful >>>>>>>>> addition for >>>>>>>>> community validation. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Aman >>>>>>>>> >>>>>>>>> On Mon, Aug 17, 2026 at 4:01 PM James Dailey < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>> +1 >>>>>>>>> >>>>>>>>> Thank you Aman. >>>>>>>>> >>>>>>>>> I’ll help as needed w karma on infra and keys >>>>>>>>> >>>>>>>>> TL;DR - Fineract headless backend will be getting a front end UI >>>>>>>>> >>>>>>>>> We need to decide release style - only in synch w latest release >>>>>>>>> of Fineract? release commit for this first one only? >>>>>>>>> >>>>>>>>> As the first thing is a release candidate against latest fineract >>>>>>>>> dev branch , as long as that is stable, ok to validate that. Yes? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Sent from Gmail Mobile >>>>>>>>> >>>>>>>>> On Mon, Aug 17, 2026 at 11:08 AM sujan kumar < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>> Hi Aman, >>>>>>>>> >>>>>>>>> This looks like a solid and thorough release-readiness proposal. I >>>>>>>>> know how much effort and work has gone into getting the Backoffice UI >>>>>>>>> to >>>>>>>>> this stage, and this is a really comprehensive overview of that >>>>>>>>> progress. >>>>>>>>> Great to see the project reaching this level of release readiness. >>>>>>>>> >>>>>>>>> Looking forward to seeing the community and PMC feedback on the >>>>>>>>> next steps. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Sujan >>>>>>>>> >>>>>>>>> On Sun, 16 Aug, 2026, 22:07 Aman Mittal, <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hello Fineract Community, >>>>>>>>> >>>>>>>>> I would like to propose that we start the process for the first >>>>>>>>> official release of the Apache Fineract Backoffice UI. >>>>>>>>> >>>>>>>>> Tracking issue: >>>>>>>>> https://github.com/apache/fineract-backoffice-ui/issues/377 >>>>>>>>> >>>>>>>>> The issue is intended to be the release-readiness and >>>>>>>>> release-tracking umbrella for this work. It does not replace the >>>>>>>>> formal ASF >>>>>>>>> release vote. The release vote will be conducted on >>>>>>>>> [email protected] in accordance with the ASF release policy. >>>>>>>>> >>>>>>>>> ASF Release Policy: >>>>>>>>> https://www.apache.org/legal/release-policy.html >>>>>>>>> <https://www.apache.org/legal/release-policy.html?utm_source=chatgpt.com> >>>>>>>>> >>>>>>>>> Fineract Release Documentation / Release Process: >>>>>>>>> https://fineract.apache.org/docs/current/ >>>>>>>>> <https://fineract.apache.org/docs/current/?utm_source=chatgpt.com> >>>>>>>>> >>>>>>>>> ASF Voting Process: >>>>>>>>> https://www.apache.org/foundation/voting.html >>>>>>>>> <https://www.apache.org/foundation/voting.html?utm_source=chatgpt.com> >>>>>>>>> >>>>>>>>> PROPOSAL >>>>>>>>> >>>>>>>>> I propose that Apache Fineract release the Fineract Backoffice UI >>>>>>>>> as its first official release. >>>>>>>>> >>>>>>>>> The current audit indicates that the project is technically mature >>>>>>>>> enough to proceed toward a release candidate, subject to resolving the >>>>>>>>> remaining release-engineering items and receiving PMC guidance on the >>>>>>>>> release scope, version, compatibility target, licensing questions, and >>>>>>>>> Release Manager. >>>>>>>>> >>>>>>>>> My current proposal is to prepare a 1.0.0 release, initially >>>>>>>>> through a 1.0.0-RC.1 candidate, rather than treating the current main >>>>>>>>> branch as an informal release. >>>>>>>>> >>>>>>>>> WHY RELEASE NOW >>>>>>>>> >>>>>>>>> The Backoffice UI has reached a point where users and integrators >>>>>>>>> can benefit from having a fixed, identifiable version rather than >>>>>>>>> consuming >>>>>>>>> an arbitrary state of main. >>>>>>>>> >>>>>>>>> A release would provide: >>>>>>>>> >>>>>>>>> - A versioned and reproducible source artifact. >>>>>>>>> - A known Fineract API compatibility point. >>>>>>>>> - A documented feature set. >>>>>>>>> - An audited dependency and licensing state. >>>>>>>>> - An SBOM for supply-chain review. >>>>>>>>> - ASF-compliant LICENSE and NOTICE handling. >>>>>>>>> - A documented testing and release process. >>>>>>>>> - A fixed version against which users can report issues. >>>>>>>>> - A clear statement of known limitations and Fineract >>>>>>>>> compatibility. >>>>>>>>> >>>>>>>>> The release is also an opportunity to make the project's security, >>>>>>>>> architecture, dependency, and functional state visible to the wider >>>>>>>>> Fineract community rather than requiring users to inspect the >>>>>>>>> repository >>>>>>>>> themselves. >>>>>>>>> >>>>>>>>> CURRENT PROJECT STATUS >>>>>>>>> >>>>>>>>> A full release-readiness audit was performed against: >>>>>>>>> >>>>>>>>> 0846def1e7ce08cab809752f1808c2aa16b56f62 >>>>>>>>> >>>>>>>>> The audit covered: >>>>>>>>> >>>>>>>>> - Build and packaging >>>>>>>>> - Unit tests >>>>>>>>> - E2E tests >>>>>>>>> - Real-backend E2E tests >>>>>>>>> - RBAC >>>>>>>>> - Navigation authorization >>>>>>>>> - Action-level authorization >>>>>>>>> - API surface >>>>>>>>> - API contract synchronization >>>>>>>>> - GA gates >>>>>>>>> - Dependency licensing >>>>>>>>> - Dependency vulnerabilities >>>>>>>>> - Apache RAT >>>>>>>>> - SBOM generation >>>>>>>>> - CI/CD security >>>>>>>>> - Accessibility >>>>>>>>> - Functional coverage >>>>>>>>> - Documentation >>>>>>>>> - Deployment artifacts >>>>>>>>> - Release hygiene >>>>>>>>> >>>>>>>>> CURRENT VERIFIED RESULTS >>>>>>>>> >>>>>>>>> Unit tests: >>>>>>>>> 1093/1093 + 2/2 MFE project tests. >>>>>>>>> >>>>>>>>> E2E: >>>>>>>>> 325 passed in the initial parallel execution. >>>>>>>>> >>>>>>>>> The 8 failures were investigated rather than simply ignored. They >>>>>>>>> were reproduced successfully under the CI execution model: >>>>>>>>> >>>>>>>>> - backend: 12/12 passed >>>>>>>>> - mocked accessibility: 3/3 passed >>>>>>>>> >>>>>>>>> The failures were attributed to host contention and test isolation >>>>>>>>> under parallel execution. >>>>>>>>> >>>>>>>>> Two-factor authentication E2E: >>>>>>>>> 3/3 passed against a dedicated real-backend stack. >>>>>>>>> >>>>>>>>> GA gates: >>>>>>>>> 8/9 with 0 blocking failures. >>>>>>>>> >>>>>>>>> Build: >>>>>>>>> PASS >>>>>>>>> >>>>>>>>> Lint: >>>>>>>>> PASS >>>>>>>>> >>>>>>>>> Format: >>>>>>>>> PASS >>>>>>>>> >>>>>>>>> i18n mechanism: >>>>>>>>> PASS >>>>>>>>> >>>>>>>>> Internal endpoint validation: >>>>>>>>> PASS >>>>>>>>> >>>>>>>>> Route permission drift check: >>>>>>>>> PASS >>>>>>>>> >>>>>>>>> E2E typecheck: >>>>>>>>> PASS >>>>>>>>> >>>>>>>>> Apache RAT: >>>>>>>>> 706 approved, 0 unapproved. >>>>>>>>> >>>>>>>>> Production dependency licensing: >>>>>>>>> 25/25 packages Category A after removal of eslint-plugin-sonarjs. >>>>>>>>> >>>>>>>>> Production dependency vulnerabilities: >>>>>>>>> 0. >>>>>>>>> >>>>>>>>> RBAC: >>>>>>>>> 223/223 declared permission codes validated against the platform >>>>>>>>> catalogue. >>>>>>>>> >>>>>>>>> Navigation: >>>>>>>>> 119 entries, 104 gated, with route/navigation permission parity >>>>>>>>> enforced. >>>>>>>>> >>>>>>>>> Action authorization: >>>>>>>>> 163 gating sites. >>>>>>>>> 62 of 74 identified write controls are directly gated. >>>>>>>>> The remaining 7 identified ungated controls all lead to routes >>>>>>>>> that are themselves permission protected. >>>>>>>>> >>>>>>>>> API surface: >>>>>>>>> 142 services / 564 operations. >>>>>>>>> >>>>>>>>> Committed API contract: >>>>>>>>> 594 paths / 958 operations. >>>>>>>>> >>>>>>>>> The committed contract was verified against the Fineract head used >>>>>>>>> by the audit with no operation-level additions or removals. >>>>>>>>> >>>>>>>>> Coverage: >>>>>>>>> 73.72% statements excluding the generated OpenAPI client. >>>>>>>>> Security-critical files are at least 90% covered. >>>>>>>>> >>>>>>>>> Functional inventory: >>>>>>>>> 27 functional areas >>>>>>>>> 333 routes >>>>>>>>> 302 components >>>>>>>>> 0 TODO/FIXME/HACK findings >>>>>>>>> No dead routes identified. >>>>>>>>> >>>>>>>>> CURRENT FEATURES AND TECHNICAL ARCHITECTURE >>>>>>>>> >>>>>>>>> The Backoffice UI is an Angular-based application intended to >>>>>>>>> provide an operational interface over Apache Fineract. >>>>>>>>> >>>>>>>>> The architecture currently includes the following major >>>>>>>>> capabilities: >>>>>>>>> >>>>>>>>> 1. Angular application architecture >>>>>>>>> >>>>>>>>> The application uses modern Angular application patterns with >>>>>>>>> standalone components and feature-oriented route organization. >>>>>>>>> >>>>>>>>> The application is divided into functional areas rather than >>>>>>>>> treating the UI as one monolithic feature. >>>>>>>>> >>>>>>>>> Examples include: >>>>>>>>> >>>>>>>>> - Clients >>>>>>>>> - Groups >>>>>>>>> - Centers >>>>>>>>> - Loans >>>>>>>>> - Savings >>>>>>>>> - Shares >>>>>>>>> - Accounting >>>>>>>>> - Products >>>>>>>>> - Tellers >>>>>>>>> - Reports >>>>>>>>> - System/configuration >>>>>>>>> - Users and roles >>>>>>>>> - Notifications >>>>>>>>> - Search >>>>>>>>> - Profile and dashboard functionality >>>>>>>>> >>>>>>>>> >>>>>>>>> 2. API integration >>>>>>>>> >>>>>>>>> The UI uses the Fineract REST API as its backend contract. >>>>>>>>> >>>>>>>>> The generated API client and committed API specification are kept >>>>>>>>> synchronized with Fineract. >>>>>>>>> >>>>>>>>> The project maintains an API-surface manifest containing the >>>>>>>>> operations actually used by the UI. >>>>>>>>> >>>>>>>>> This provides two independent controls: >>>>>>>>> >>>>>>>>> - API contract compatibility >>>>>>>>> - Actual API usage tracking >>>>>>>>> >>>>>>>>> The API surface currently covers: >>>>>>>>> >>>>>>>>> 142 services >>>>>>>>> 564 operations >>>>>>>>> >>>>>>>>> 3. Permission and RBAC model >>>>>>>>> >>>>>>>>> The application uses the Fineract permission vocabulary rather >>>>>>>>> than defining an independent authorization model. >>>>>>>>> >>>>>>>>> The existing AuthService provides: >>>>>>>>> >>>>>>>>> - Individual permission checks >>>>>>>>> - OR semantics >>>>>>>>> - AND semantics >>>>>>>>> - ALL_FUNCTIONS >>>>>>>>> - ALL_FUNCTIONS_READ >>>>>>>>> - Permission normalization >>>>>>>>> >>>>>>>>> Route-level authorization has now been implemented using a >>>>>>>>> permission guard. >>>>>>>>> >>>>>>>>> Navigation permissions and route permissions are checked for drift >>>>>>>>> in CI. >>>>>>>>> >>>>>>>>> The UI also uses action-level permission directives for privileged >>>>>>>>> operations. >>>>>>>>> >>>>>>>>> The important architectural decision is that the frontend RBAC is >>>>>>>>> defence-in-depth. >>>>>>>>> >>>>>>>>> Fineract Core remains the authoritative security boundary. >>>>>>>>> >>>>>>>>> The UI does not attempt to replace backend authorization. >>>>>>>>> >>>>>>>>> 4. Navigation authorization >>>>>>>>> >>>>>>>>> Navigation is data-driven through NAV_CONFIG. >>>>>>>>> >>>>>>>>> Permission-protected navigation entries are filtered according to >>>>>>>>> the user's permissions. >>>>>>>>> >>>>>>>>> The project also has a static validation mechanism ensuring that >>>>>>>>> navigation permissions and route permissions do not silently diverge. >>>>>>>>> >>>>>>>>> This prevents a situation where a menu hides a feature but its >>>>>>>>> route remains unrestricted, or where the navigation exposes something >>>>>>>>> that >>>>>>>>> the route subsequently refuses. >>>>>>>>> >>>>>>>>> 5. Route-level authorization >>>>>>>>> >>>>>>>>> Protected routes now explicitly declare their required Fineract >>>>>>>>> permission. >>>>>>>>> >>>>>>>>> For example, a read-only screen can require a READ_* permission >>>>>>>>> while creation and modification screens require CREATE_* or UPDATE_* >>>>>>>>> permissions. >>>>>>>>> >>>>>>>>> This allows ALL_FUNCTIONS_READ users to access read functionality >>>>>>>>> while preventing them from reaching write forms. >>>>>>>>> >>>>>>>>> Unauthorized navigation results in a dedicated Access Denied page >>>>>>>>> rather than silently returning the user to the dashboard. >>>>>>>>> >>>>>>>>> 6. Action-level authorization >>>>>>>>> >>>>>>>>> Privileged operations such as: >>>>>>>>> >>>>>>>>> - Create >>>>>>>>> - Update >>>>>>>>> - Delete >>>>>>>>> - Approve >>>>>>>>> - Reject >>>>>>>>> - Disburse >>>>>>>>> - Repayment >>>>>>>>> - Waive >>>>>>>>> - Configuration >>>>>>>>> - User management >>>>>>>>> - Role management >>>>>>>>> - Permission management >>>>>>>>> - Teller operations >>>>>>>>> - Accounting operations >>>>>>>>> - Reports >>>>>>>>> >>>>>>>>> are permission-gated where applicable. >>>>>>>>> >>>>>>>>> The existing permission directive is used instead of introducing a >>>>>>>>> second authorization abstraction. >>>>>>>>> >>>>>>>>> 7. Two-factor authentication >>>>>>>>> >>>>>>>>> The application includes two-factor authentication functionality >>>>>>>>> and has dedicated E2E coverage against a real backend. >>>>>>>>> >>>>>>>>> The release audit includes a real-backend test path rather than >>>>>>>>> relying exclusively on mocked authentication. >>>>>>>>> >>>>>>>>> 8. Configuration-driven deployment >>>>>>>>> >>>>>>>>> Runtime configuration is provided separately from the application >>>>>>>>> build. >>>>>>>>> >>>>>>>>> This allows deployments to configure items such as: >>>>>>>>> >>>>>>>>> - Fineract API URL >>>>>>>>> - Tenant >>>>>>>>> - RBAC enablement >>>>>>>>> - Institution features >>>>>>>>> - Developer tooling >>>>>>>>> - Navigation overrides >>>>>>>>> - API-origin restrictions >>>>>>>>> >>>>>>>>> >>>>>>>>> 9. Security controls >>>>>>>>> >>>>>>>>> The project currently includes security-oriented CI checks >>>>>>>>> covering areas such as: >>>>>>>>> >>>>>>>>> - CSP >>>>>>>>> - API-origin restrictions >>>>>>>>> - Authorization header handling >>>>>>>>> - Sanitization/raw HTML checks >>>>>>>>> - GitHub Actions pinning >>>>>>>>> - Workflow permissions >>>>>>>>> - Dependency scanning >>>>>>>>> - License policy >>>>>>>>> - RAT >>>>>>>>> - Signed commits >>>>>>>>> >>>>>>>>> >>>>>>>>> 10. API contract synchronization >>>>>>>>> >>>>>>>>> The project has automation for keeping the API contract >>>>>>>>> synchronized with Fineract. >>>>>>>>> >>>>>>>>> The current design resolves the Fineract container/image to a >>>>>>>>> digest, checks the API specification, regenerates the client when the >>>>>>>>> contract changes, and opens a PR. >>>>>>>>> >>>>>>>>> The backend E2E suite also exercises the UI against Fineract. >>>>>>>>> >>>>>>>>> This is intended to reduce API drift between the UI and Fineract >>>>>>>>> Core. >>>>>>>>> >>>>>>>>> 11. Testing architecture >>>>>>>>> >>>>>>>>> Testing currently consists of: >>>>>>>>> >>>>>>>>> - Angular unit tests >>>>>>>>> - MFE tests >>>>>>>>> - Mocked Playwright E2E tests >>>>>>>>> - Real-backend Playwright E2E tests >>>>>>>>> - Two-factor E2E tests >>>>>>>>> - Accessibility checks >>>>>>>>> - API-surface validation >>>>>>>>> - Route permission drift checks >>>>>>>>> - i18n checks >>>>>>>>> - Build validation >>>>>>>>> - GA checks >>>>>>>>> - Dependency checks >>>>>>>>> - RAT >>>>>>>>> >>>>>>>>> >>>>>>>>> 12. SBOM and supply-chain transparency >>>>>>>>> >>>>>>>>> The project generates CycloneDX 1.6 SBOMs. >>>>>>>>> >>>>>>>>> The release audit generated: >>>>>>>>> >>>>>>>>> - Production SBOM >>>>>>>>> - Full dependency-tree SBOM >>>>>>>>> >>>>>>>>> The SBOMs will be regenerated from the final release candidate so >>>>>>>>> that the PMC can review the exact release contents rather than >>>>>>>>> relying on >>>>>>>>> an SBOM generated from an earlier commit. >>>>>>>>> >>>>>>>>> The current generator does not provide component hashes, and this >>>>>>>>> limitation is documented rather than fabricating hash information. >>>>>>>>> >>>>>>>>> RELEASE ENGINEERING ITEMS REMAINING >>>>>>>>> >>>>>>>>> The main remaining work is release engineering rather than a large >>>>>>>>> feature implementation. >>>>>>>>> >>>>>>>>> 1. Versioning >>>>>>>>> >>>>>>>>> The repository currently reports 0.0.0. >>>>>>>>> >>>>>>>>> The release version needs to be agreed by the PMC/community and >>>>>>>>> then applied consistently to package metadata, generated federation >>>>>>>>> metadata, SBOM metadata and release artifacts. >>>>>>>>> >>>>>>>>> My initial proposal is: >>>>>>>>> >>>>>>>>> 1.0.0-RC.1 >>>>>>>>> >>>>>>>>> followed by: >>>>>>>>> >>>>>>>>> 1.0.0 >>>>>>>>> >>>>>>>>> assuming the RC passes review and the release vote. >>>>>>>>> >>>>>>>>> 2. Release documentation >>>>>>>>> >>>>>>>>> The project needs release documentation covering: >>>>>>>>> >>>>>>>>> - Release preparation >>>>>>>>> - Release candidate creation >>>>>>>>> - Signing >>>>>>>>> - Checksums >>>>>>>>> - SBOM generation >>>>>>>>> - RAT verification >>>>>>>>> - Candidate verification >>>>>>>>> - Staging >>>>>>>>> - Voting >>>>>>>>> - Promotion >>>>>>>>> - Announcement >>>>>>>>> >>>>>>>>> I propose adding RELEASING.md and CHANGELOG.md as part of the >>>>>>>>> release preparation. >>>>>>>>> >>>>>>>>> 3. Release Manager >>>>>>>>> >>>>>>>>> I am willing to nominate myself as Release Manager for the first >>>>>>>>> Backoffice UI release. >>>>>>>>> >>>>>>>>> I have already performed the release-readiness audit and have been >>>>>>>>> working through the release blockers, so I can continue the mechanical >>>>>>>>> preparation and verification work. >>>>>>>>> >>>>>>>>> However, because this is the first official release of this >>>>>>>>> project, I would specifically like PMC guidance and approval before >>>>>>>>> proceeding as Release Manager. >>>>>>>>> >>>>>>>>> If the PMC is comfortable with me acting as RM, I am prepared to: >>>>>>>>> >>>>>>>>> - Prepare the release branch/tag. >>>>>>>>> - Prepare the RC artifacts. >>>>>>>>> - Generate and verify the SBOM. >>>>>>>>> - Run RAT over the actual release artifact. >>>>>>>>> - Generate checksums. >>>>>>>>> - Sign the release artifacts. >>>>>>>>> - Stage the release candidate. >>>>>>>>> - Prepare the release vote email. >>>>>>>>> - Monitor the vote. >>>>>>>>> - Prepare the vote result. >>>>>>>>> - Promote the artifacts after a successful vote. >>>>>>>>> - Prepare the release announcement. >>>>>>>>> >>>>>>>>> I would appreciate guidance from the PMC on whether I should >>>>>>>>> proceed in this role and whether there are any Fineract-specific >>>>>>>>> release >>>>>>>>> steps beyond the documented process that I should follow. >>>>>>>>> >>>>>>>>> 4. Container release scope >>>>>>>>> >>>>>>>>> The current container image builds successfully, but the audit >>>>>>>>> identified a deployment issue: >>>>>>>>> >>>>>>>>> The current nginx configuration does not proxy /api/ requests to >>>>>>>>> Fineract. >>>>>>>>> >>>>>>>>> As a result, an API request can fall through to the SPA shell. >>>>>>>>> >>>>>>>>> The compose configuration also currently points at a third-party >>>>>>>>> public demo host by default. >>>>>>>>> >>>>>>>>> Additionally, the Dockerfile currently uses npm install rather >>>>>>>>> than npm ci. >>>>>>>>> >>>>>>>>> Therefore, I propose that the PMC/community explicitly decide >>>>>>>>> whether the first official release is: >>>>>>>>> >>>>>>>>> A. Source release only >>>>>>>>> >>>>>>>>> or >>>>>>>>> >>>>>>>>> B. Source release plus a convenience container image. >>>>>>>>> >>>>>>>>> If the container is part of the official release scope, the >>>>>>>>> identified deployment issues should be fixed and tested before the >>>>>>>>> vote. >>>>>>>>> >>>>>>>>> The ASF release policy states that official releases are source >>>>>>>>> materials, while convenience binaries/bytecode packages may be >>>>>>>>> distributed >>>>>>>>> alongside the source release when they meet the applicable >>>>>>>>> requirements. >>>>>>>>> >>>>>>>>> Reference: >>>>>>>>> >>>>>>>>> https://www.apache.org/legal/release-policy.html >>>>>>>>> <https://www.apache.org/legal/release-policy.html?utm_source=chatgpt.com> >>>>>>>>> >>>>>>>>> 5. Fineract compatibility >>>>>>>>> >>>>>>>>> The current release-readiness audit validates the UI against >>>>>>>>> Fineract head / 1.16.0-SNAPSHOT. >>>>>>>>> >>>>>>>>> The current evidence does not establish complete compatibility >>>>>>>>> with Fineract 1.15. >>>>>>>>> >>>>>>>>> Therefore, I would like PMC/community guidance on whether the >>>>>>>>> first Backoffice UI release should target: >>>>>>>>> >>>>>>>>> - Fineract 1.16.x / current head >>>>>>>>> - Fineract 1.15.x >>>>>>>>> - A documented compatibility range >>>>>>>>> >>>>>>>>> If 1.15 compatibility is required, I propose adding an API >>>>>>>>> compatibility check and a real-backend E2E matrix against a pinned >>>>>>>>> Fineract >>>>>>>>> 1.15 image before the release vote. >>>>>>>>> >>>>>>>>> DEPENDENCY AND ASF LICENSING REVIEW >>>>>>>>> >>>>>>>>> The dependency audit was performed against the full dependency >>>>>>>>> tree as well as production dependencies. >>>>>>>>> >>>>>>>>> The previous direct devDependency: >>>>>>>>> >>>>>>>>> eslint-plugin-sonarjs >>>>>>>>> >>>>>>>>> was licensed under LGPL-3.0-only. >>>>>>>>> >>>>>>>>> It has been removed and replaced with permissively licensed >>>>>>>>> alternatives under: >>>>>>>>> >>>>>>>>> https://github.com/apache/fineract-backoffice-ui/pull/378 >>>>>>>>> >>>>>>>>> The current audit reports: >>>>>>>>> >>>>>>>>> Category A: >>>>>>>>> 1188 dependencies/components >>>>>>>>> >>>>>>>>> Acknowledged BlueOak-1.0.0: >>>>>>>>> 7 >>>>>>>>> >>>>>>>>> Category B: >>>>>>>>> 2, test-only >>>>>>>>> >>>>>>>>> Category X: >>>>>>>>> 0 >>>>>>>>> >>>>>>>>> Unclassified: >>>>>>>>> 0 >>>>>>>>> >>>>>>>>> Production dependencies: >>>>>>>>> 25 packages, all Category A. >>>>>>>>> >>>>>>>>> The project also added a licensing gate so future dependency >>>>>>>>> changes are classified as: >>>>>>>>> >>>>>>>>> Category A: PASS >>>>>>>>> Category B: REVIEW >>>>>>>>> Category X: BLOCK >>>>>>>>> Unknown: BLOCK >>>>>>>>> >>>>>>>>> There is, however, one licensing question I would like the >>>>>>>>> community/PMC to be aware of: >>>>>>>>> >>>>>>>>> Blue Oak Model License 1.0.0 is not currently included in the ASF >>>>>>>>> Category A list used by our automated policy. >>>>>>>>> >>>>>>>>> There is an existing ASF Legal JIRA issue: >>>>>>>>> >>>>>>>>> LEGAL-639: >>>>>>>>> https://issues.apache.org/jira/browse/LEGAL-639 >>>>>>>>> <https://issues.apache.org/jira/browse/LEGAL-639?utm_source=chatgpt.com> >>>>>>>>> >>>>>>>>> That issue specifically discusses whether Blue Oak Model License >>>>>>>>> 1.0.0 is acceptable for ASF Category A. >>>>>>>>> >>>>>>>>> The license is currently acknowledged by the project's dependency >>>>>>>>> audit rather than silently treated as ordinary Category A. >>>>>>>>> >>>>>>>>> I would appreciate confirmation from the PMC/legal process on >>>>>>>>> whether this treatment is appropriate for Fineract, or whether the >>>>>>>>> project >>>>>>>>> should take any additional action. >>>>>>>>> >>>>>>>>> The dependency itself is currently only present through build >>>>>>>>> tooling and is not part of the production dependency tree. >>>>>>>>> >>>>>>>>> SBOM >>>>>>>>> >>>>>>>>> For the release candidate, I propose that we regenerate the SBOM >>>>>>>>> from the exact release candidate source tree. >>>>>>>>> >>>>>>>>> The release package will therefore have an auditable dependency >>>>>>>>> inventory corresponding to the actual release candidate rather than an >>>>>>>>> earlier working-tree audit. >>>>>>>>> >>>>>>>>> The current audit generated CycloneDX 1.6 SBOMs for: >>>>>>>>> >>>>>>>>> - Production dependencies >>>>>>>>> - Full dependency tree >>>>>>>>> >>>>>>>>> The existing SBOM limitation is that the current generator does >>>>>>>>> not provide component hashes. This will be documented explicitly >>>>>>>>> rather >>>>>>>>> than presenting incomplete data as if it were complete. >>>>>>>>> >>>>>>>>> The final release candidate SBOM will be regenerated and >>>>>>>>> attached/staged with the release evidence for PMC review. >>>>>>>>> >>>>>>>>> FUNCTIONAL READINESS >>>>>>>>> >>>>>>>>> The functional audit currently identifies: >>>>>>>>> >>>>>>>>> 27 functional areas >>>>>>>>> 333 routes >>>>>>>>> 302 components >>>>>>>>> >>>>>>>>> No TODO/FIXME/HACK markers were identified in the functional >>>>>>>>> inventory. >>>>>>>>> >>>>>>>>> The project currently provides functionality around the major >>>>>>>>> Backoffice operational areas, including: >>>>>>>>> >>>>>>>>> - Dashboard >>>>>>>>> - Clients >>>>>>>>> - Groups >>>>>>>>> - Centers >>>>>>>>> - Loans >>>>>>>>> - Savings >>>>>>>>> - Shares >>>>>>>>> - Products >>>>>>>>> - Accounting >>>>>>>>> - Tellers >>>>>>>>> - Reports >>>>>>>>> - System/configuration >>>>>>>>> - Users >>>>>>>>> - Roles >>>>>>>>> - Permissions >>>>>>>>> - Notifications >>>>>>>>> - Search >>>>>>>>> - Profile >>>>>>>>> - Authentication >>>>>>>>> - Two-factor authentication >>>>>>>>> >>>>>>>>> The release audit also specifically verified the relationship >>>>>>>>> between: >>>>>>>>> >>>>>>>>> - UI navigation >>>>>>>>> - Route authorization >>>>>>>>> - Action authorization >>>>>>>>> - Fineract backend authorization >>>>>>>>> >>>>>>>>> The goal is not to claim that every Fineract capability is >>>>>>>>> perfectly represented in the UI. Instead, the release documentation >>>>>>>>> should >>>>>>>>> provide an explicit functional inventory and identify unsupported or >>>>>>>>> known-limited areas. >>>>>>>>> >>>>>>>>> KNOWN FUNCTIONAL LIMITATIONS >>>>>>>>> >>>>>>>>> The current audit identified three functionality limitations >>>>>>>>> caused by verified Fineract PostgreSQL defects rather than UI >>>>>>>>> implementation gaps. >>>>>>>>> >>>>>>>>> GLIM: >>>>>>>>> >>>>>>>>> Creation fails with: >>>>>>>>> >>>>>>>>> null value in column "principal_amount" of relation >>>>>>>>> "glim_accounts" violates not-null constraint >>>>>>>>> >>>>>>>>> GSIM: >>>>>>>>> >>>>>>>>> The request is accepted and returns gsimId: 0, but no parent >>>>>>>>> record is created. >>>>>>>>> >>>>>>>>> Centre collection sheet: >>>>>>>>> >>>>>>>>> command=generateCollectionSheet returns HTTP 500 due to: >>>>>>>>> >>>>>>>>> operator does not exist: boolean = integer >>>>>>>>> >>>>>>>>> These are tracked in: >>>>>>>>> >>>>>>>>> https://github.com/apache/fineract-backoffice-ui/issues/376 >>>>>>>>> >>>>>>>>> They should be documented as known release limitations unless the >>>>>>>>> corresponding Fineract defects are resolved before the release. >>>>>>>>> >>>>>>>>> OTHER KNOWN LIMITATIONS >>>>>>>>> >>>>>>>>> Hindi and Korean translations are currently approximately 20.9% >>>>>>>>> complete. >>>>>>>>> >>>>>>>>> Untranslated strings fall back to English. >>>>>>>>> >>>>>>>>> One WCAG 2.1 AA contrast issue was identified in the current theme: >>>>>>>>> >>>>>>>>> #3498db background >>>>>>>>> #ffffff foreground >>>>>>>>> 3.15:1 contrast ratio >>>>>>>>> >>>>>>>>> No WCAG compliance claim is being made for the release. >>>>>>>>> >>>>>>>>> The RBAC route protection is defence-in-depth. Fineract Core >>>>>>>>> remains the authoritative security boundary. >>>>>>>>> >>>>>>>>> RELEASE ARTIFACT AND VERIFICATION PROPOSAL >>>>>>>>> >>>>>>>>> For the release candidate I propose that we produce: >>>>>>>>> >>>>>>>>> - Source distribution >>>>>>>>> - Detached ASCII-armored signature >>>>>>>>> - SHA-512 checksum >>>>>>>>> - Production SBOM >>>>>>>>> - Full dependency SBOM >>>>>>>>> - Dependency license report >>>>>>>>> - RAT report >>>>>>>>> - Release verification instructions >>>>>>>>> - Changelog >>>>>>>>> - Release notes >>>>>>>>> >>>>>>>>> The candidate should be tested independently from the working tree. >>>>>>>>> >>>>>>>>> RAT should be executed against the actual source distribution, not >>>>>>>>> merely against the Git checkout. >>>>>>>>> >>>>>>>>> The ASF release policy requires supplied packages to be >>>>>>>>> cryptographically signed and requires LICENSE and NOTICE to correctly >>>>>>>>> account for the contents of the package. >>>>>>>>> >>>>>>>>> Reference: >>>>>>>>> >>>>>>>>> https://www.apache.org/legal/release-policy.html >>>>>>>>> <https://www.apache.org/legal/release-policy.html?utm_source=chatgpt.com> >>>>>>>>> >>>>>>>>> PROPOSED RELEASE PROCESS >>>>>>>>> >>>>>>>>> Subject to PMC guidance, I propose the following sequence: >>>>>>>>> >>>>>>>>> 1. Resolve the remaining release blockers. >>>>>>>>> 2. Agree on: >>>>>>>>> - release version >>>>>>>>> - supported Fineract version >>>>>>>>> - source-only vs source + container scope >>>>>>>>> - Release Manager >>>>>>>>> 3. Add/finalize release documentation. >>>>>>>>> 4. Update version metadata. >>>>>>>>> 5. Regenerate the SBOM from the final RC source tree. >>>>>>>>> 6. Perform the final dependency and ASF licensing audit. >>>>>>>>> 7. Build the release candidate from a clean checkout. >>>>>>>>> 8. Run RAT against the release source archive. >>>>>>>>> 9. Verify LICENSE and NOTICE. >>>>>>>>> 10. Generate SHA-512 checksums. >>>>>>>>> 11. Sign the source archive. >>>>>>>>> 12. Verify the signature independently. >>>>>>>>> 13. Stage the RC according to the applicable ASF/Fineract >>>>>>>>> release process. >>>>>>>>> 14. Send the [VOTE] thread to [email protected]. >>>>>>>>> 15. Keep the vote open for at least 72 hours under the normal >>>>>>>>> ASF release policy. >>>>>>>>> 16. Collect the required binding votes. >>>>>>>>> 17. If approved, publish/promote the release according to ASF >>>>>>>>> policy. >>>>>>>>> 18. Publish the release announcement. >>>>>>>>> 19. Tag the final release and update the project >>>>>>>>> documentation. >>>>>>>>> >>>>>>>>> The ASF policy requires at least three binding +1 votes and more >>>>>>>>> positive than negative binding votes for a release, with release votes >>>>>>>>> normally remaining open for at least 72 hours. >>>>>>>>> >>>>>>>>> Reference: >>>>>>>>> >>>>>>>>> https://www.apache.org/legal/release-policy.html >>>>>>>>> <https://www.apache.org/legal/release-policy.html?utm_source=chatgpt.com> >>>>>>>>> >>>>>>>>> Fineract's existing release documentation: >>>>>>>>> >>>>>>>>> https://fineract.apache.org/docs/current/ >>>>>>>>> <https://fineract.apache.org/docs/current/?utm_source=chatgpt.com> >>>>>>>>> >>>>>>>>> ASF voting process: >>>>>>>>> >>>>>>>>> https://www.apache.org/foundation/voting.html >>>>>>>>> <https://www.apache.org/foundation/voting.html?utm_source=chatgpt.com> >>>>>>>>> >>>>>>>>> REQUEST FOR PMC / COMMUNITY GUIDANCE >>>>>>>>> >>>>>>>>> Before I proceed with the remaining release engineering work, I >>>>>>>>> would appreciate guidance on the following: >>>>>>>>> >>>>>>>>> 1. Is the community/PMC supportive of proceeding toward the >>>>>>>>> first official Fineract Backoffice UI release? >>>>>>>>> 2. Is 1.0.0 an appropriate version for the first official >>>>>>>>> release, with 1.0.0-RC.1 as the first release candidate? >>>>>>>>> 3. Which Fineract version should the release officially >>>>>>>>> target? >>>>>>>>> 4. Should the first release be source-only, or should a >>>>>>>>> container image be included? >>>>>>>>> 5. Should the current Blue Oak Model License dependency >>>>>>>>> treatment be considered acceptable, given LEGAL-639? >>>>>>>>> 6. Is the PMC comfortable with me acting as Release Manager >>>>>>>>> for this first release? >>>>>>>>> 7. Are there any additional Fineract-specific release >>>>>>>>> requirements that I should incorporate before creating the RC? >>>>>>>>> 8. Are there any concerns with the current functional scope or >>>>>>>>> known limitations that should prevent an RC from being prepared? >>>>>>>>> >>>>>>>>> RELEASE MANAGER NOMINATION >>>>>>>>> >>>>>>>>> I would like to explicitly volunteer to act as Release Manager for >>>>>>>>> this first release. >>>>>>>>> >>>>>>>>> I am willing to take responsibility for the release preparation >>>>>>>>> and execution, including the audit, candidate preparation, artifact >>>>>>>>> signing, staging, vote coordination, verification and final >>>>>>>>> publication. >>>>>>>>> >>>>>>>>> Since this would be the first official release of the Backoffice >>>>>>>>> UI, I would prefer to proceed only after receiving explicit >>>>>>>>> guidance/approval from the PMC on the mailing list. >>>>>>>>> >>>>>>>>> If the PMC is comfortable with me taking the RM role, I can >>>>>>>>> proceed with the remaining release work on a self-serve basis and >>>>>>>>> keep the >>>>>>>>> community updated through the release tracking issue and dev@ >>>>>>>>> mailing list. >>>>>>>>> >>>>>>>>> TRACKING >>>>>>>>> >>>>>>>>> GitHub release tracking issue: >>>>>>>>> >>>>>>>>> https://github.com/apache/fineract-backoffice-ui/issues/377 >>>>>>>>> >>>>>>>>> Known Fineract functionality issues: >>>>>>>>> >>>>>>>>> https://github.com/apache/fineract-backoffice-ui/issues/376 >>>>>>>>> >>>>>>>>> Dependency licensing change: >>>>>>>>> >>>>>>>>> https://github.com/apache/fineract-backoffice-ui/pull/378 >>>>>>>>> >>>>>>>>> ASF Legal JIRA — Blue Oak Model License: >>>>>>>>> >>>>>>>>> https://issues.apache.org/jira/browse/LEGAL-639 >>>>>>>>> <https://issues.apache.org/jira/browse/LEGAL-639?utm_source=chatgpt.com> >>>>>>>>> >>>>>>>>> ASF Release Policy: >>>>>>>>> >>>>>>>>> https://www.apache.org/legal/release-policy.html >>>>>>>>> <https://www.apache.org/legal/release-policy.html?utm_source=chatgpt.com> >>>>>>>>> >>>>>>>>> ASF Voting Process: >>>>>>>>> >>>>>>>>> https://www.apache.org/foundation/voting.html >>>>>>>>> <https://www.apache.org/foundation/voting.html?utm_source=chatgpt.com> >>>>>>>>> >>>>>>>>> Fineract Release Process: >>>>>>>>> >>>>>>>>> https://fineract.apache.org/docs/current/ >>>>>>>>> <https://fineract.apache.org/docs/current/?utm_source=chatgpt.com> >>>>>>>>> >>>>>>>>> SUMMARY >>>>>>>>> >>>>>>>>> In summary, I believe the Backoffice UI is ready to begin the >>>>>>>>> formal release-preparation process, with the remaining work primarily >>>>>>>>> around release engineering, documentation, artifact scope, >>>>>>>>> compatibility >>>>>>>>> confirmation and PMC decisions. >>>>>>>>> >>>>>>>>> I am not proposing that we vote on the release in this email. >>>>>>>>> >>>>>>>>> I am proposing that we agree on the release direction first, >>>>>>>>> resolve the remaining release blockers, and then prepare a >>>>>>>>> reproducible >>>>>>>>> 1.0.0-RC.1 candidate for formal review and vote. >>>>>>>>> >>>>>>>>> I am also volunteering to serve as Release Manager, subject to PMC >>>>>>>>> guidance and approval. >>>>>>>>> >>>>>>>>> Feedback, concerns, additional release requirements, and guidance >>>>>>>>> on the proposed version, compatibility target and release scope would >>>>>>>>> be >>>>>>>>> very welcome. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Aman Mittal >>>>>>>>> Apache Fineract Contributor/Committer >>>>>>>>> >>>>>>>>>
