# 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.
- Feedback screenshot records store blob container/path metadata and expose a protected API download path, not a public blob URL.
- 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.
