Add root users query to GraphQL API
What does this MR do?
Adds a root users
query to the GraphQL API which allows for the following types of queries:
By list of usernames:
{
users(usernames: ["user12298", "mwoolf"]) {
nodes {
id
}
}
}
By list of IDs:
{
users(ids: ["gid://gitlab/User/12344", "gid://gitlab/User/12345"]) {
nodes {
id
}
}
}
All publicly available users:
{
users {
nodes {
id
}
}
}
This is one of 3 MRs to allow for the generation of a report defined in #215658 (closed) but is mergeable independently.
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry -
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers -
Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Database
Changes to UsersFinder
have triggered a database review.
A sample of 100 random users generates the following query and plan:
Query
SELECT "users".* FROM "users" WHERE "users"."id" IN (XXXXXX) ORDER BY "users"."id" DESC
Plan
Index Scan using users_pkey on public.users (cost=0.43..338.40 rows=100 width=1244) (actual time=9.493..309.435 rows=94 loops=1)
Index Cond: (users.id = ANY ('{XXXXXXX}'::integer[]))
Buffers: shared hit=359 read=132 dirtied=3
I/O Timings: read=306.287
Timings
Time: 309.955 ms
- planning: 0.387 ms
- execution: 309.568 ms
- I/O read: 306.287 ms
- I/O write: 0.000 ms
Shared buffers:
- hits: 359 (~2.80 MiB) from the buffer pool
- reads: 132 (~1.00 MiB) from the OS file cache, including disk I/O
- dirtied: 3 (~24.00 KiB)
- writes: 0
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec
-
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team
Merge request reports
Activity
changed milestone to %13.1
mentioned in issue #215658 (closed)
assigned to @mwoolf
- Resolved by Max Woolf
Reviewer roulette
Changes that require review have been detected! A merge request is normally reviewed by both a reviewer and a maintainer in its primary category (e.g. frontend or backend), and by a maintainer in all other categories.
To spread load more evenly across eligible reviewers, Danger has randomly picked a candidate for each review slot. Feel free to override these selections if you think someone else would be better-suited, or the chosen person is unavailable.
To read more on how to use the reviewer roulette, please take a look at the Engineering workflow and code review guidelines.
Once you've decided who will review this merge request, mention them as you normally would! Danger does not (yet?) automatically notify them for you.
Category Reviewer Maintainer database Dmitry Gruzd ( @dgruzd
)Mayra Cabrera ( @mayra-cabrera
)backend Alex Buijs ( @alexbuijs
)Jan Provaznik ( @jprovaznik
)If needed, you can retry the
danger-review
job that generated this comment.Generated by
DangerEdited by 🤖 GitLab Bot 🤖added workflowin dev label and removed workflowin review label
added GraphQL label
marked the checklist item Changelog entry as completed
marked the checklist item Documentation (if required) as completed
marked the checklist item Code review guidelines as completed
marked the checklist item Merge request performance guidelines as completed
marked the checklist item Style guides as completed
marked the checklist item Database guides as completed
marked the checklist item Separation of EE specific content as completed