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:
- The Fineract Backoffice UI release candidate is built and tested against
the latest stable state of Fineract's develop branch.
- The release candidate is cut from a specific Backoffice UI release commit,
so the UI release itself remains reproducible and immutable once voted on.
- 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.
- 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
Fineract Release Documentation / Release Process:
https://fineract.apache.org/docs/current/
ASF Voting Process:
https://www.apache.org/foundation/voting.html
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:
- 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
- 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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
- 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
- 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.
- 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
- 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.
- 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.
- 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.
- 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.
- 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
- 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
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
PROPOSED RELEASE PROCESS
Subject to PMC guidance, I propose the following sequence:
- Resolve the remaining release blockers.
- Agree on:
- release version
- supported Fineract version
- source-only vs source + container scope
- Release Manager
- Add/finalize release documentation.
- Update version metadata.
- Regenerate the SBOM from the final RC source tree.
- Perform the final dependency and ASF licensing audit.
- Build the release candidate from a clean checkout.
- Run RAT against the release source archive.
- Verify LICENSE and NOTICE.
- Generate SHA-512 checksums.
- Sign the source archive.
- Verify the signature independently.
- Stage the RC according to the applicable ASF/Fineract release process.
- Send the [VOTE] thread to [email protected].
- Keep the vote open for at least 72 hours under the normal ASF release
policy.
- Collect the required binding votes.
- If approved, publish/promote the release according to ASF policy.
- Publish the release announcement.
- 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
Fineract's existing release documentation:
https://fineract.apache.org/docs/current/
ASF voting process:
https://www.apache.org/foundation/voting.html
REQUEST FOR PMC / COMMUNITY GUIDANCE
Before I proceed with the remaining release engineering work, I would
appreciate guidance on the following:
- Is the community/PMC supportive of proceeding toward the first official
Fineract Backoffice UI release?
- Is 1.0.0 an appropriate version for the first official release, with
1.0.0-RC.1 as the first release candidate?
- Which Fineract version should the release officially target?
- Should the first release be source-only, or should a container image be
included?
- Should the current Blue Oak Model License dependency treatment be
considered acceptable, given LEGAL-639?
- Is the PMC comfortable with me acting as Release Manager for this first
release?
- Are there any additional Fineract-specific release requirements that I
should incorporate before creating the RC?
- 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
ASF Release Policy:
https://www.apache.org/legal/release-policy.html
ASF Voting Process:
https://www.apache.org/foundation/voting.html
Fineract Release Process:
https://fineract.apache.org/docs/current/
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
