257 lines
9.4 KiB
Markdown
257 lines
9.4 KiB
Markdown
# Feature: Product Feedback
|
|
|
|
## Status
|
|
|
|
Draft
|
|
|
|
## Goal
|
|
|
|
Allow authenticated users to report bugs, suggestions, and requests from inside the app without interrupting their workflow, and give developers a lightweight place to review, discuss, and resolve that feedback.
|
|
|
|
This is product-level support data for the SaaS operator. It may capture workspace and page context for debugging, but it is not workspace-owned workflow data.
|
|
|
|
## User Stories
|
|
|
|
- As an authenticated user, I want to submit feedback from any app page so that I can report a bug, suggestion, or request when I notice it.
|
|
- As an authenticated user, I want to optionally capture and annotate the current app viewport so that I can explain visual issues clearly.
|
|
- As an authenticated user, I want a global My Feedback page so that I can track my submitted feedback across all workspaces.
|
|
- As a developer, I want a global feedback review page so that I can see all submitted product feedback.
|
|
- As a developer, I want to comment, update status/type, and add tags so that feedback can be reviewed without turning the app into a ticketing system.
|
|
- As a reporter, I want notifications when a developer comments or changes status so that I know when feedback needs my attention.
|
|
- As a developer, I want notifications for new reports and reporter replies so that feedback does not stall silently.
|
|
|
|
## Frontend Areas
|
|
|
|
- Global authenticated app shell floating Feedback button
|
|
- Feedback submission dialog
|
|
- Screenshot capture and annotation editor
|
|
- `/app/my-feedback`
|
|
- `/app/my-feedback/:id`
|
|
- `/app/feedback`
|
|
- `/app/feedback/:id`
|
|
- Existing notification bell
|
|
- `frontend/src/features/feedback/`
|
|
|
|
## Backend Modules
|
|
|
|
- Identity
|
|
- Notifications
|
|
- Feedback
|
|
- Infrastructure blob storage
|
|
|
|
## Access Rules
|
|
|
|
- Only authenticated users can submit feedback.
|
|
- Any authenticated user can submit feedback from any authenticated app page.
|
|
- A new `Developer` role can access the global developer feedback review pages and APIs.
|
|
- Developers can view every feedback report across the SaaS.
|
|
- Reporters can view only feedback they submitted.
|
|
- Feedback detail access is limited to the reporter and users with the `Developer` role.
|
|
- Feedback screenshot access must be authenticated and must follow the same reporter/developer access rules as the report.
|
|
- Feedback does not have public or shared links in v1.
|
|
|
|
## Submission Rules
|
|
|
|
- The global Feedback button appears on every authenticated app page.
|
|
- Submitting feedback is intentionally user-initiated and non-intrusive.
|
|
- Feedback type is required and must be one of:
|
|
- `Bug`
|
|
- `Suggestion`
|
|
- `Request`
|
|
- Description is required and plain text.
|
|
- Screenshot capture is optional.
|
|
- Users explicitly click `Capture screen`; opening feedback does not automatically capture the page.
|
|
- Capture is limited to the app viewport.
|
|
- If capture fails, the user can still submit text-only feedback.
|
|
- If a user closes a dirty feedback dialog, the app warns that unsent feedback will be discarded.
|
|
- Draft persistence is out of scope for v1.
|
|
- Reporters cannot edit or delete submitted feedback in v1.
|
|
- Reporters can add follow-up comments.
|
|
|
|
## Screenshot And Annotation Rules
|
|
|
|
- Screenshots are uploaded through the blob storage abstraction, not embedded in feedback database rows.
|
|
- Feedback screenshots should use a dedicated storage area or prefix.
|
|
- Annotated captures are exported as compressed image files.
|
|
- Backend upload size and content type validation must be enforced.
|
|
- The UI must show a friendly error when an image is too large or invalid.
|
|
- Annotation tools should support:
|
|
- crop
|
|
- arrows
|
|
- circles or ellipses
|
|
- lines
|
|
- freehand marks
|
|
- text labels
|
|
- undo
|
|
- clear/reset
|
|
- Frontend implementation may use established capture and annotation libraries rather than custom screenshot tooling.
|
|
- Developers can preview and download/open the annotated screenshot.
|
|
- Reporters can preview the annotated screenshot.
|
|
- If feedback deletion is added in the future, associated screenshot blobs must be deleted with the report.
|
|
- Feedback reports and screenshots are retained indefinitely until a future retention/deletion feature exists.
|
|
|
|
## Captured Metadata
|
|
|
|
Each report should capture useful debugging context automatically when available:
|
|
|
|
- reporter user id
|
|
- reporter name and email
|
|
- current app URL/path
|
|
- active workspace id/name
|
|
- active client id/name
|
|
- active project id/name
|
|
- active content item id/title
|
|
- browser user agent
|
|
- viewport size
|
|
- app version, if available
|
|
- created timestamp
|
|
|
|
## Status Model
|
|
|
|
Feedback status is deliberately lightweight:
|
|
|
|
- `New`
|
|
- `Planned`
|
|
- `Resolved`
|
|
- `Won't Do`
|
|
- `Cancelled`
|
|
|
|
Status rules:
|
|
|
|
- New reports start as `New`.
|
|
- Developers can move reports to `Planned`, `Resolved`, or `Won't Do`.
|
|
- Developers can change a report type.
|
|
- Developers can add, remove, and update free-form tags.
|
|
- Tags are visible to reporters.
|
|
- Tag entry should suggest previously used tags.
|
|
- Reporters can cancel their own report with an optional plain-text reason.
|
|
- `Cancelled` is final in v1.
|
|
- Reporters cannot reopen resolved or cancelled feedback; they can add comments where comments remain allowed.
|
|
- Developer reason/comment on `Won't Do` is optional.
|
|
- No severity, priority, assignment, duplicate linking, or Jira-style workflow is included in v1.
|
|
|
|
## Comments And Activity
|
|
|
|
- Feedback comments are visible to both the reporter and developers.
|
|
- Internal/private developer comments are out of scope for v1.
|
|
- Status/type/tag changes should be stored as activity history.
|
|
- Feedback detail should show a simple mixed timeline of comments and activity.
|
|
- Reporters can comment on their own feedback.
|
|
- Developers can comment on any feedback report.
|
|
|
|
## Notifications
|
|
|
|
- New feedback report: notify all users with the `Developer` role.
|
|
- Developer comment: notify the reporter.
|
|
- Developer status change: notify the reporter.
|
|
- Developer type/tag changes do not notify the reporter.
|
|
- Reporter comment: notify developers who have previously commented on that report.
|
|
- Feedback notifications use the existing in-app notification system.
|
|
- The existing notification bell should show feedback notifications and open the relevant feedback detail page.
|
|
- Email notifications are out of scope for v1.
|
|
- My Feedback should show an unread indicator for reports with unread developer comments or status changes.
|
|
|
|
## Developer Review Page
|
|
|
|
The developer review area is global, not workspace-scoped.
|
|
|
|
`/app/feedback` should support:
|
|
|
|
- list all reports by default, including final statuses
|
|
- filter by type
|
|
- filter by status
|
|
- filter by tag
|
|
- filter by reporter
|
|
- filter by workspace context
|
|
- filter by date range
|
|
- text search
|
|
- sort by newest
|
|
- sort by oldest
|
|
- sort by last activity
|
|
|
|
`/app/feedback/:id` should support:
|
|
|
|
- report details and captured metadata
|
|
- reporter identity details
|
|
- current URL/path link
|
|
- screenshot preview and developer download/open-original action
|
|
- comments
|
|
- activity timeline
|
|
- status updates
|
|
- type updates
|
|
- tag management with suggestions
|
|
|
|
## Reporter Pages
|
|
|
|
`/app/my-feedback` is global across workspaces and should default to active reports:
|
|
|
|
- `New`
|
|
- `Planned`
|
|
|
|
The page should support:
|
|
|
|
- list own reports only
|
|
- filter by status
|
|
- filter by type
|
|
- sort by newest
|
|
- sort by last activity
|
|
- unread indicators
|
|
- open feedback detail
|
|
- view visible tags
|
|
|
|
`/app/my-feedback/:id` should support:
|
|
|
|
- report details
|
|
- current URL/path link
|
|
- screenshot preview
|
|
- visible tags
|
|
- comments
|
|
- activity timeline
|
|
- cancel with optional reason when status is not final
|
|
|
|
## Localization
|
|
|
|
- User-facing feedback UI must be available in English and French.
|
|
- New strings belong in the existing locale files.
|
|
|
|
## API And Data Expectations
|
|
|
|
- Backend code should follow the FastEndpoints module pattern under `backend/src/Socialize.Api/Modules/Feedback`.
|
|
- Feedback entities should be added to `AppDbContext` with explicit model configuration.
|
|
- The `Developer` role should be seeded with the existing identity role setup.
|
|
- Screenshot storage should use the existing `IBlobStorage` abstraction.
|
|
- Protected screenshot access may require a feedback-specific download endpoint instead of public static blob URLs.
|
|
- Backend contract changes require OpenAPI regeneration while the backend is running.
|
|
|
|
## Out Of Scope For V1
|
|
|
|
- Public or unauthenticated feedback submission
|
|
- Shared feedback links
|
|
- Email notifications
|
|
- Draft saving
|
|
- Feedback deletion UI
|
|
- Automatic retention cleanup
|
|
- Severity or priority fields
|
|
- Assignment/owner workflow
|
|
- Duplicate linking
|
|
- Internal/private comments
|
|
- Workspace-owned exports or audit reports
|
|
|
|
## Done When
|
|
|
|
- [ ] Authenticated users can open a global Feedback dialog from every app page.
|
|
- [ ] Users can submit feedback with required type and description.
|
|
- [ ] Users can optionally capture, annotate, and upload an app viewport screenshot.
|
|
- [ ] Feedback records capture debugging metadata when available.
|
|
- [ ] Reporters can view their own global My Feedback list and details.
|
|
- [ ] Developers with the `Developer` role can view all feedback in `/app/feedback`.
|
|
- [ ] Developers can update type, status, and tags.
|
|
- [ ] Reporters and developers can comment on feedback.
|
|
- [ ] Feedback activity history is shown with comments.
|
|
- [ ] Feedback notifications appear in the existing in-app notification system.
|
|
- [ ] Feedback screenshot access is authenticated and scoped to reporter/developer access.
|
|
- [ ] English and French UI strings are present.
|
|
- [ ] Backend build and tests pass.
|
|
- [ ] Frontend build passes.
|
|
- [ ] OpenAPI is updated after backend contracts are implemented.
|