Does emitting @Authorization roles into property/method description makes sense?

[tomasstrejcek]

Before I send pull request I want to make sure I am thinking about this the right way. I patched the compiled metadata-generator code to test this idea. For real code I would presume some configuration, customized text, filtered (internal roles) not showing in docs etc.

        definitions.forEach(def => {
            const fields = this.fields.filter(field => field.target === def.target);
            fields.forEach(field => {
                ....
                if(field.roles) {
                  field.description = (field.description ? field.description : '') + `
user can authorize via roles: ${Array.isArray(field.roles) ? field.roles.join(): field.roles}
                `
                }
            });
            def.fields = fields;
        });
    }```

[MichalLytek]

I would rather give users an universal mechanism to reflect the TypeGraphQL metadata in description, rather than coupling with authorization or complexity directly. We can then expose a few built-in functions that will do the transformation so you can use them as simple plug in or write your custom one if you need more control over that.

[glen-84]

Maybe description can accept a function with two metadata arguments, like:

description?: string | ((objectMetadata, metadata: MetadataStorage) => string | undefined);

objectMetadata would be the metadata for the specific query/field/interface/etc., and metadata would be the global metadata (could be added later).

And then you'd need a way to configure a global default, perhaps:

defaults: {
    description?: string | ((objectMetadata, metadata: MetadataStorage) => string | undefined)
}

... in SchemaGeneratorOptions.

[MichalLytek]

What is an use case for tuning description based on metadata for a single block (type, field)?

I was thinking about something like:

await buildSchema({
  transformDescription: (description, metadata) => 
    description + "\nAccess only for: " + metadata.roles.join(", ");
  },
});

So you can customize the message while not polluting decorators with additional noise.

[glen-84]

What is an use case for tuning description based on metadata for a single block (type, field)?

I didn't have a specific use case in mind, I was just trying to make it as flexible as possible (which is quite possibly unnecessary).

I like your suggestion of passing in the current description to a global transformation function.

[rohit-gohri]

This would be useful to me so that I can add info about Roles required to get access to a query/mutation. So that users can know which Role Access they need to request.