Overview
Partner branding data (logos, websites, footer text, social links) is currently hardcoded in the frontend at lib/constants/partners.ts. This means adding or updating a partner requires a code change and deployment. We want to move this config into the database so it can be managed dynamically via the backend API.
Current state
- Frontend
PartnerContent interface defines: name, logo, logoAlt, partnershipLogo, partnershipLogoAlt, bloomGirlIllustration, website, footerLine1, footerLine2, facebook, twitter, instagram, youtube, tiktok, github see here
- Backend
PartnerEntity only has: id, name, isActive (plus relationships) see here
- All 4 endpoints on the partner controller require
SuperAdminAuthGuard see here
IPartner interface exists separately from the entity and is used for response typing see hereUpdatePartnerDto only supports updating the active (boolean) field see here
Action Items
This epic is broken down into 5 sub-tickets in Bloom-Backend and 1 sub-ticket in Bloom-Frontend.
Overview
Partner branding data (logos, websites, footer text, social links) is currently hardcoded in the frontend at
lib/constants/partners.ts. This means adding or updating a partner requires a code change and deployment. We want to move this config into the database so it can be managed dynamically via the backend API.Current state
PartnerContentinterface defines:name,logo,logoAlt,partnershipLogo,partnershipLogoAlt,bloomGirlIllustration,website,footerLine1,footerLine2,facebook,twitter,instagram,youtube,tiktok,githubsee herePartnerEntityonly has:id,name,isActive(plus relationships) see hereSuperAdminAuthGuardsee hereIPartnerinterface exists separately from the entity and is used for response typing see hereUpdatePartnerDtoonly supports updating theactive(boolean) field see hereAction Items
This epic is broken down into 5 sub-tickets in Bloom-Backend and 1 sub-ticket in Bloom-Frontend.