Give the system a banner image, and show member banners in full on public profiles - #321
Merged
Merged
Conversation
…blic profiles A member has had a wide 3:1 banner since June; the system profile only had an avatar. This adds System.banner_url as the exact twin of Member.banner_url at every layer the member one touches: - model + migration (nullable String(500), same storage/trust model) - create/update/read schemas, sharing the avatar normaliser and the signed serve-URL serializer; the update path drops a key that belongs to another account before it is stored, as the avatar does - the public projection (withheld from visitors when external, served when hosted) and the public system view schema - native export/import (with its own clamp cap), the archive import's image restore, and PluralPort (`System.banner_asset_id`, which the spec already defines) - the orphaned-file scan and the references endpoint (`system_banner`) Web: the System profile settings card gains a Banner control under the avatar, using the same upload component and cropper the member editor uses. The public profile renders it above the avatar and name. Also fixes a long-standing display bug on public profiles: the member card gave its banner a fixed 96px height and cropped the image to fit, so the top and bottom of a 3:1 banner never showed on the one page it was framed for. It now renders at the banner's own 3:1 shape, flush to the card's top edge, exactly as the in-app member list and dialog do. Tests: parity lists (native + PluralPort), the PluralPort export mapping, the public key sets, and two new public-profile tests (hosted served / external withheld / owner read unscrubbed; foreign storage key dropped).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two things, both about banners on the public profile.
System banner. A member has had a wide 3:1 banner since June; the system profile only had an avatar. This adds
banner_urlon the system as the exact twin of the member's, at every layer the member one touches: model and migration, create/update/read schemas (same normaliser, same signed serve URL, same drop of a storage key belonging to another account), the public projection (served when hosted, withheld from visitors when it points at an external host), native export and archive import, PluralPort (System.banner_asset_id, already in the spec), and the orphaned-file scan. In the web app the System profile settings card gains a Banner control under the avatar, reusing the member editor's upload component and cropper, and the public profile shows it above the avatar and name.Member banners were being cropped on public profiles. The public member card gave its banner a fixed height and cropped the image to fit, so the top and bottom of the 3:1 banner the owner framed in the cropper never showed on the one page it was framed for. It now renders at the banner's own 3:1 shape, flush to the card's top edge, the same as the in-app member list and dialog. Before and after, same account, same image with edge markers:
Verification. Type-check and lint clean; pure unit suites (parity, PluralPort, signing, cleanup) pass;
selfhosted/public_profilesandselfhosted/nonedocker suites pass. Two new public-profile tests cover the system banner: hosted is served and external is withheld while the owner's own read is untouched, and a storage key under another account's prefix is dropped at write time. Screenshots of all three surfaces (public profile before/after, settings card) were taken against a scratch stack.API clients:
banner_urlonGET/PATCH /v1/systems/meand on the public system view. Additive; nothing existing changes shape.