- Due to https://github.com/exAspArk/batch-loader/pull/32,
we changed BatchLoader.for into BatchLoader::GraphQL.for
- since our results are wrapped in a BatchLoader::GraphQL,
calling `sync` during authorization is required to get real object
- `graphql` now has it's own authorization system. Our
`authorized?` method conflicted and required renaming
Raise an exception if a developer calls any of the GraphQL authorization
methods and a `authorize :permission` is missing from a mutation class.
Previously `authorized?` would return `true` in this situation, which
although technically is accurate is not what a developer is intending.
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