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.
66 lines
4.4 KiB
Markdown
66 lines
4.4 KiB
Markdown
# 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** система убирает его из состава альбома
|