NEW Generate description from class_description when scaffolding types from DataObject

[maxime-rainville]

Description

Update the schema DatObject scaffolding logic to read the description from DataObjects and use that to populate the GraphQL schema description for the resulting types.

Manual testing steps

• Add class_description to a Test DataObject.
• Set up your default graphql schema for your project and your test DataObject to your schema.
• Generate your schema.
• Use the GraphQL dev tools to access your schema via /dev/graphql/ide
• Use the Schema doc view to see the description for your generated type.

Issues

• Auto-generate schema description for DataObject types #632

Pull request checklist

• The target branch is correct
  • See picking the right version
• All commits are relevant to the purpose of the PR (e.g. no debug statements, unrelated refactoring, or arbitrary linting)
  • Small amounts of additional linting are usually okay, but if it makes it hard to concentrate on the relevant changes, ask for the unrelated changes to be reverted, and submitted as a separate PR.
• The commit messages follow our commit message guidelines
• The PR follows our contribution guidelines
• Code changes follow our coding conventions
• This change is covered with tests (or tests aren't necessary for this change)
• Any relevant User Help/Developer documentation is updated; for impactful changes, information is added to the changelog for the intended release
• CI is green

[maxime-rainville]

I considered allowing developers to override the description in their schema definition, but opted against it because it felt like subverting the class_description API. It would have look something like that.

SilverStripe\FrameworkTest\Model\Company:
  description: "My overridden description"
  fields: '*'
  operations:
    '*': true

I also considered provided description for the scaffolded queries and mutations, but opted against it because the description would have been so painfully obvious, it didn't seem worth it. e.g. readOneCompany: Retrieve a Company

[maxime-rainville]

This probably should be in SchemaModelInterface but that would be a breaking change.

[maxime-rainville]

This mimics the approach above that is used with ModelBlacklist.

[maxime-rainville]

Honestly, I didn't find any obviously great place to park those test. The existing tests don't seem to be targeted at specific classes.

[GuySartorelli]

Suggested change

	return $this->dataObject->classDescription() ?? null;
	return $this->dataObject->i18nClassDescription() ?? null;

Unless there's a good reason to not use i18n here?

[maxime-rainville]

Not overly fuss either way.

I would argue that the description in the GraphQL schema is more like developer doc than CMS user doc. We don't normally localise the dev doc.

We also don't provide a way to localise the description when manually defining types or queries.

types:
  Monkey:
    description: "This description will only be available in English and can't be translated."
    fields:
      name:
        type: String
      age:
        type: Int
      species:
        type: String

It's worth pointing out that the description is set when you build your schema. The description will then be stored in the .graphql-generated folder. So if Friedrich has his CMS locale set to German and decides to rebuild the schema, everyone else will get their GraphQL schema description in German whether they like or not.

[GuySartorelli]

Seems fine - if $config['description'] has been set this will be overridden in applyConfig which gives developers a way to override this if they super duper want to.