Is your feature request related to a problem? Please describe.
Currently, the default value of disallowAdditionalPropertiesIfNotPresent is true, which means that if a schema in the input spec does not specify additionalProperties, the generator treats that the same as additionalProperties: false and generates model code that forbids additional properties. This means that, when using default config, users will generate non-spec-compliant code with overly strict validation rules.
Many of the tests in this repo have code that is wrong based on the input spec. For example, the following test spec does not include any mention of additionalProperties, which means that models that comply with this spec should allow additional properties:
https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/test/resources/3_0/go/allof_multiple_ref_and_discriminator.yaml
However, the test code was generated from that spec with the default disallowAdditionalPropertiesIfNotPresent=true, so the FinalItem model incorrectly forbids additional properties:
https://github.com/OpenAPITools/openapi-generator/blob/master/samples/client/others/go/allof_multiple_ref_and_discriminator/model_final_item.go#L198-L200
Describe the solution you'd like
I propose changing the default value of disallowAdditionalPropertiesIfNotPresent from true to false. This will cause openapi-generator to default to generating code that follows OpenAPI standards. The config flag can be maintained for backwards compatibility, but I think keeping it as-is causes unnecessary confusion.
Describe alternatives you've considered
Theoretically, the docs could be improved to more clearly call out the need for users to explicitly set disallowAdditionalPropertiesIfNotPresent to false and a significant number of the tests could be updated to set that flag. However, I think it is preferable for this generator to follow OpenAPI standards by default and doing so will lead to a more consistent experience for users.
Additional context
Since this would involve changing the default value of a config option, it would require a major version bump.
Is your feature request related to a problem? Please describe.
Currently, the default value of
disallowAdditionalPropertiesIfNotPresentistrue, which means that if a schema in the input spec does not specifyadditionalProperties, the generator treats that the same asadditionalProperties: falseand generates model code that forbids additional properties. This means that, when using default config, users will generate non-spec-compliant code with overly strict validation rules.Many of the tests in this repo have code that is wrong based on the input spec. For example, the following test spec does not include any mention of
additionalProperties, which means that models that comply with this spec should allow additional properties:https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/test/resources/3_0/go/allof_multiple_ref_and_discriminator.yaml
However, the test code was generated from that spec with the default
disallowAdditionalPropertiesIfNotPresent=true, so the FinalItem model incorrectly forbids additional properties:https://github.com/OpenAPITools/openapi-generator/blob/master/samples/client/others/go/allof_multiple_ref_and_discriminator/model_final_item.go#L198-L200
Describe the solution you'd like
I propose changing the default value of
disallowAdditionalPropertiesIfNotPresentfromtruetofalse. This will cause openapi-generator to default to generating code that follows OpenAPI standards. The config flag can be maintained for backwards compatibility, but I think keeping it as-is causes unnecessary confusion.Describe alternatives you've considered
Theoretically, the docs could be improved to more clearly call out the need for users to explicitly set
disallowAdditionalPropertiesIfNotPresenttofalseand a significant number of the tests could be updated to set that flag. However, I think it is preferable for this generator to follow OpenAPI standards by default and doing so will lead to a more consistent experience for users.Additional context
Since this would involve changing the default value of a config option, it would require a major version bump.