Closed RichardLindhout closed 3 years ago
@troian I think you have this use-case too right? Based on creatorId in your scheme
Exactly!
Ok, I'll try to resolve this issue this week!
This is finished in #development will try to release this soon!
api.AddPlugin(gbgen.NewResolverPlugin(
output,
backend,
frontend,
gbgen.ResolverPluginConfig{
// Authorization scopes can be used to override e.g. userId, organizationId, tenantId
// This will be resolved used the provided ScopeResolverName if the result of the AddTrigger=true
// You would need this if you don't want to require these fields in your schema but you want to add them
// to the db model.
// If you do have these fields in your schema but want them authorized you could use a gqlgen directive
AuthorizationScopes: []*gbgen.AuthorizationScope{
{
ImportPath: "github.com/.../app/backend/auth",
ImportAlias: "auth",
ScopeResolverName: "UserIDFromContext", // function which is called with the context of the resolver
BoilerColumnName: "UserID",
AddHook: func(model *gbgen.BoilerModel, resolver *gbgen.Resolver, templateKey string) bool {
fmt.Println(templateKey)
// templateKey contains a unique where the resolver tries to add something
// e.g.
// most of the time you can ignore this
var addResolver bool
for _, field := range model.Fields {
if field.Name == "UserID" {
addResolver = true
}
}
return addResolver
},
},
},
},
)),
Is released in v3.1.0
We now have some check for userId, organizationId, userOrganizationId which are used at webRidge.
This won't work for other thing like authorId, or creatorId. User from a GraphQL api is generally not allowed to put this field inside of the api, this field needs to be resolved based on auth context or something else.
We need to support his use case by deprecating the userId, organizationId, userOrganizationId fields https://github.com/web-ridge/gqlgen-sqlboiler/blob/master/resolver.gotpl#L110.
Instead user would be allowed to put a resolver config object inside the convert_plugin.go
Instead of
Maybe something like this