chore: add missing multi-level editor for approval workflow, rename projects to campaings.
This commit is contained in:
@@ -31,7 +31,7 @@ Composition registers:
|
||||
|
||||
- web services and auth in `DependencyInjection.cs`
|
||||
- infrastructure in `Infrastructure/DependencyInjection.cs`
|
||||
- domain modules for Identity, Workspaces, Clients, Projects, ContentItems, Assets, Comments, Approvals, Notifications, and Feedback
|
||||
- domain modules for Identity, Workspaces, Clients, Campaigns, ContentItems, Assets, Comments, Approvals, Notifications, and Feedback
|
||||
|
||||
## Data Ownership
|
||||
|
||||
|
||||
@@ -100,7 +100,7 @@ Each report should capture useful debugging context automatically when available
|
||||
- current app URL/path
|
||||
- active workspace id/name
|
||||
- active client id/name
|
||||
- active project id/name
|
||||
- active campaign id/name
|
||||
- active content item id/title
|
||||
- browser user agent
|
||||
- viewport size
|
||||
|
||||
@@ -0,0 +1,43 @@
|
||||
# Task: Align content lifecycle statuses
|
||||
|
||||
## Feature
|
||||
|
||||
`docs/FEATURES/approval-workflow.md`
|
||||
|
||||
## Goal
|
||||
|
||||
Align `ContentItem.Status` with the fixed lifecycle states defined by the approval workflow spec.
|
||||
|
||||
## Scope
|
||||
|
||||
- Replace older review/rework/publishing statuses with the fixed lifecycle set:
|
||||
- `Draft`
|
||||
- `In production`
|
||||
- `In approval`
|
||||
- `Approved`
|
||||
- `Scheduled`
|
||||
- `Published`
|
||||
- Update backend status validation and approval side effects.
|
||||
- Update development seed content statuses.
|
||||
- Update frontend status filters, labels, and manual status actions that referenced retired statuses.
|
||||
|
||||
## Constraints
|
||||
|
||||
- Do not redesign the approval data model in this task.
|
||||
- Do not implement workspace approval configuration, multi-level approval, comments, reminders, or magic links in this task.
|
||||
- Keep the current approval request endpoints working as a compatibility layer until the workflow data model task replaces them.
|
||||
|
||||
## Done When
|
||||
|
||||
- [x] Backend accepts only the fixed lifecycle statuses for manual content status updates.
|
||||
- [x] Creating an approval request moves content to `In approval`.
|
||||
- [x] Recording an approved decision moves content to `Approved`.
|
||||
- [x] Frontend no longer offers or filters against retired content statuses.
|
||||
- [x] Development seed data uses fixed lifecycle statuses.
|
||||
|
||||
## Validation Commands
|
||||
|
||||
```bash
|
||||
dotnet build backend/Socialize.slnx
|
||||
cd frontend && npm run build
|
||||
```
|
||||
@@ -0,0 +1,47 @@
|
||||
# Task: Workspace approval configuration
|
||||
|
||||
## Feature
|
||||
|
||||
`docs/FEATURES/approval-workflow.md`
|
||||
|
||||
## Goal
|
||||
|
||||
Persist workspace-level approval workflow configuration and expose it to workspace settings.
|
||||
|
||||
## Scope
|
||||
|
||||
- Add workspace approval mode:
|
||||
- `None`
|
||||
- `Optional`
|
||||
- `Required`
|
||||
- `Multi-level`
|
||||
- Add approval options:
|
||||
- schedule posts automatically on approval
|
||||
- lock content after approval
|
||||
- send automatic reminders for pending approvals
|
||||
- Return approval configuration from workspace APIs.
|
||||
- Allow workspace managers/admins to update approval configuration.
|
||||
- Replace static workflow settings UI with saved configuration controls.
|
||||
|
||||
## Constraints
|
||||
|
||||
- Do not implement workflow recalculation in this task.
|
||||
- Do not implement multi-level step configuration in this task.
|
||||
- Do not implement automatic scheduling, locking behavior, or reminders in this task; only persist the options.
|
||||
- If backend contracts change, update OpenAPI when the backend is running.
|
||||
|
||||
## Done When
|
||||
|
||||
- [x] Workspace approval config is persisted with defaults.
|
||||
- [x] Workspace API responses include approval config.
|
||||
- [x] Workspace update accepts approval config and validates allowed modes.
|
||||
- [x] Workspace settings UI can edit and save approval config.
|
||||
- [x] Backend and frontend builds pass.
|
||||
|
||||
## Validation Commands
|
||||
|
||||
```bash
|
||||
dotnet build backend/Socialize.slnx
|
||||
dotnet test backend/Socialize.slnx
|
||||
cd frontend && npm run build
|
||||
```
|
||||
@@ -0,0 +1,39 @@
|
||||
# Task: Enforce basic approval modes
|
||||
|
||||
## Feature
|
||||
|
||||
`docs/FEATURES/approval-workflow.md`
|
||||
|
||||
## Goal
|
||||
|
||||
Apply workspace approval mode configuration to the existing single-step approval request flow.
|
||||
|
||||
## Scope
|
||||
|
||||
- Prevent approval requests when workspace approval mode is `None`.
|
||||
- Keep the current approval request endpoints as the one-step compatibility flow for `Optional` and `Required`.
|
||||
- Block manual moves to `Approved` or `Scheduled` for `Required` workspaces until an approval request has an approved decision.
|
||||
- Leave `Optional` approval non-blocking.
|
||||
- Apply the saved "schedule posts automatically on approval" option when a final approval decision is recorded.
|
||||
|
||||
## Constraints
|
||||
|
||||
- Do not implement workflow recalculation in this task.
|
||||
- Do not implement multi-level step configuration in this task.
|
||||
- Do not implement locking behavior, reminder jobs, comments, mentions, reopening, or magic links in this task.
|
||||
- Do not replace the existing approval request data model in this task.
|
||||
|
||||
## Done When
|
||||
|
||||
- [x] Approval mode `None` does not create approval requests.
|
||||
- [x] Approval mode `Optional` allows manual approval/scheduling without approval decisions.
|
||||
- [x] Approval mode `Required` blocks manual approval/scheduling until a completed approval decision exists.
|
||||
- [x] Approved decisions move content to `Scheduled` when auto-scheduling is enabled and the content item has a planned publish date.
|
||||
- [x] Backend tests pass.
|
||||
|
||||
## Validation Commands
|
||||
|
||||
```bash
|
||||
dotnet build backend/Socialize.slnx
|
||||
dotnet test backend/Socialize.slnx
|
||||
```
|
||||
@@ -0,0 +1,71 @@
|
||||
# Task: Multi-level approval step configuration backend
|
||||
|
||||
## Feature
|
||||
|
||||
`docs/FEATURES/approval-workflow.md`
|
||||
|
||||
## Goal
|
||||
|
||||
Persist workspace-level multi-level approval step configuration and expose it through workspace settings APIs.
|
||||
|
||||
## Context
|
||||
|
||||
The workspace can currently select `Multi-level`, but there is no backend model or API surface for defining the ordered steps that make multi-level approval usable.
|
||||
|
||||
## Scope
|
||||
|
||||
- Add a workspace-owned approval step configuration data model.
|
||||
- Each configured step must include:
|
||||
- display name
|
||||
- sort order
|
||||
- target type: `Role`, `Membership`, or `Member`
|
||||
- target value
|
||||
- required approver count
|
||||
- Add EF Core configuration and migration.
|
||||
- Return configured approval steps from workspace APIs.
|
||||
- Allow workspace managers/admins to replace the configured step list for a workspace.
|
||||
- Validate:
|
||||
- `Multi-level` workspaces must have at least one step.
|
||||
- step names are required and bounded.
|
||||
- target type is one of `Role`, `Membership`, or `Member`.
|
||||
- role targets use known workspace roles.
|
||||
- membership targets use known membership categories.
|
||||
- member targets reference a user with workspace access.
|
||||
- required approver count is at least 1.
|
||||
- sort order is stable and unique per workspace.
|
||||
|
||||
## Constraints
|
||||
|
||||
- Do not implement active approval workflow instance recalculation in this task.
|
||||
- Do not implement approval step execution or per-step approval decisions in this task.
|
||||
- Do not implement reminders, comments, reopening, or magic links in this task.
|
||||
- Keep backend feature code under `backend/src/Socialize.Api/Modules/Approvals` or `Modules/Workspaces` according to existing ownership patterns.
|
||||
- If backend contracts change, update OpenAPI when the backend is running.
|
||||
|
||||
## Likely Files
|
||||
|
||||
- `backend/src/Socialize.Api/Modules/Approvals/Data/*`
|
||||
- `backend/src/Socialize.Api/Modules/Approvals/Handlers/*`
|
||||
- `backend/src/Socialize.Api/Modules/Workspaces/Handlers/*`
|
||||
- `backend/src/Socialize.Api/Data/AppDbContext.cs`
|
||||
- `backend/src/Socialize.Api/Migrations/*`
|
||||
- `backend/tests/Socialize.Tests/Approvals/*`
|
||||
- `shared/openapi/openapi.json`
|
||||
- `frontend/src/api/schema.d.ts`
|
||||
|
||||
## Done When
|
||||
|
||||
- [x] Multi-level step configuration is persisted per workspace.
|
||||
- [x] Workspace responses include configured approval steps.
|
||||
- [x] Managers/admins can save an ordered list of approval steps.
|
||||
- [x] Invalid target types, target values, counts, and empty multi-level configurations are rejected.
|
||||
- [x] Backend tests cover validation and persistence rules.
|
||||
- [x] OpenAPI and generated frontend schema are updated.
|
||||
|
||||
## Validation Commands
|
||||
|
||||
```bash
|
||||
dotnet build backend/Socialize.slnx
|
||||
dotnet test backend/Socialize.slnx
|
||||
./scripts/update-openapi.sh
|
||||
```
|
||||
@@ -0,0 +1,63 @@
|
||||
# Task: Multi-level workflow editor UI
|
||||
|
||||
## Feature
|
||||
|
||||
`docs/FEATURES/approval-workflow.md`
|
||||
|
||||
## Goal
|
||||
|
||||
Add a workspace settings workflow editor that lets managers/admins configure multi-level approval steps.
|
||||
|
||||
## Context
|
||||
|
||||
The workspace settings screen currently saves the approval mode and simple options, but `Multi-level` has no step editor. Users can select the mode without any way to define who approves each step.
|
||||
|
||||
## Scope
|
||||
|
||||
- Add a feature-owned workflow editor component under `frontend/src/features/workspaces/components/`.
|
||||
- Show the editor only when approval mode is `Multi-level`.
|
||||
- Allow users to add, remove, reorder, and edit approval steps.
|
||||
- For each step, support:
|
||||
- display name
|
||||
- target type: role, membership, or member
|
||||
- target value selector appropriate to the selected type
|
||||
- required approver count
|
||||
- Load available workspace members from the existing workspace members API.
|
||||
- Use existing workspace store/API patterns to save the full workflow configuration.
|
||||
- Show inline validation before save for missing names, missing targets, and invalid required approver count.
|
||||
- Keep the existing simple approval options in the same workflow settings tab.
|
||||
- Update English and French locale strings.
|
||||
|
||||
## Constraints
|
||||
|
||||
- Do not implement the backend in this task; depend on the API contract from task 005.
|
||||
- Do not implement approval execution, recalculation, reminders, comments, reopening, or magic links in this task.
|
||||
- Keep feature-owned code under `frontend/src/features/workspaces`.
|
||||
- Use `frontend/src/config.js` for runtime config if any runtime config is needed.
|
||||
- Preserve the shared Axios client in `frontend/src/plugins/api.js`.
|
||||
- Do not create a marketing or explanatory page; this is an app settings editor.
|
||||
|
||||
## Likely Files
|
||||
|
||||
- `frontend/src/features/workspaces/views/WorkspaceSettingsView.vue`
|
||||
- `frontend/src/features/workspaces/components/ApprovalWorkflowEditor.vue`
|
||||
- `frontend/src/features/workspaces/stores/workspaceStore.js`
|
||||
- `frontend/src/locales/en.json`
|
||||
- `frontend/src/locales/fr.json`
|
||||
- `frontend/src/api/schema.d.ts`
|
||||
|
||||
## Done When
|
||||
|
||||
- [ ] Selecting `Multi-level` reveals an approval step editor.
|
||||
- [ ] Users can add, remove, reorder, and edit steps.
|
||||
- [ ] Role, membership, and member target selectors are available.
|
||||
- [ ] The editor saves and reloads persisted workflow configuration.
|
||||
- [ ] UI prevents saving invalid multi-level configurations.
|
||||
- [ ] Frontend build passes.
|
||||
|
||||
## Validation Commands
|
||||
|
||||
```bash
|
||||
cd frontend
|
||||
npm run build
|
||||
```
|
||||
@@ -0,0 +1,64 @@
|
||||
# Task: Execute multi-level approval workflow
|
||||
|
||||
## Feature
|
||||
|
||||
`docs/FEATURES/approval-workflow.md`
|
||||
|
||||
## Goal
|
||||
|
||||
Use configured multi-level approval steps when content enters approval and when approvers record decisions.
|
||||
|
||||
## Context
|
||||
|
||||
Tasks 005 and 006 make multi-level approval configurable. This task makes that configuration affect runtime approval behavior.
|
||||
|
||||
## Scope
|
||||
|
||||
- Create or update the approval workflow runtime model so a `ContentItem` has at most one active approval workflow instance.
|
||||
- Instantiate ordered approval steps from workspace configuration when content enters `In approval`.
|
||||
- Track step status as `Pending` or `Approved`.
|
||||
- Allow approval only on the current pending step.
|
||||
- Require each step's configured approver count before the step becomes approved.
|
||||
- Advance to the next step after the current step is approved.
|
||||
- Move content to `Approved` or `Scheduled` after the final step completes, following existing workspace options.
|
||||
- Preserve approval history.
|
||||
- Notify current step approvers when a step becomes current.
|
||||
- Notify publish-capable users when final approval completes.
|
||||
- Keep the existing single-step `Optional` and `Required` flows working.
|
||||
|
||||
## Constraints
|
||||
|
||||
- Do not implement configuration recalculation for already-active workflows in this task unless the task is explicitly expanded.
|
||||
- Do not implement reminders, comments, mentions, reopening, or magic links in this task.
|
||||
- Do not delete previous approval history.
|
||||
- Preserve workspace scoping and access checks.
|
||||
|
||||
## Likely Files
|
||||
|
||||
- `backend/src/Socialize.Api/Modules/Approvals/Data/*`
|
||||
- `backend/src/Socialize.Api/Modules/Approvals/Handlers/*`
|
||||
- `backend/src/Socialize.Api/Modules/Approvals/Services/*`
|
||||
- `backend/src/Socialize.Api/Modules/ContentItems/Handlers/*`
|
||||
- `backend/src/Socialize.Api/Modules/Notifications/*`
|
||||
- `backend/src/Socialize.Api/Migrations/*`
|
||||
- `backend/tests/Socialize.Tests/Approvals/*`
|
||||
- `frontend/src/features/content/views/ContentItemDetailView.vue`
|
||||
- `frontend/src/features/reviews/*`
|
||||
|
||||
## Done When
|
||||
|
||||
- [x] Content entering approval creates a runtime approval workflow with ordered steps.
|
||||
- [x] Only the current pending step can be approved.
|
||||
- [x] Required approver counts are enforced.
|
||||
- [x] Final approval updates content status according to workspace options.
|
||||
- [x] Approval history remains available after completion.
|
||||
- [x] Notifications are written for current approvers and final approval.
|
||||
- [x] Backend tests cover sequencing, counts, access, and final status behavior.
|
||||
|
||||
## Validation Commands
|
||||
|
||||
```bash
|
||||
dotnet build backend/Socialize.slnx
|
||||
dotnet test backend/Socialize.slnx
|
||||
cd frontend && npm run build
|
||||
```
|
||||
25
docs/TASKS/campaigns/001-rename-projects-to-campaigns.md
Normal file
25
docs/TASKS/campaigns/001-rename-projects-to-campaigns.md
Normal file
@@ -0,0 +1,25 @@
|
||||
# Rename Projects To Campaigns
|
||||
|
||||
## Goal
|
||||
|
||||
Align the codebase terminology with the product language by replacing the `Project` domain surface with `Campaign`.
|
||||
|
||||
## Relevant Specs
|
||||
|
||||
- `docs/product/glossary.md`
|
||||
- `docs/ARCHITECTURE.md`
|
||||
|
||||
## Scope
|
||||
|
||||
- Rename backend module, entity, DTOs, handlers, EF configuration, and route/tag names from projects to campaigns.
|
||||
- Update content item and access-scope references that point at the renamed campaign concept.
|
||||
- Update frontend feature naming and API calls where they still refer to projects.
|
||||
- Update OpenAPI snapshots if backend contracts change and the backend can run.
|
||||
|
||||
## Validation
|
||||
|
||||
```bash
|
||||
dotnet build backend/Socialize.slnx
|
||||
dotnet test backend/Socialize.slnx
|
||||
cd frontend && npm run build
|
||||
```
|
||||
@@ -17,7 +17,7 @@ Add the backend foundation for product feedback reports.
|
||||
- type: `Bug`, `Suggestion`, `Request`
|
||||
- status: `New`, `Planned`, `Resolved`, `Won't Do`, `Cancelled`
|
||||
- Add `DbSet` entries and module configuration to `AppDbContext`.
|
||||
- Capture reporter id, reporter display fields, submitted route, browser metadata, viewport size, app version if available, and optional workspace/client/project/content context.
|
||||
- Capture reporter id, reporter display fields, submitted route, browser metadata, viewport size, app version if available, and optional workspace/client/campaign/content context.
|
||||
- Add API endpoints for:
|
||||
- submit feedback
|
||||
- list current user's feedback
|
||||
|
||||
@@ -29,6 +29,10 @@ An agency is above the workspace level in the business model.
|
||||
|
||||
Business, brand, or organization represented by a workspace and participating in review and approval flows.
|
||||
|
||||
## Campaign
|
||||
|
||||
Client-owned body of content work that groups related content items, notes, and timelines.
|
||||
|
||||
## Content Item
|
||||
|
||||
Primary reviewable unit in the system. Contains metadata, copy, due dates, networks, channels, and linked assets.
|
||||
|
||||
Reference in New Issue
Block a user