Hi Shivaansh, Sorry for the late reply; the majority of them are already implemented. What we can consider is migrating ion-specific primitives behind adapter pattern. I'm not sure if FSIP will be applicable, as this is a non-core Fineract project.
While i am the core maintainer of the Fineract Backoffice UI, I may not decide to mentor this one. Unless we can get more proposals. However community members are open to co-mentoring this. Regards Aman On Wed, Oct 7, 2026 at 1:58 PM Shivaansh Pandey <[email protected]> wrote: > Hi all, > > I'm Shivaansh, a student contributor to fineract-backoffice-ui > (GitHub: shivaansh0610-LUFFY). My work there includes: > - the ADR-0003 i18n adapter migration (#685) > - the ngx-translate v18 upgrade (#654) > - the searchable-select primitive (#637) > > If Fineract takes part in GSoC 2027, I'd like to float an idea early, > so it can be shaped or rejected on the list well before ideas are > finalized in January. > > THE PROBLEM > > In the Backoffice UI 1.0.0 release thread, Aleks raised a question > integrators keep asking: how can a deployment adapt the UI (style, > behaviour, which modules appear, embedding in an existing portal) > without editing upstream source? > https://www.mail-archive.com/[email protected]/msg12489.html > > Today the answer is partial. Runtime configuration covers the API URL, > tenant, institution features and navigation overrides, and > _ionic-theme.scss maps app tokens onto Ionic. But most visual and > behavioural changes still mean patching templates. #530 measures the > gap: about 5,400 <ion-*> occurrences across roughly 296 files, and > about 770 ngModel bindings with no app-owned ControlValueAccessor. > > PROPOSED SCOPE (large, ~350h) > > 1. Theming contract. Make the app's design tokens the complete, > documented theming surface, loadable per deployment at runtime: > colours, typography, logo and branding. Include a default palette that > meets WCAG 2.1 AA, closing the contrast gap noted in the release > audit. > > 2. App-owned UI primitives, following the three-tier design in #530. > Cosmetic and form-control tiers first, with ControlValueAccessors so > the value contract lives in the app. Each primitive gets a stable > data-testid/ARIA test seam so E2E stops asserting against Ionic > internals. > > 3. Extension points. A documented way for a deployment to hide, > replace or add a feature module without forking, building on the > existing navigation overrides and module federation setup. > > 4. Integrator documentation, plus a small example custom deployment > exercised in CI, so the contract cannot silently break. > > Non-goals: no change of framework, no changes to Fineract core, no new > banking features. > > WHY GSOC > > This is mostly non-functional work (architecture, tests, > documentation) rather than new functionality, which matches the > guidance in the Fineract GSoC FAQ. It also lowers maintenance cost for > every downstream integrator. > > QUESTIONS > > - Would the PMC want this on the GSoC 2027 ideas list, or should it go > through an FSIP first? I'm happy to write one. > - Would a committer be willing to mentor it? > - Is the scope right, or should it be split (e.g. theming plus > primitives as a medium-sized project)? > > If there is interest, I can draft the Jira ticket in the format used > for the 2026 ideas. > > Thanks, > Shivaansh Pandey > GitHub: shivaansh0610-LUFFY >
