StudyLyon — multi-tenant ERP / School Management API. This package designs the
Rooms module client (Flutter, forward-looking spec) against the implemented
NestJS backend. All endpoints, DTO fields, schemas, and wire contracts are derived
directly from src/modules/rooms/**, src/modules/rbac/permissions.constants.ts,
src/database/base.schema.ts + base.repository.ts, and src/common/dto/pagination-query.dto.ts.
No feature is invented; gaps are flagged in §10 and the module Assumptions & Open Questions.
Rooms is the physical-facility registry of an institution: a tenant-scoped catalog of
classrooms, labs, libraries, offices, halls, and other spaces. It is the reference data
that future scheduling surfaces (timetable, bookings) will hang off — a room is only
bookable if it exists as a document in rooms.
Org Admin / Admin Staff: create, edit, filter, and retire the room catalog; keep
codes, types, capacities, buildings, and facilities accurate.
Timetable Coordinator (admin staff): browse rooms by type/building/capacity to plan
where classes run (timetable module (planned) — docs/IMPLEMENTATION_PLAN.md:227).
Teacher / staff: look up a room (location, capacity, facilities) before/while using it.
Platform Super Admin: cross-tenant visibility only via platform tooling; never operates
inside a tenant's room data.
Every class, exam, and (future) booking needs a physical space. Without a room registry,
timetable entries would reference free-text room names — no capacity check, no duplicate
detection, no facility matching. Rooms is the smallest reference module that makes
timetable ((planned)), bookings ((planned)), and exam seating meaningful.
Client scope flag (matches 00-shared/01 §9): native mobile apps are out of Phase 1
(PRODUCT_REQUIREMENTS_DOCUMENT.md:144); these docs are forward-looking full client specs
against the implemented API. Module-specific (forward-looking) marks apply to QR and
room check-in surfaces.
Rooms surface is admin-owned (rooms.create/update/delete), read is broader
(rooms.read); timetable coordinators and teachers read the catalog.
(forward-looking): QR room signage, room check-in/check-out, availability calendar.
(proposed): analytics events (see 05/09) and client-side validation rules — the
backend DTOs impose no min/max on capacity, no length limits on name/code.
The wire contract (envelope, pagination meta, error codes) follows 00-shared/07.
Update path has no duplicate-code check.update() blindly $sets (rooms.service.ts:42-46); changing code to an existing one hits the unique index (room.schema.ts:38) → Mongo E11000 → generic 500. Pre-check + 409 (planned).
Room editor (code change)
OQ-2
RBAC not enforced on the controller. Only JwtAuthGuard (rooms.controller.ts:19); rooms.* perms (permissions.constants.ts:50-53) are declared but no @Permissions guard. Client must gate UI; server guard (planned).
All screens
OQ-3
List has no sort/filter/search.findAll accepts only page/limit (rooms.controller.ts:32); PaginationQueryDto's sort/q (pagination-query.dto.ts:21-29) are unused. Default order is Mongo natural (_id) order — no -createdAt sort. Filters (planned).
Room list
OQ-4
No in-use delete guard.remove() soft-deletes regardless of timetable/bookings references (rooms.service.ts:48-51). Guard on reference counts (planned) with bookings/timetable modules.
Delete dialog
OQ-5
No status (operational), floor, or equipment fields — schema is name/code/capacity/type/building/facilities (room.schema.ts:18-34); facilities: string[] is the closest to equipment. Additions (proposed)/(planned); the client must not invent fields the API won't return.
Room model
OQ-6
No update-room.dto.ts. PATCH reuses CreateRoomDto (rooms.controller.ts:44) so name+code are mandatory on every update. A true partial DTO (planned).
Room editor
OQ-7
Capacity unvalidated — @IsNumber only (create-room.dto.ts:20-23); negative/0/fractional capacities persist. Server @Min(1)(planned); client blocks < 1(proposed) today.
Room form
OQ-8
Delete returns no payload — remove() is Promise<void> (rooms.service.ts:48); client reconciles locally.