Allow filtering Resource Access Tokens by state in the REST API
What does this MR do and why?
Allow filtering Resource Access Tokens by state in the REST API
The REST API has and endpoint to fetch Group and Project Access Tokens. The API, in its current state, returns all APIs associated with the resource.
This MR introduces the ability to filter the response by a token's
state. The default is unchanged - all tokens associated with the
resource are returned. inactive includes expired and revoked tokens.
However in practice the behavior of this endpoint does change because it
will now return expired and revoked tokens.
Inactive tokens and bot users
Prior to List Revoked and Expired Project and Group Acce... (#462217),
revoking a token via the API or UI called
ResourceAccessToken::RevokeService, which deleted the bot user and
therefore the association between the token and the resource. Revoking
the user directly in the Rails console did not remove the bot user. See: https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#revoke-a-group-access-token-using-rails-console, which does not call RevokeService.
Similarly, when a Project or Group Access Token expired, a worker would come along and expire the bot user's membership. That would remove the association with the resource.
So in practice, although no state param is provided, the only tokens remaining with a relation to the resource would be active + revoked_via_the_console.
What now?
When that feature is completed and the FF is enabled the API will, by default, start to return
active + expired + revoked.
Changelog: changed
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
| Before | After |
|---|---|
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
Related to #462217