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