<!-- The first section "Release notes" is required if you want to have your release post blog MR auto generated. Currently in BETA, details on the **release post item generator** can be found in the handbook: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator and this video: https://www.youtube.com/watch?v=rfn9ebgTwKg. The next four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended in your first draft, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on the solution. --> ### Release notes <!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " --> It is hard to differentiate between from the point of the view of the API. ### Problem to solve When using the Notes API it hard to differentiate between different times of events e.g. if a pull request is changed because there is a new commit or when it is no longer WIP. ### Intended users * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager) * [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer) * [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test) * [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops) ### User experience goal Users that use Applications that use the Gitlab Notes API would have an easier time using Gitlab. ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> Add a type field to the note object and add different types of notes per type of notes e.g. pull-request or issue. ### Further details <!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. --> A tool that listens to any event could see if it worth to issue a notification to a user or trigger another event e.g. a CI event. ### Permissions and Security They don't require additional permissions, everything is already there just no as good to use. ### Documentation Document changes in the [Note API](https://docs.gitlab.com/ee/api/notes.html) ### Availability & Testing Add test for the extended API. ### Links / references <!-- Label reminders - you should have one of each of the following labels. Read the descriptions on https://gitlab.com/gitlab-org/gitlab/-/labels to find the correct ones --> See the discussion here about the caveats in the Gitlab Notes API while parsing events: https://github.com/magit/forge/issues/318