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
