Hi James, ... good idea, let's further clarify when and how FSIP applies, and when not.
Cheers On Sat, Aug 22, 2026 at 12:12 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 >>>>>>> >>>>>>>
