Skip to content

fix(dashboard): show custom apps' own logos - #1508

Open
AsadKhanAb17 wants to merge 1 commit into
oblien:mainfrom
AsadKhanAb17:fix/1507-custom-app-logo-url
Open

AsadKhanAb17 wants to merge 1 commit into
oblien:mainfrom
AsadKhanAb17:fix/1507-custom-app-logo-url

Conversation

@AsadKhanAb17

@AsadKhanAb17 AsadKhanAb17 commented Oct 27, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Custom apps now show their own logo. A template logo can be an https: image URL or an image data URI, and it appears everywhere the app is shown, including the project list.

Motivation

#1507: custom apps added with POST /api/apps/custom only got a placeholder icon.

  • AppLogo treated every logo as a simpleicons slug, so https://…/logo.png became a broken https://cdn.simpleicons.org/https://… request.
  • Most screens (the project list, project pages, deployments) render logos by app ID only, and custom apps have no entry in the built-in APP_LOGO map, so their logo was never even looked up.

Related issue

Refs #1507. This implements the first option in the issue: render an https URL or data URI from the template logo. Uploading icons and a writable project favicon are not included.

Changes

  • packages/ui/src/AppLogo.tsx: logoImageSource() accepts only an https: URL or a data:image/(png|jpeg|gif|webp|svg+xml) URI. Any other address-like value (http:, javascript:, paths) shows the fallback instead of a broken request.
  • apps/dashboard/src/components/AppLogo.tsx: the dashboard wrapper, previously a re-export, looks up a custom app's logo from the catalog by ID. That's one cached request per page, and only for IDs that aren't built-in. Any failure falls back to the default icon. The ~15 existing call sites need no change.
  • AddCustomAppModal.tsx: refreshes that cache after a custom app is added.

Verification

# without the packages/ui change
 × renders a custom logo given as an https URL (#1507)
 × renders a custom logo given as an image data URI (#1507)
 × shows the fallback instead of requesting javascript:alert(1)  (+ http:, a/b)
 × shows a custom app's own logo where only its app id is known (#1507)
 Tests  6 failed | 2 passed (8)
# without the dashboard lookup
 × shows a custom app's own logo where only its app id is known (#1507)
# with the fix
$ bun run --cwd apps/dashboard test                 # Test Files 349 passed, Tests 3969 passed
$ cd apps/dashboard && npx tsc --noEmit              # clean;  packages/ui and apps/web typechecks clean
$ bun run errors:check                               # 0 need a reporter

Screenshots

The real dashboard AppLogo rendered from main and from this branch, with the dashboard's CSS, in a project-list card that passes only the app ID. The two custom apps have an https logo and an image data URI:

1507-before-after

Before: both show the generic placeholder. After: each shows its own logo.

Checklist

  • One change per PR — one bug, or one agreed feature, with nothing unrelated bundled in
  • The diff is scoped — no reformatting or lint fixes on lines I wasn't otherwise changing
  • A test fails without this change and passes with it (or I explained above why there isn't one)
  • Dashboard tests, typechecks and the error audit pass locally
  • I understand every line of this diff and can explain it in review

A custom app's template `logo` was only ever treated as a simpleicons slug, so
an image URL became a broken simpleicons request, and screens that show apps
by id (the project list, project pages) never saw a custom app's logo at all.

- AppLogo renders a `logo` that is an https URL or an image data URI, and
  shows the fallback for any other address instead of a broken request.
- The dashboard AppLogo looks up a custom app's logo from the catalog by id
  (one cached request per page), refreshed after a custom app is added.

Refs oblien#1507
@AsadKhanAb17

Copy link
Copy Markdown
Contributor Author

@Hydralerne Please review this PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant