72 lines
2.5 KiB
Markdown
72 lines
2.5 KiB
Markdown
# Task: Backend release update foundation
|
|
|
|
## Goal
|
|
|
|
Add the backend foundation for curated release update entries and per-user read state.
|
|
|
|
## Feature Spec
|
|
|
|
- `docs/FEATURES/release-communications.md`
|
|
|
|
## Scope
|
|
|
|
- Add a new FastEndpoints module under `backend/src/Socialize.Api/Modules/ReleaseCommunications`.
|
|
- Add release update data entities and EF Core model configuration.
|
|
- Add per-user release update read receipts.
|
|
- Add enum/value support for:
|
|
- category: `Feature`, `Improvement`, `Fix`, `BreakingChange`
|
|
- importance: `Normal`, `Important`
|
|
- audience: `Everyone`, `OrganizationOwners`, `Developers`
|
|
- status: `Draft`, `Published`, `Archived`
|
|
- Add `DbSet` entries and module configuration to `AppDbContext`.
|
|
- Add current-user API endpoints:
|
|
- list visible published release updates
|
|
- get unread visible release updates
|
|
- mark one release update as read
|
|
- mark all visible release updates as read
|
|
- Add developer API endpoints:
|
|
- list all release updates
|
|
- create draft release update
|
|
- get release update detail
|
|
- update draft release update
|
|
- publish release update
|
|
- archive release update
|
|
- Enforce access rules:
|
|
- authenticated users can read only visible published updates
|
|
- only `Developer` users can manage update entries
|
|
- organization-owner audience only appears to users who own at least one organization
|
|
- developer audience only appears to `Developer` users
|
|
- Keep commit import and email digest out of this task.
|
|
|
|
## Likely Files
|
|
|
|
- `backend/src/Socialize.Api/Data/AppDbContext.cs`
|
|
- `backend/src/Socialize.Api/Modules/ReleaseCommunications/**`
|
|
- `backend/tests/Socialize.Tests/**`
|
|
|
|
## Notes
|
|
|
|
- Treat release communications as global SaaS operator data, not workspace-owned workflow data.
|
|
- Use FastEndpoints handlers and keep request/response records near handlers unless local module patterns suggest otherwise.
|
|
- Use FluentValidation for non-trivial input.
|
|
- Do not expose draft entries to non-developer users.
|
|
- Do not expose commit metadata in user-facing DTOs.
|
|
|
|
## Validation
|
|
|
|
```bash
|
|
dotnet build backend/Socialize.slnx
|
|
dotnet test backend/Socialize.slnx
|
|
```
|
|
|
|
## Done When
|
|
|
|
- [x] Developers can create draft release update entries.
|
|
- [x] Developers can publish and archive release updates.
|
|
- [x] Authenticated users can list visible published updates.
|
|
- [x] Audience filtering is enforced.
|
|
- [x] Users can mark one update read.
|
|
- [x] Users can mark all visible updates read.
|
|
- [x] Unread queries only count visible published updates.
|
|
- [x] Backend tests cover access rules and read state.
|