Files
accounted/extensions/general/_example-branding
Mattsson c86dbdc60d feat(branding): add hiddenNavHrefs to hide sidebar items via env var (#382)
Extends the branding service with a hiddenNavHrefs: string[] field so
forks can hide sidebar entries (e.g. /salary, /customers) without
patching DashboardNav.tsx. Configurable via NEXT_PUBLIC_BRANDING_HIDDEN_NAV
as a comma-separated list. Default is [] — vanilla gnubok unchanged.

Routes remain reachable; this is a nav-visibility switch only. Settings
sidebar is intentionally out of scope.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-29 22:53:34 +02:00
..
2026-04-29 16:32:26 +02:00
2026-04-29 16:32:26 +02:00

Example branding extension

Copy this folder to start a whitelabel fork:

cp -r extensions/general/_example-branding extensions/general/your-brand

Then:

  1. Edit your-brand/manifest.json — set id, exportName, entryPoint, name, description.
  2. Edit your-brand/index.ts — uncomment and set the branding values you want to override.
  3. Drop your assets in your-brand/assets/ (logo.svg, favicon.ico, og.png, etc.). Wire up an extension API route to serve them, or set the asset paths in index.ts to external CDN URLs.
  4. Enable the extension in extensions.config.json:
    { "id": "your-brand", "enabled": true }
    
  5. Run npm run setup:extensions && npm run dev.

See WHITELABEL.md at the repo root for the full fork checklist (env vars, sync workflow, what NOT to change).

Why a separate extension instead of just env vars?

Both work. Env vars are simpler for scalar overrides (app name, support email). An extension lets you bundle assets (logos, icons) and override values that don't fit cleanly into env vars. You can use both — extension overrides win over env vars.