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