Comment Templates - pre-defined blocks of text that can be expanded in comments
Also see https://gitlab.com/groups/gitlab-org/-/epics/12669+
### Problem to solve
For every GitLab users, there will be a situation where they want to reply with similar messages or when they want to apply quick actions for newly created issues or merge requests. We want to be able to quickly reply with a predefined message, speed up repetitive tasks, save time and focus on more important tasks.
### Intended users
This benefits all users since all users can write comments, create issues and MRs.
### User experience goal
We can easily manage and apply saved replies with the ability to inject variables to customize the message.
### Proposal
#### Managing Saved Replies
Saved Replies belong to a single user, they are not shared within the Group/Instance.
1. In Profile -> Preferences (https://gitlab.com/-/profile/preferences) users can list all defined Saved Replies.
1. Creating/updating a single Saved Reply will open a new Editor with the ability to set Name and Content (markdown-supported).
1. Users can use predefined variables (as we have in https://docs.gitlab.com/ee/user/project/merge_requests/commit_templates/#supported-variables-in-commit-templates).
1. Users can set a custom variable that can be set when Saved Reply is applied.
1. Name of the Saved Reply is unique in the scope of the user.
#### Applying Saved Reply
1. In the Editor users can click on the icon in the toolbar, a new list with available Saved Replies will be presented and they can select reply to apply.
~~1. In the Editor users can write `/reply SAVED_REPLY_NAME` and apply Saved Reply with the name `SAVED_REPLY_NAME`.~~
### Iteration plan
#### Iteration 1 - MVC
1. Feature is hidden behind feature flag that can be enabled in the scope of the user, default: disabled.
1. Users can list and manage Saved Replies with GraphQL API.
1. Users can apply saved reply with a button in the editor, when you click on the button you'll get a list of saved replies without ability to filter them.
#### Iteration 2
1. Feature flag - default: enabled.
1. Users can list and manage Saved Replies in Profile -> Preferences.
1. Users can filter saved replies in the editor.
### Iteration 3
1. No feature flag.
1. Users can set predefined variables (like %{author}, etc.) that are applied based on the context (in this case: `author` of the Issue or Merge Request)
1. Users can set custom variables that can be set when applying Saved Reply in the editor.
### Further details
#### Ideas for future iterations
1. Ability to store Saved Replies for Project/Group/Instance so they can be shared.
1. Ability to share personal Saved Replies publicly so they can be reused.
### Permissions and Security
### Documentation
### Availability & Testing
### What does success look like, and how can we measure that?
### What is the type of buyer?
### Is this a cross-stage feature?
Yes, this affects every stage.
### Links / references
epic