Serve rooms ("Räume"), which are not courses however the urls read
The account this was built against is in no rooms, so the whole space was invisible and easy to dismiss as an empty endpoint. It is not empty in general — the user had rooms until a teacher removed access — and the UI's naming actively hides the distinction: the sidebar's *Kurse* entry links to `/rooms/courses-overview` and lists courses, while *Räume* links to `/rooms` and lists rooms. A url containing `/rooms` identifies neither. list_rooms and get_room cover the latter. A room holds boards and nothing else, so get_room lists boards for get_board (which already reports "in room" from the board context) plus who else is in it. Room boards report `isVisible`, which the course-page projection does not, so a draft is named as a draft instead of being offered and then answering 403. Rooms also go through the crawl, or they would have become the next blind spot: their boards are indexed, searchable by both the index and the live-crawl path, diffed by what_changed, and mirrored by the CLI under the room's name. The board traversal and the snapshot matcher are now shared between courses and rooms rather than duplicated, which also fixed the live-crawl path silently not searching pad contents. The CLI needed no new command — it is file-centric and inherits rooms through the manifest — but `--course` now accepts a room id, and says so. `kind` gains 'room'; the column is plain TEXT, so no migration. 112 tests. Smoke: 42/42 and 44/44 local, 41/41 and 43/43 live. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
16
docs/API.md
16
docs/API.md
@@ -89,10 +89,18 @@ does not exist. The route that returns a course's lessons/tasks/boards is
|
||||
`GET /api/v3/course-rooms/{roomId}/board`, and its `:roomId` is the *course* id.
|
||||
Nothing in the naming suggests this.
|
||||
|
||||
**`/api/v3/rooms` is a different feature.** "Rooms" are the newer standalone
|
||||
collaboration spaces, unrelated to courses. On this instance the account has
|
||||
none, so `GET /api/v3/rooms` returns `{"data":[]}` — which reads like a broken
|
||||
endpoint but is simply an empty feature.
|
||||
**`/api/v3/rooms` is a different feature, and the UI's naming hides it.** Rooms
|
||||
("Räume") are the newer standalone collaboration spaces. The sidebar's *Kurse*
|
||||
entry links to `/rooms/courses-overview` and lists **courses** (served by
|
||||
`/api/v3/dashboard` + `/api/v3/courses`), while *Räume* links to `/rooms` and
|
||||
lists **rooms** — so a url containing `/rooms` identifies neither.
|
||||
|
||||
A room holds boards and nothing else: no lessons, no tasks. `GET /rooms`
|
||||
answers `{"data":[]}` with no `total`, derived from real memberships, so an
|
||||
empty result means the account is in no rooms — which is also what it looks
|
||||
like after a teacher deletes a room or revokes access. `GET /rooms/{id}/boards`
|
||||
does report `isVisible`, unlike the course-page projection, so a room's draft
|
||||
boards can be identified without trying to open one.
|
||||
|
||||
**`limit` maxima are enforced and mis-documented.** The OpenAPI schema says
|
||||
`maximum: 99`; the runtime validator rejects anything `> 100`. Page at 99 to
|
||||
|
||||
Reference in New Issue
Block a user