- Shipped
- August 22, 2026 at 10:03 PM UTC
- Author
- Kamo
- Commit
- a4f14d3
A Picture Frame is a member's own photos and videos on their own launchpad, and a member may hang several. This is everything the platform needs to hold one. PictureFrame is a row rather than a key in the member's preference blob because the media are imaging rows associated BY frame id, and an association needs something durable to point at. Member-scoped rather than user-scoped: the bytes are stored under an organization and counted against it, so a frame that followed a person between orgs would put one org's storage on another org's bill. Its appearance is one JSON column — read whole to draw a pane, written whole on save, never queried into — so a designer that grows a bevel next month does not need a DDL change ahead of it. ImageAssocType.PICTURE_FRAME scopes to the FRAME, not the member: several frames are several slideshows, and scoping to the member would make every one of them show everything. It buys content-addressed dedup for free, so a member who puts the same photo in three frames is billed for one. StorageDomain.PICTURE_FRAMES gets its own line rather than being folded into a general bucket. This is the one domain an organization's own people fill a few megabytes at a time with nobody administering it, and an org watching its bill needs to see that separately from the documents its business runs on. The coverage test would have failed the build otherwise, which is the point of it. Rights follow the shape every other widget uses — PICTURE_FRAME_WIDGET plus the four policy children — hung off MANAGE_OWN_BACKGROUND_IMAGES, the right that already governs the personal media a member puts on their own screen. Not a root: a widget whose grant is unreachable from the group that owns its data is a right nobody finds. Ids 229-233; 228 was taken. Taxonomy 219/156/32/31 -> 224/161/32/31.