1
0
mirror of https://github.com/netbox-community/netbox.git synced 2024-05-10 07:54:54 +00:00

139 lines
6.3 KiB
Python
Raw Normal View History

from drf_yasg import openapi
Fix type mismatches in API view (#2429) * Fix tags field to be shown as array in API view `tags` field in serializers is defineded as `TagListSerializerField`. It should be shown as an array value in API view but actually, it is a simple string value. This fixes it by introducing a new `FieldInspector` to handle `TagListSerializerField` type field as an array. It doesn't affects any other type fields. * Fix SerializedPKRelatedField type API expression A field definded as `SerializedPKRelatedField` should be shown as an array of child serializer objects in a response value definition in API view but it is shown as an array of primary key values (usually `integer` type) of a child serializer. This fixes it by introducing a new `FieldInspector` to handle the field. It doesn't affect any other type fields. * Fix request parameter representation in API view In API view, representation of a parameter defined as a sub class of `WritableNestedSerializer` should be vary between a request and a response. For example, `tenant` field in `IPAddressSerializer` should be shown like following as a request body: ``` tenant: integer ... ``` while it should be shown like following as a response body: ``` tenant: { id: integer ..., url: string ..., name: string ..., slug: string ... } ``` But in both cases, it is shown as a response body type expression. This causes an error at sending an API request with that type value. It is only an API view issue, API can handle a request if a request parameter is structured as an expected request body by ignoring the wrong expression. This fixes the issue by replacing an implicitly used default auto schema generator class by its sub class and returning a pseudo serializer with 'Writable' prefix at generating a request body. The reason to introduce a new generator class is that there is no other point which can distinguish a request and a response. It is not enough to distinguish POST, PUT, PATCH methods from GET because former cases may return a JSON object as a response but it is also represented as same as a request body, causes another mismatch. This also fixes `SerializedPKRelatedField` type field representation. It should be shown as an array of primary keys in a request body. Fixed #2400
2018-11-28 06:14:45 +09:00
from drf_yasg.inspectors import FieldInspector, NotHandled, PaginatorInspector, FilterInspector, SwaggerAutoSchema
from drf_yasg.utils import get_serializer_ref_name
from rest_framework.fields import ChoiceField
Fix type mismatches in API view (#2429) * Fix tags field to be shown as array in API view `tags` field in serializers is defineded as `TagListSerializerField`. It should be shown as an array value in API view but actually, it is a simple string value. This fixes it by introducing a new `FieldInspector` to handle `TagListSerializerField` type field as an array. It doesn't affects any other type fields. * Fix SerializedPKRelatedField type API expression A field definded as `SerializedPKRelatedField` should be shown as an array of child serializer objects in a response value definition in API view but it is shown as an array of primary key values (usually `integer` type) of a child serializer. This fixes it by introducing a new `FieldInspector` to handle the field. It doesn't affect any other type fields. * Fix request parameter representation in API view In API view, representation of a parameter defined as a sub class of `WritableNestedSerializer` should be vary between a request and a response. For example, `tenant` field in `IPAddressSerializer` should be shown like following as a request body: ``` tenant: integer ... ``` while it should be shown like following as a response body: ``` tenant: { id: integer ..., url: string ..., name: string ..., slug: string ... } ``` But in both cases, it is shown as a response body type expression. This causes an error at sending an API request with that type value. It is only an API view issue, API can handle a request if a request parameter is structured as an expected request body by ignoring the wrong expression. This fixes the issue by replacing an implicitly used default auto schema generator class by its sub class and returning a pseudo serializer with 'Writable' prefix at generating a request body. The reason to introduce a new generator class is that there is no other point which can distinguish a request and a response. It is not enough to distinguish POST, PUT, PATCH methods from GET because former cases may return a JSON object as a response but it is also represented as same as a request body, causes another mismatch. This also fixes `SerializedPKRelatedField` type field representation. It should be shown as an array of primary keys in a request body. Fixed #2400
2018-11-28 06:14:45 +09:00
from rest_framework.relations import ManyRelatedField
from taggit_serializer.serializers import TagListSerializerField
2019-03-07 13:58:34 -05:00
from dcim.api.serializers import InterfaceSerializer as DeviceInterfaceSerializer
from extras.api.customfields import CustomFieldsSerializer
Fix type mismatches in API view (#2429) * Fix tags field to be shown as array in API view `tags` field in serializers is defineded as `TagListSerializerField`. It should be shown as an array value in API view but actually, it is a simple string value. This fixes it by introducing a new `FieldInspector` to handle `TagListSerializerField` type field as an array. It doesn't affects any other type fields. * Fix SerializedPKRelatedField type API expression A field definded as `SerializedPKRelatedField` should be shown as an array of child serializer objects in a response value definition in API view but it is shown as an array of primary key values (usually `integer` type) of a child serializer. This fixes it by introducing a new `FieldInspector` to handle the field. It doesn't affect any other type fields. * Fix request parameter representation in API view In API view, representation of a parameter defined as a sub class of `WritableNestedSerializer` should be vary between a request and a response. For example, `tenant` field in `IPAddressSerializer` should be shown like following as a request body: ``` tenant: integer ... ``` while it should be shown like following as a response body: ``` tenant: { id: integer ..., url: string ..., name: string ..., slug: string ... } ``` But in both cases, it is shown as a response body type expression. This causes an error at sending an API request with that type value. It is only an API view issue, API can handle a request if a request parameter is structured as an expected request body by ignoring the wrong expression. This fixes the issue by replacing an implicitly used default auto schema generator class by its sub class and returning a pseudo serializer with 'Writable' prefix at generating a request body. The reason to introduce a new generator class is that there is no other point which can distinguish a request and a response. It is not enough to distinguish POST, PUT, PATCH methods from GET because former cases may return a JSON object as a response but it is also represented as same as a request body, causes another mismatch. This also fixes `SerializedPKRelatedField` type field representation. It should be shown as an array of primary keys in a request body. Fixed #2400
2018-11-28 06:14:45 +09:00
from utilities.api import ChoiceField, SerializedPKRelatedField, WritableNestedSerializer
2019-10-04 12:08:48 -04:00
from virtualization.api.serializers import InterfaceSerializer as VirtualMachineInterfaceSerializer
Fix type mismatches in API view (#2429) * Fix tags field to be shown as array in API view `tags` field in serializers is defineded as `TagListSerializerField`. It should be shown as an array value in API view but actually, it is a simple string value. This fixes it by introducing a new `FieldInspector` to handle `TagListSerializerField` type field as an array. It doesn't affects any other type fields. * Fix SerializedPKRelatedField type API expression A field definded as `SerializedPKRelatedField` should be shown as an array of child serializer objects in a response value definition in API view but it is shown as an array of primary key values (usually `integer` type) of a child serializer. This fixes it by introducing a new `FieldInspector` to handle the field. It doesn't affect any other type fields. * Fix request parameter representation in API view In API view, representation of a parameter defined as a sub class of `WritableNestedSerializer` should be vary between a request and a response. For example, `tenant` field in `IPAddressSerializer` should be shown like following as a request body: ``` tenant: integer ... ``` while it should be shown like following as a response body: ``` tenant: { id: integer ..., url: string ..., name: string ..., slug: string ... } ``` But in both cases, it is shown as a response body type expression. This causes an error at sending an API request with that type value. It is only an API view issue, API can handle a request if a request parameter is structured as an expected request body by ignoring the wrong expression. This fixes the issue by replacing an implicitly used default auto schema generator class by its sub class and returning a pseudo serializer with 'Writable' prefix at generating a request body. The reason to introduce a new generator class is that there is no other point which can distinguish a request and a response. It is not enough to distinguish POST, PUT, PATCH methods from GET because former cases may return a JSON object as a response but it is also represented as same as a request body, causes another mismatch. This also fixes `SerializedPKRelatedField` type field representation. It should be shown as an array of primary keys in a request body. Fixed #2400
2018-11-28 06:14:45 +09:00
# this might be ugly, but it limits drf_yasg-specific code to this file
2019-03-07 13:58:34 -05:00
DeviceInterfaceSerializer.Meta.ref_name = 'DeviceInterface'
VirtualMachineInterfaceSerializer.Meta.ref_name = 'VirtualMachineInterface'
Fix type mismatches in API view (#2429) * Fix tags field to be shown as array in API view `tags` field in serializers is defineded as `TagListSerializerField`. It should be shown as an array value in API view but actually, it is a simple string value. This fixes it by introducing a new `FieldInspector` to handle `TagListSerializerField` type field as an array. It doesn't affects any other type fields. * Fix SerializedPKRelatedField type API expression A field definded as `SerializedPKRelatedField` should be shown as an array of child serializer objects in a response value definition in API view but it is shown as an array of primary key values (usually `integer` type) of a child serializer. This fixes it by introducing a new `FieldInspector` to handle the field. It doesn't affect any other type fields. * Fix request parameter representation in API view In API view, representation of a parameter defined as a sub class of `WritableNestedSerializer` should be vary between a request and a response. For example, `tenant` field in `IPAddressSerializer` should be shown like following as a request body: ``` tenant: integer ... ``` while it should be shown like following as a response body: ``` tenant: { id: integer ..., url: string ..., name: string ..., slug: string ... } ``` But in both cases, it is shown as a response body type expression. This causes an error at sending an API request with that type value. It is only an API view issue, API can handle a request if a request parameter is structured as an expected request body by ignoring the wrong expression. This fixes the issue by replacing an implicitly used default auto schema generator class by its sub class and returning a pseudo serializer with 'Writable' prefix at generating a request body. The reason to introduce a new generator class is that there is no other point which can distinguish a request and a response. It is not enough to distinguish POST, PUT, PATCH methods from GET because former cases may return a JSON object as a response but it is also represented as same as a request body, causes another mismatch. This also fixes `SerializedPKRelatedField` type field representation. It should be shown as an array of primary keys in a request body. Fixed #2400
2018-11-28 06:14:45 +09:00
class NetBoxSwaggerAutoSchema(SwaggerAutoSchema):
writable_serializers = {}
Fix type mismatches in API view (#2429) * Fix tags field to be shown as array in API view `tags` field in serializers is defineded as `TagListSerializerField`. It should be shown as an array value in API view but actually, it is a simple string value. This fixes it by introducing a new `FieldInspector` to handle `TagListSerializerField` type field as an array. It doesn't affects any other type fields. * Fix SerializedPKRelatedField type API expression A field definded as `SerializedPKRelatedField` should be shown as an array of child serializer objects in a response value definition in API view but it is shown as an array of primary key values (usually `integer` type) of a child serializer. This fixes it by introducing a new `FieldInspector` to handle the field. It doesn't affect any other type fields. * Fix request parameter representation in API view In API view, representation of a parameter defined as a sub class of `WritableNestedSerializer` should be vary between a request and a response. For example, `tenant` field in `IPAddressSerializer` should be shown like following as a request body: ``` tenant: integer ... ``` while it should be shown like following as a response body: ``` tenant: { id: integer ..., url: string ..., name: string ..., slug: string ... } ``` But in both cases, it is shown as a response body type expression. This causes an error at sending an API request with that type value. It is only an API view issue, API can handle a request if a request parameter is structured as an expected request body by ignoring the wrong expression. This fixes the issue by replacing an implicitly used default auto schema generator class by its sub class and returning a pseudo serializer with 'Writable' prefix at generating a request body. The reason to introduce a new generator class is that there is no other point which can distinguish a request and a response. It is not enough to distinguish POST, PUT, PATCH methods from GET because former cases may return a JSON object as a response but it is also represented as same as a request body, causes another mismatch. This also fixes `SerializedPKRelatedField` type field representation. It should be shown as an array of primary keys in a request body. Fixed #2400
2018-11-28 06:14:45 +09:00
def get_request_serializer(self):
serializer = super().get_request_serializer()
if serializer is not None and self.method in self.implicit_body_methods:
properties = {}
for child_name, child in serializer.fields.items():
if isinstance(child, (ChoiceField, WritableNestedSerializer)):
properties[child_name] = None
elif isinstance(child, ManyRelatedField) and isinstance(child.child_relation, SerializedPKRelatedField):
properties[child_name] = None
if properties:
if type(serializer) not in self.writable_serializers:
writable_name = 'Writable' + type(serializer).__name__
meta_class = getattr(type(serializer), 'Meta', None)
if meta_class:
ref_name = 'Writable' + get_serializer_ref_name(serializer)
writable_meta = type('Meta', (meta_class,), {'ref_name': ref_name})
properties['Meta'] = writable_meta
self.writable_serializers[type(serializer)] = type(writable_name, (type(serializer),), properties)
writable_class = self.writable_serializers[type(serializer)]
Fix type mismatches in API view (#2429) * Fix tags field to be shown as array in API view `tags` field in serializers is defineded as `TagListSerializerField`. It should be shown as an array value in API view but actually, it is a simple string value. This fixes it by introducing a new `FieldInspector` to handle `TagListSerializerField` type field as an array. It doesn't affects any other type fields. * Fix SerializedPKRelatedField type API expression A field definded as `SerializedPKRelatedField` should be shown as an array of child serializer objects in a response value definition in API view but it is shown as an array of primary key values (usually `integer` type) of a child serializer. This fixes it by introducing a new `FieldInspector` to handle the field. It doesn't affect any other type fields. * Fix request parameter representation in API view In API view, representation of a parameter defined as a sub class of `WritableNestedSerializer` should be vary between a request and a response. For example, `tenant` field in `IPAddressSerializer` should be shown like following as a request body: ``` tenant: integer ... ``` while it should be shown like following as a response body: ``` tenant: { id: integer ..., url: string ..., name: string ..., slug: string ... } ``` But in both cases, it is shown as a response body type expression. This causes an error at sending an API request with that type value. It is only an API view issue, API can handle a request if a request parameter is structured as an expected request body by ignoring the wrong expression. This fixes the issue by replacing an implicitly used default auto schema generator class by its sub class and returning a pseudo serializer with 'Writable' prefix at generating a request body. The reason to introduce a new generator class is that there is no other point which can distinguish a request and a response. It is not enough to distinguish POST, PUT, PATCH methods from GET because former cases may return a JSON object as a response but it is also represented as same as a request body, causes another mismatch. This also fixes `SerializedPKRelatedField` type field representation. It should be shown as an array of primary keys in a request body. Fixed #2400
2018-11-28 06:14:45 +09:00
serializer = writable_class()
return serializer
class SerializedPKRelatedFieldInspector(FieldInspector):
def field_to_swagger_object(self, field, swagger_object_type, use_references, **kwargs):
SwaggerType, ChildSwaggerType = self._get_partial_types(field, swagger_object_type, use_references, **kwargs)
if isinstance(field, SerializedPKRelatedField):
return self.probe_field_inspectors(field.serializer(), ChildSwaggerType, use_references)
return NotHandled
class TagListFieldInspector(FieldInspector):
def field_to_swagger_object(self, field, swagger_object_type, use_references, **kwargs):
SwaggerType, ChildSwaggerType = self._get_partial_types(field, swagger_object_type, use_references, **kwargs)
if isinstance(field, TagListSerializerField):
child_schema = self.probe_field_inspectors(field.child, ChildSwaggerType, use_references)
return SwaggerType(
type=openapi.TYPE_ARRAY,
items=child_schema,
)
return NotHandled
class CustomChoiceFieldInspector(FieldInspector):
def field_to_swagger_object(self, field, swagger_object_type, use_references, **kwargs):
# this returns a callable which extracts title, description and other stuff
# https://drf-yasg.readthedocs.io/en/stable/_modules/drf_yasg/inspectors/base.html#FieldInspector._get_partial_types
SwaggerType, _ = self._get_partial_types(field, swagger_object_type, use_references, **kwargs)
if isinstance(field, ChoiceField):
value_schema = openapi.Schema(type=openapi.TYPE_STRING)
choices = list(field._choices.keys())
if set([None] + choices) == {None, True, False}:
# DeviceType.subdevice_role, Device.face and InterfaceConnection.connection_status all need to be
# differentiated since they each have subtly different values in their choice keys.
# - subdevice_role and connection_status are booleans, although subdevice_role includes None
# - face is an integer set {0, 1} which is easily confused with {False, True}
schema_type = openapi.TYPE_STRING
if all(type(x) == bool for x in [c for c in choices if c is not None]):
schema_type = openapi.TYPE_BOOLEAN
value_schema = openapi.Schema(type=schema_type)
value_schema['x-nullable'] = True
schema = SwaggerType(type=openapi.TYPE_OBJECT, required=["label", "value"], properties={
"label": openapi.Schema(type=openapi.TYPE_STRING),
"value": value_schema
})
return schema
elif isinstance(field, CustomFieldsSerializer):
schema = SwaggerType(type=openapi.TYPE_OBJECT)
return schema
return NotHandled
class NullableBooleanFieldInspector(FieldInspector):
def process_result(self, result, method_name, obj, **kwargs):
if isinstance(result, openapi.Schema) and isinstance(obj, ChoiceField) and result.type == 'boolean':
keys = obj.choices.keys()
if set(keys) == {None, True, False}:
result['x-nullable'] = True
result.type = 'boolean'
return result
class IdInFilterInspector(FilterInspector):
def process_result(self, result, method_name, obj, **kwargs):
if isinstance(result, list):
params = [p for p in result if isinstance(p, openapi.Parameter) and p.name == 'id__in']
for p in params:
p.type = 'string'
return result
class NullablePaginatorInspector(PaginatorInspector):
def process_result(self, result, method_name, obj, **kwargs):
if method_name == 'get_paginated_response' and isinstance(result, openapi.Schema):
next = result.properties['next']
if isinstance(next, openapi.Schema):
next['x-nullable'] = True
previous = result.properties['previous']
if isinstance(previous, openapi.Schema):
previous['x-nullable'] = True
return result