12c8615615
Adds accounting-service PATCH/archive, fiscal helpers, COA templates and setup status, plus SuperApp Accounting UI (DS, scoreboard, masters, vouchers, ledger, ops modules) with session refresh and HTTPS public API URLs. Co-authored-by: Cursor <cursoragent@cursor.com>
40 lines
1.1 KiB
Markdown
40 lines
1.1 KiB
Markdown
# ADR-008: White-Label Branding via Config and Tenant Profile
|
|
|
|
| Field | Value |
|
|
| --- | --- |
|
|
| Status | Accepted |
|
|
| Date | 2025-01-01 |
|
|
| Deciders | Product + Platform Architecture |
|
|
| Supersedes | — |
|
|
| Superseded by | — |
|
|
|
|
## Context
|
|
|
|
The platform must serve many tenant brands without hardcoding colors, logos, or names in source.
|
|
|
|
## Decision
|
|
|
|
Platform brand defaults come from environment / `theme.config.json`. Tenant brand fields live on `tenants` (`primary_color`, `secondary_color`, `logo_url`, `favicon_url`, …). Frontend applies CSS variables. Public tenant-site APIs resolve theme by host for subdomain/custom-domain experiences.
|
|
|
|
## Consequences
|
|
|
|
### Positive
|
|
|
|
- Brand changes without rebuild
|
|
- Tenant onboarding captures brand early
|
|
|
|
### Negative
|
|
|
|
- Runtime theme loading must stay cacheable and tenant-safe
|
|
|
|
## Alternatives Considered
|
|
|
|
1. Hardcoded themes per tenant in frontend builds
|
|
2. Separate theme microservice from day one
|
|
|
|
## Related Documents
|
|
|
|
- [Multi-Tenant Architecture](../multi-tenant-architecture.md)
|
|
- [Deployment Architecture](../deployment-architecture.md)
|
|
- [Next Steps](../../next-steps.md)
|