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
