This exposes all fields named `id` as GlobalIDs so they can be used
across our entire GraphQL implementation.
When the objects loaded are `ApplicationRecord`s. We'll use our
existing batchloading to find them. Otherwise, we'll fall back to the
default implementation of `GlobalID`: Calling the `.find` method on
the class.
Previously GraphQL field authorization happened like this:
class ProjectType
field :my_field, MyFieldType do
authorize :permission
end
end
This change allowed us to authorize like this instead:
class ProjectType
field :my_field, MyFieldType, authorize: :permission
end
A new initializer registers the `authorize` metadata keyword on GraphQL
Schema Objects and Fields, and we can collect this data within the
context of Instrumentation like this:
field.metadata[:authorize]
The previous functionality of authorize is still being used for
mutations, as the #authorize method here is called at during the code
that executes during the mutation, rather than when a field resolves.
https://gitlab.com/gitlab-org/gitlab-ce/issues/57828
This adds Keyset pagination to GraphQL lists. PoC for that is
pipelines on merge requests and projects.
When paginating a list, the base-64 encoded id of the ordering
field (in most cases the primary key) can be passed in the `before` or
`after` GraphQL argument.
- All definitions have been replaced by classes:
http://graphql-ruby.org/schema/class_based_api.html
- Authorization & Presentation have been refactored to work in the
class based system
- Loaders have been replaced by resolvers
- Times are now coersed as ISO 8601
By specifying a presenter for the object type, we can keep the logic
out of `GitlabSchema`.
The presenter gets initialized using the object being presented, and
the context (including the `current_user`).
Douwe Maan