DeviceFilterSet attributes being stripped of options

[itdependsnetworks]

Environment

• Nautobot version (Docker tag too if applicable): 2.0-rc2
• Python version: 3.11
• Database platform, version: latest
• Middleware(s): N/A

I attempted to look on 1.5 or 1.6 but the demo instances weren't immediately loading to see if this is 1.x or not.

Steps to Reproduce

1. Go to https://next.demo.nautobot.com/api/docs/#/dcim/dcim_devices_list
2. Observe has_device_bays, created, last_updated, etc.

Expected Behavior

The attributes to match up to their type, such as DateTime, Boolean, Integer, etc.. as shown in the device-types api

Observed Behavior

Everything is defaulting to char type.

[itdependsnetworks]

The same seems to be true for virtual machines.

[itdependsnetworks]

demo.nautobot.com on 1.6.1 seems to be working, except for face

sales instance on 1.5.24 seems to only have face choice working?

[glennmatthews]

Can confirm that the OpenAPI schema differs between Device and DeviceType in next, e.g.:

      - name: has_console_ports
        required: false
        in: query
        description: Has console ports
        schema:
          type: string

versus:

      - in: query
        name: has_console_port_templates
        schema:
          type: boolean
        description: Has console port templates

[glennmatthews]

I wonder if this somehow has anything to do with the FilterForm definitions - DeviceFilterForm has has_console_ports included as a NullBooleanField, while DeviceTypeFilterForm does not include has_console_port_templates.

[itdependsnetworks]

@glennmatthews my gut says no, since it is stripping off many other things, I realized this when implementing #4378, that the isnull was also being stripped out. Look at all of the attributes, not just the has_*, I think something else is going on.

[glennmatthews]

Agreed - the weirdness appears specific to the dcim/devices/ and virtualization/virtual-machines/ endpoints; all others appear to be working normally on a quick search of the schema.

[glennmatthews]

Possibly related to some of the config-context handling changes in 2.0, such as #3814?

[itdependsnetworks]

@glennmatthews also consider, that I see the issue on the one instance of 1.5.24, but not on 1.6.1, though 1.6.1 has an issue with face_* choices... So oddness all around. It is not clear if it is something specfic with the deployments (such as version of drf-spectacular) being used, or something else.