[BUG] Problems with model parameters and form-urlencode
Created by: neclimdul
Bug Report Checklist
-
Have you provided a full/minimal spec to reproduce the issue? -
Have you validated the input using an OpenAPI validator (example)? -
What's the version of OpenAPI Generator used? -
Have you search for related issues/PRs? -
What's the actual output vs expected output? -
[Optional] Bounty to sponsor the fix (example)
Description
I'm not sure where the bugs here are but there are some problems the way parameters are handled for form encoded resource. There is at least a bug somewhere in the code so I'll just talk it through it.
First, I'd prefer these not be filtered at all because filtering and collapsing the parameters makes the generated code inconsistent with the Spec/Documentation. While there is a separate set of documentation generated by this project but I think its a pretty big experience problem for developers when it doesn't match. This seems to be a feature added in #74 and #51 (closed). I agree with the idea of filtering unused schemas but these schemas are actually used.
Second, it breaks the ability to use API's with dynamic objects. Marketo for example has a schema that can be customized by admin's, adding fields to different models. It is possible to developer the ability for additionalProperties
when the model to the method and serialization but it is impossible when the properties are hard-coded into the signature.
Third, the filtering isn't 100%. In the Person2 example we add the reference different and the filtering doesn't catch it.
openapi-generator version
This seems to affect all versions since the fork. The filtering was added before the 3.0.0 release.
OpenAPI declaration file content or url
openapi: 3.0.0
info:
title: test
version: 1.0.0
contact: {}
security: []
servers: []
paths:
/person1:
post:
operationId: createPerson1
requestBody:
content:
application/x-www-form-urlencoded:
schema:
$ref: '#/components/schemas/Person1'
required: true
responses:
default:
description: Unexpected error
parameters: []
/person2:
post:
operationId: createPerson2
requestBody:
$ref: '#/components/requestBodies/Person2'
responses:
default:
description: Unexpected error
parameters: []
components:
requestBodies:
Person2:
content:
application/x-www-form-urlencoded:
schema:
$ref: '#/components/schemas/Person2'
required: true
schemas:
Person1:
type: object
properties:
email:
type: string
format: email
enabled:
type: boolean
Person2:
type: object
properties:
email:
type: string
format: email
enabled:
type: boolean
extra:
type: array
items:
type: string
Command line used for generation
docker run --rm -v ${PWD}:/local/ openapitools/openapi-generator-cli:v3.0.0 generate \
-i test.yaml -g php -o /local/.build
docker run --rm -v ${PWD}:/local/ openapitools/openapi-generator-cli:latest generate \
-i test.yaml -g php -o /local/.build
Steps to reproduce
Build and review the generated API.
Related issues/PRs
behavior added by #51 (closed)/#74
Suggest a fix
My preferences would be to go back to swagger's behavior of using models for forms the same as other content types.