ukaea / ukaea/fds

Device title convention, DeviceUpdate creator fix, and Device metadata on the landing page

Open
#48 0 comments 0 reactions 0 assignees View on GitHub

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.py sets title on both devices (MAST, MAST Upgrade), so a device's dct:title no longer falls back to "Device: mast".
  • docs/data-model/device.md documents the convention correctly at the title row, and its register-a-device examples set title.

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 in title / description / publisher / creator, all already X | None = None, exactly the optionality a PATCH DTO wants. This removes the three hand-copied lines and restores creator.
  • Keep the non-descriptive fields (name / type / began_operations / status / access_level / required_scopes / allowed_idps) as explicit optional declarations. DeviceBase makes several of them required, so it cannot be reused wholesale for a PATCH DTO.
  • Check DatasetUpdate and CollectionUpdate for 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_operations
  • publisher
  • effective_access_level, falling back to access_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; title stays the short display label.
  • A device's JSON-LD dct:title reflects the set title, with no "Device: ..." fallback.
  • DescriptiveMixin docstring describes the title / description split.
  • PATCH /api/v1/devices/{name} can set creator; DeviceUpdate derives its descriptive fields from DescriptiveMixin.
  • DatasetUpdate / CollectionUpdate verified, 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 creator PATCH; uv run --all-extras pytest green; prek run --all-files clean.

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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.