Backend (Go/Gin/pgx): env config, pgx pool with retries, Garage S3 client (path-style, region garage), embedded golang-migrate migrations, JWT auth with refresh rotation, albums CRUD, members/roles/invites with no-escalation matrix, photo upload + async imaging/goexif WebP variants, cursor pagination, presigned URLs, likes/comments, SSE hub (album + personal), notifications, share links. Frontend (SvelteKit 2 + Svelte 5 + Tailwind v4): API wrapper with 401 refresh, auth store, all screens, Uploader/PhotoGrid/Lightbox/Comments, SSE client with reconnect + REST catch-up, three themes + system via data-theme. Deploy without Docker: Makefile builds the frontend into backend/static and embeds it (go:embed) into a single statically linked binary; systemd unit and nginx SSE example included. Use gen2brain/webp (-tags nodynamic) instead of cgo kolesa-team/go-webp to keep CGO_ENABLED=0 static builds; design.md/proposal.md updated accordingly.
4.4 KiB
Spec Delta
Purpose
Управление составом альбома, ролями и правами доступа, включая приглашения по токену.
ADDED Requirements
Requirement: Роли участников
Участник альбома SHALL иметь одну из ролей: admin, editor, member, viewer. Владелец выводится из albums.owner_id и не хранится как роль участника.
Scenario: Создатель становится владельцем
- WHEN пользователь создаёт альбом
- THEN система делает его владельцем альбома
Requirement: Матрица прав
Система SHALL ограничивать действия по ролям: загружать фото могут owner/admin/editor/member; удалять чужие фото — owner/admin; удалять свои — owner/admin/editor/member; комментировать — owner/admin/editor/member; скачивать одиночное фото и просматривать — все участники, включая viewer.
Scenario: Наблюдатель не может загружать
- WHEN участник с ролью viewer пытается загрузить фото
- THEN система отклоняет запрос
Scenario: Участник не может удалять чужие фото
- WHEN участник с ролью member пытается удалить фото другого автора
- THEN система отклоняет запрос
Requirement: Приглашение участников
Владелец и админ SHALL иметь возможность создавать инвайт-ссылку с токеном. Редактор SHALL иметь возможность приглашать только на роли member и viewer. Никто не может приглашать на роль выше своей.
Scenario: Админ приглашает участника
- WHEN админ создаёт инвайт на роль member
- THEN система создаёт инвайт с токеном и сроком действия
Scenario: Редактор не может приглашать админа
- WHEN редактор пытается создать инвайт на роль admin или editor
- THEN система отклоняет запрос
Requirement: Принятие инвайта
Пользователь SHALL иметь возможность стать участником, перейдя по токену инвайта.
Scenario: Принятие действующего инвайта
- WHEN пользователь принимает неистёкший инвайт с неисчерпанным лимитом использования
- THEN система добавляет его в состав альбома с ролью из инвайта
Scenario: Принятие истёкшего инвайта
- WHEN пользователь принимает истёкший инвайт
- THEN система отклоняет запрос
Requirement: Смена ролей
Админ SHALL иметь возможность менять роли editor/member/viewer. Владелец SHALL управлять ролями админов. Никто не может менять роль выше своей и не может трогать владельца.
Scenario: Админ меняет роль участника
- WHEN админ повышает участника до editor
- THEN система обновляет роль
Scenario: Админ не может назначить админа
- WHEN админ пытается назначить другому участнику роль admin
- THEN система отклоняет запрос
Requirement: Удаление участника
Владелец и админ SHALL иметь возможность удалять участников, кроме владельца и других админов.
Scenario: Удаление участника
- WHEN админ удаляет участника с ролью member/viewer/editor
- THEN система убирает его из состава альбома