Fix: OpenAPI warnings

[newstler]

Closes bullet-train-co/bullet_train#734
Requires bullet-train-co/bullet_train#749

• Fixes warnings shown by yarn exec redocly lint http://127.0.0.1:3000/api/v1/openapi.yaml
• Includes Fix: Empty examples in schemas in OpenAPI #236 and Fix: Paths methods generation for OpenAPI #258
• Test test/controllers/api/open_api_controller_test.rb in starter repo was rewritten to fail on warnings
• Upgraded jbuilder-schema to >= 2.2.0
• Added Jbuilder hack module in bullet_train-api/lib/jbuilder/values_transformer.rb to modify attributes produced by external classes, by now it replaces ActionText::RichText object with it's body value. More can be added if needed.

[gazayas]

LGTM 👍 The Open API controller test wasn't passing for me before this PR, but now it's good.

[gazayas]

This reminds me of the comment in the Transformer about rich text attributes

bullet_train-core/bullet_train-super_scaffolding/lib/scaffolding/transformer.rb

Line 1140 in aad0748

# TODO The serializers can't handle these `has_rich_text` attributes.

We skip trix editor attributes when super scaffolding jbuilder files, but should we add the body somehow over there in the transformer as well?

[newstler]

Well, anyway those attributes are exposed for ScaffoldingCompletelyConcreteTangibleThing when HIDE_THINGS is not enabled. So this Jbuilder hack lets us show ActionText::RichText attributes properly (as string instead of whole object). I think if those were skipped before, now they can be added. Also, if there are any other attributes that should be exposed differently in Jbuilder, they might also be added to this file.

I afraid I didn't fully understand what you meant by should we add the body somehow over there in the transformer as well? :)

[gazayas]

I afraid I didn't fully understand what you meant by should we add the body somehow over there in the transformer as well? :)

I just wasn't sure how we should handle rich text attributes with the API, but after looking into it a bit, I'm thinking I'll make a different PR to return the ActionText::RichText object as a whole instead of just the body (that seems to make the most sense to me). As far as what we return, I think we can leave the decision up to Andrew. I'm fine with how things are now though. Thanks!

Here is an example of bar as a trix editor attribute:

[newstler]

Well, that data in API feels completely useless for me, as it is the internal ActionText stuff, and as an API user I can't do anything with that, it's only clutters up the information.

Also, I am pretty sure warnings were there as when we create a record, we send bar as a string. And I'm not sure we now support different types of same attribute for Attributes and Parameters. Should we?

What about the case when some code gets data from one API endpoint and redirects it to another? It will take manual work in the middle to clarify this data..

[gazayas]

Well, that data in API feels completely useless for me, as it is the internal ActionText stuff, and as an API user I can't do anything with that, it's only clutters up the information.

Good point, I didn't consider this. I hadn't run the the ActionText::RichText API object against the OpenAPI test so that makes sense about the warnings. Thanks for explaining!

[newstler]

@gazayas Try with Open API controller test from the corresponding branch in starter repo, it was rewritten.

I also updated description.
Not sure if it's right, but this PR includes 2 other PRs that it needs to work correctly :)

[jagthedrummer]

@newstler Can you look at fixing the test failures here? They seem to be related to the OpenAPI stuff that's changed in this PR and/or the one in the starter repo.

[newstler]

@jagthedrummer Fixed!