Univention Bugzilla – Bug 55096
OpenAPI schema does not resolve nested object types
Last modified: 2022-11-22 11:35:05 CET
OpenAPI schema does not resolve nested object types If a complex syntax has the "ComplexMultiValueKeyValueDictType" or "ComplexMultiValueDictType" type, only `additionalProperties": true` (free form object) is set. Not a big deal but would be a nice to have. It is a bit confusing since the work on it seems to be already started and it works for "ComplexListType" :) On a side note: "ComplexMultiValueKeyValueDictType" seems to support setting a type for keys. Afaik only strings are supported as keys in OenAPI schemas. I'm not sure what the plan is for that. "73_udm-rest/03_complex_syntax_type.py" can be used for testing.
(In reply to Jürn Brodersen from comment #0) > OpenAPI schema does not resolve nested object types > > If a complex syntax has the "ComplexMultiValueKeyValueDictType" or > "ComplexMultiValueDictType" type, only `additionalProperties": true` (free > form object) is set. A real life example for ComplexMultiValueDictType: `dhcp/host` has property `hwaddress` wich is `multivalue=False` and has `syntax:DHCP_HardwareAddress` which has `subsyntax_names = ('type', 'address')`. It currently has a openapi schema definition of: ``` "hwaddress": { "type": "object", "nullable": true, "additionalProperties": true }, ``` while it could be: ``` "hwaddress": { "type": "object", "nullable": true, "additionalProperties": false, "properties": { "type": { "type": "string", "nullable": true }, "address": { "type": "string", "nullable": true } } }, ``` For ComplexMultiValueKeyValueDictType we don't know the name of the dictionary keys. As the time of writing the type definitions there was no openapi solution for that. We only know the structure of the keys and values but not the key names. > Not a big deal but would be a nice to have. It is a bit > confusing since the work on it seems to be already started and it works for > "ComplexListType" :) I don't remember the reason why this was not done anymore. Maybe overlooking due to the above mentioned complexity plus we need to initialize the type class with the property name and value (which don't exists for a sub-syntax class, but this is also done for ListOfItems as well). > On a side note: "ComplexMultiValueKeyValueDictType" seems to support setting > a type for keys. Afaik only strings are supported as keys in OpenAPI schemas. > I'm not sure what the plan is for that. Yes, but we cannot use this at all for the above reason?!
(In reply to Florian Best from comment #1) > (In reply to Jürn Brodersen from comment #0) > For ComplexMultiValueKeyValueDictType we don't know the name of the > dictionary keys. > As the time of writing the type definitions there was no openapi solution > for that. > We only know the structure of the keys and values but not the key names. It seems we can use the `additionalProperties` property for that, which allows to set either boolean or a schema: https://swagger.io/docs/specification/data-models/keywords/?sbsearch=additionalProperties (not mentioned here :-( https://swagger.io/docs/specification/data-models/data-types/?sbsearch=additionalProperties) I created a MR which implements the nested objects: https://git.knut.univention.de/univention/ucs/-/merge_requests/482
(In reply to Florian Best from comment #2) > (In reply to Florian Best from comment #1) > > (In reply to Jürn Brodersen from comment #0) > > For ComplexMultiValueKeyValueDictType we don't know the name of the > > dictionary keys. > > As the time of writing the type definitions there was no openapi solution > > for that. > > We only know the structure of the keys and values but not the key names. > It seems we can use the `additionalProperties` property for that, which > allows to set either boolean or a schema: > https://swagger.io/docs/specification/data-models/keywords/ > ?sbsearch=additionalProperties > (not mentioned here :-( > https://swagger.io/docs/specification/data-models/data-types/ > ?sbsearch=additionalProperties) One example is the policies/registry:registry property: currently it's schematized as: ``` "registry": { "additionalProperties": true, "nullable": true, "type": "object" }, ``` but should be: ``` "registry": { "additionalProperties": { "nullable": true, "type": "string" }, "nullable": true, "type": "object" }, ```
The nested object type are now described in detail in the OpenAPI schema. A lot of refactoring of the OpenAPI schema has been done as well. * Nested properties are now described more detailed while they previously were only described as free form objects. * Data de-duplication has been made by referencing global data instead of including them. * All possible HTTP errors are listed in the responses. * Experimental features like pagination during search have been added as deprecated so that they can be used more easily in the future when UCS supports them. * Various parameters are now created via code introspection. univention-directory-manager-rest.yaml 7f65982ce4aa | feat(udm-rest): enhance OpenAPI schema univention-directory-manager-rest (10.0.4-6) 7f65982ce4aa | feat(udm-rest): enhance OpenAPI schema b8cf68521aeb | perf(udm-rest): drop properties which are not requested univention-directory-manager-modules.yaml 7f65982ce4aa | feat(udm-rest): enhance OpenAPI schema univention-directory-manager-modules (15.0.13-13) 1f3750bf473a | feat(udm-rest openapi): describe nested properties / subsyntaxes in OpenAPI schema ucs-test (10.0.7-27) 1f3750bf473a | feat(udm-rest openapi): describe nested properties / subsyntaxes in OpenAPI schema
Verified: * Advisory * ucs-test-udm-rest
<https://errata.software-univention.de/#/?erratum=5.0x489> <https://errata.software-univention.de/#/?erratum=5.0x490>