Resolve "Add a doorkeeper scope suitable for authentication" ## What does this MR do? - Add a single new scope (in addition to the `api` scope we've had) - `read_user` - Allow creating OAuth applications and Personal access tokens with a scope selected - Enforce scopes in the API ## What are the relevant issue numbers? - Closes #20492 - EE counterpart for this MR: gitlab-org/gitlab-ee!946 See merge request !5951
Mattermost Notifications Service ## What does this MR do? closes #22269 ## Screenshots   ## Does this MR meet the acceptance criteria? - [x] [Changelog entry](https://docs.gitlab.com/ce/development/changelog.html) added - [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md) - [x] API support added - Tests - [x] Added for this feature/bug - [x] All builds are passing - [x] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html) - [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides) - [x] Branch has no merge conflicts with `master` (if it does - rebase it please) - [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits) See merge request !7764
`valid_api_token?` is a better name. Scopes are just (potentially) one facet of a "valid" token.
- Previously, AccessTokenValidationService was a module, and all its public methods accepted a token. It makes sense to convert it to a class which accepts a token during initialization. - Also rename the `sufficient_scope?` method to `include_any_scope?` - Based on feedback from @rymai
- Based on @dbalexandre's review - Extract token validity conditions into two separate methods, for personal access tokens and OAuth tokens.
- Mainly whitespace changes. - Require the migration adding the `scope` column to the `personal_access_tokens` table to have downtime, since API calls will fail if the new code is in place, but the migration hasn't run. - Minor refactoring - load `@scopes` in a `before_action`, since we're doing it in three different places.
- This module is used for git-over-http, as well as JWT. - The only valid scope here is `api`, currently.
- Move the `Oauth2::AccessTokenValidationService` class to `AccessTokenValidationService`, since it is now being used for personal access token validation as well. - Each API endpoint declares the scopes it accepts (if any). Currently, the top level API module declares the `api` scope, and the `Users` API module declares the `read_user` scope (for GET requests). - Move the `find_user_by_private_token` from the API `Helpers` module to the `APIGuard` module, to avoid littering `Helpers` with more auth-related methods to support `find_user_by_private_token`
Don't open Asciidoc module twice See merge request !8119
Resolve "gitlab-ce mattermost slash command for issue create needs better documentation" ## What does this MR do? Updates the documentation and the <kbd>help</kbd> command to be clearer, having the keys used to add a newline in chat clients (both Mattermost and Slack). ## Are there points in the code the reviewer needs to double check? * Are the available commands (via <kbd>help</kbd>) being formatted as `<code>` ? ## Why was this MR needed? `\n` represents a new line character and doesn't communicate how the user should input the command. Also, to be correct, the documentation should use `<kbd>` instead of `<code>` for user input ([see HTML5 specification](https://www.w3.org/TR/html5/text-level-semantics.html#the-kbd-element)) ## Screenshots (if relevant) | Mattermost | Docs | | --- | --- | |  |  | ## Does this MR meet the acceptance criteria? - [x] [Changelog entry](https://docs.gitlab.com/ce/development/changelog.html) added - [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md) - Tests - [ ] All builds are passing ## What are the relevant issue numbers? Closes #25144 See merge request !7850