Public Access
Add Auth-owned product roadmap to README
Captures the Auth slices of the cross-service product roadmap: username + public-profile opt-in, friends graph, email/notification preferences, invitation system enhancements, and GDPR delete/export. Cross-links to the umbrella roadmap in ToBePlayed-Deployment. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
1 parent
34fa22c2b9
commit
4859e74d45
1 file changed
+44
-1
@@ -100,4 +100,47 @@ Tracking known work that is not yet implemented. Each item is independently acti
|
|||||||
|
|
||||||
### Testing
|
### Testing
|
||||||
|
|
||||||
- The abstract test bases under `auth_service.shared.test` already cover unit / integration / persistence / WebMvc slices. Continue adding controller-level `AbstractWebMvcTest` coverage for any new endpoint and persistence-layer tests for any new repository.
|
- The abstract test bases under `auth_service.shared.test` already cover unit / integration / persistence / WebMvc slices. Continue adding controller-level `AbstractWebMvcTest` coverage for any new endpoint and persistence-layer tests for any new repository.
|
||||||
|
|
||||||
|
## 🎯 Product Roadmap (Auth-owned slices)
|
||||||
|
|
||||||
|
The full cross-service product roadmap lives in `ToBePlayed-Deployment/README.md`. This section lists only the slices that land in Auth.
|
||||||
|
|
||||||
|
### 1. Username + public-profile opt-in
|
||||||
|
|
||||||
|
The public profile feature (`tbp.andreas-dahm.eu/u/<username>`) requires:
|
||||||
|
|
||||||
|
- **Unique, human-readable username** distinct from email. Schema: add `username` column on `users` with a unique index and a Flyway migration. Validation: 3–30 chars, `[a-z0-9_-]`, case-insensitive uniqueness.
|
||||||
|
- **`profile_public` flag** (boolean, default `false`) on `users`. Exposed via `PUT /api/users/settings`.
|
||||||
|
- New endpoint: `GET /api/public/users/{username}` returning `{ username, displayName, steamId?, joinedAt }` — the public-facing identity contract that Core's profile endpoint can compose with.
|
||||||
|
|
||||||
|
### 2. Friends / social graph
|
||||||
|
|
||||||
|
Once usernames exist:
|
||||||
|
|
||||||
|
- Schema: `user_friendship(user_id, friend_id, status, requested_at, accepted_at)` with `status` in `PENDING / ACCEPTED / BLOCKED`. Symmetric pair or single-row with a canonical ordering — pick one and stick with it.
|
||||||
|
- Endpoints: `POST /api/users/me/friends?username=...` (request), `POST /api/users/me/friends/{id}/accept`, `DELETE /api/users/me/friends/{id}`, `GET /api/users/me/friends`.
|
||||||
|
- Optional: discovery via the Steam friends API (Auth holds the `steam_id`; the friends list call itself can live in Core's `steam_adapter`, with Auth resolving Steam IDs back to TBP users).
|
||||||
|
|
||||||
|
### 3. Email-driven retention
|
||||||
|
|
||||||
|
The weekly digest, sale alerts, and friend-request notifications all need email infrastructure:
|
||||||
|
|
||||||
|
- Spring's `JavaMailSender` + templating (Thymeleaf or plain interpolation). Configure SMTP via env vars (see Deployment roadmap).
|
||||||
|
- Per-user notification preferences: `notify_digest_weekly`, `notify_sale_alerts`, `notify_friend_requests` — all booleans on `users` with sensible defaults.
|
||||||
|
- Endpoint to render `/api/users/me/notification-preferences` and update via `PUT`.
|
||||||
|
- Triggered by either Core scheduled jobs (digest, sale alerts) calling an internal Auth endpoint, or by a shared message queue if/when one is introduced.
|
||||||
|
|
||||||
|
### 4. Invitation system enhancements
|
||||||
|
|
||||||
|
Today registration validates an `INVALID_INVITATION_CODE` — so invites already exist. Worth surfacing:
|
||||||
|
|
||||||
|
- Endpoint: `POST /api/users/me/invitations` to generate a single-use code (rate-limited, expires after N days). Used for friend invites and onboarding referrals.
|
||||||
|
- Endpoint: `GET /api/users/me/invitations` to list outstanding codes.
|
||||||
|
- Optional: tie invitation acceptance to an auto-friend-request so referred users are already connected on first login.
|
||||||
|
|
||||||
|
### 5. Account deletion / GDPR
|
||||||
|
|
||||||
|
- `DELETE /api/users/me` that soft-deletes (sets `deleted_at`, anonymises PII, keeps the row for foreign-key integrity), or hard-deletes with cascade depending on policy.
|
||||||
|
- Data export endpoint: `GET /api/users/me/export` returning a downloadable JSON bundle of everything Auth knows about the user. Core should expose an equivalent and the Frontend can stitch them.
|
||||||
|
- Document the data-retention policy here once decided.
|
||||||
Reference in new issue
Block a user