Device title convention, DeviceUpdate creator fix, and Device metadata on the landing page
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 0
- Forks
- 1
- Avg merge
- 26m
- Merged PRs (30d)
- 24
Description
Summary
Clean-ups around the title descriptive field on Device (and the shared DescriptiveMixin), plus surfacing Device metadata in the demo UI. Independent of feature work. Deliver on its own branch off main.
Background
title is not Device-specific. It comes from DescriptiveMixin (app/models/mixins.py), which adds the DCAT / Dublin-Core set title / description / publisher / creator to Device, Dataset, and Collection. title maps to dct:title, a human-readable label distinct from the slug name.
Convention, settled 2026-08-11. title is the short display label: mast gives MAST, mastu gives MAST Upgrade. The expanded name and any prose about the machine belong in description. This reverses what this issue originally proposed (expanding the acronym into title). The short form wins because useDeviceLabel feeds title straight into page headings and breadcrumbs, where a full expansion is unusable.
Already delivered since this issue was filed:
demo/seed_metadata.pysetstitleon both devices (MAST,MAST Upgrade), so a device'sdct:titleno longer falls back to"Device: mast".docs/data-model/device.mddocuments the convention correctly at thetitlerow, and its register-a-device examples settitle.
Tasks
1. Give the demo devices real descriptions
description currently only spells out the acronym ("Mega Ampere Spherical Tokamak (MAST)"), which says nothing the title does not, and that redundancy becomes visible once both render on the landing page (task 4). Replace with a real sentence per machine in demo/seed_metadata.py (register_devices_and_shots). Confirm domain facts with the maintainer rather than inventing them.
2. Document the convention in DescriptiveMixin
docs/data-model/device.md already covers this, so only the code side is outstanding. The DescriptiveMixin docstring (app/models/mixins.py) is a bare one-liner that describes none of its four fields. Write up title as the short display label with description carrying the prose, so the convention is visible where the fields are defined.
3. Stop DeviceUpdate dropping creator
Still reproduces on main. DeviceUpdate (app/models/device.py, ~lines 60 to 84) hand-lists its fields and omits creator (which DescriptiveMixin has), so a PATCH cannot update a device's creator.
- Fix: derive the descriptive fields from the mixin.
class DeviceUpdate(DescriptiveMixin, SQLModel): ...pulls intitle / description / publisher / creator, all alreadyX | None = None, exactly the optionality a PATCH DTO wants. This removes the three hand-copied lines and restorescreator. - Keep the non-descriptive fields (
name / type / began_operations / status / access_level / required_scopes / allowed_idps) as explicit optional declarations.DeviceBasemakes several of them required, so it cannot be reused wholesale for a PATCH DTO. - Check
DatasetUpdateandCollectionUpdatefor the identical drift (they use the same mixin) and fix consistently. - Align the approach with ADR-0015 (Pydantic Model Hierarchy); update the ADR if the intended pattern changes.
4. Show Device metadata on the device landing page
demo/ui/src/app/devices/[device]/page.tsx renders the device label as a heading and then goes straight to the tabs. It shows no device metadata at all, while every other entity has a metadata panel.
Mirror the dataset landing page (demo/ui/src/app/devices/[device]/shots/[shot]/datasets/[id]/page.tsx): the "Created At / Media Type / License / Access Level" block, plus the publisher chip next to the heading. Surface the fields DeviceRead already returns and nothing currently displays:
description(the prose from task 1)type,status,began_operationspublishereffective_access_level, falling back toaccess_level
No API change needed. The fields are already on the read model, so this is UI only.
Acceptance criteria
- Demo devices carry a real
description;titlestays the short display label. - A device's JSON-LD
dct:titlereflects the set title, with no"Device: ..."fallback. -
DescriptiveMixindocstring describes thetitle/descriptionsplit. -
PATCH /api/v1/devices/{name}can setcreator;DeviceUpdatederives its descriptive fields fromDescriptiveMixin. -
DatasetUpdate/CollectionUpdateverified, and fixed if they share the bug. - Device landing page shows the metadata listed in task 4, and degrades cleanly when a field is unset.
- Regression test added for the
creatorPATCH;uv run --all-extras pytestgreen;prek run --all-filesclean.
Notes
Doc paths. Resolved: the docs restructure (docs/examples-in-concepts) has merged, so the Device page is docs/data-model/device.md and it carries the tabbed register-a-device examples.
Scope. Standalone change. Branch off main.
Migrated from the internal tracker, where it was #24, opened 2026-07-23.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read app/models/mixins.py and app/models/device.py first, then compare DatasetUpdate and CollectionUpdate. Check demo/seed_metadata.py and demo/ui/src/app/devices/[device]/page.tsx against the dataset landing page, and add the named regression test before running uv run --all-extras pytest and prek run --all-files. Done means the descriptions, mixin documentation, PATCH creator support, and listed device metadata all work without API changes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- fastapi, python, typescript
- Domain
- backend-api-design, documentation, frontend, testing-qa
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 55/100