Unable to filter ip-addresses by assigned_object_type via REST API

[Konunacmep]

Deployment Type

Self-hosted

NetBox Version

v4.1.1

Python Version

3.11

Steps to Reproduce

Сan be reproduced on the demo.

1. Log in to https://demo.netbox.dev
2. Request any of:

• https://demo.netbox.dev/api/ipam/ip-addresses/?assigned_object_type=dcim.interface
• https://demo.netbox.dev/api/ipam/ip-addresses/?assigned_object_type=virtualization.vminterface
• https://demo.netbox.dev/api/ipam/ip-addresses/?assigned_object_type=ipam.fhrpgroup

Expected Behavior

Expecting response with filtered list of ip-addresses with specified assigned_object_type (as it was on version 3)

Observed Behavior

Regardless of the parameter value (dcim.interface/virtualization.vminterface/ipam.fhrpgroup) get a response:
"assigned_object_type": [
"Select a valid choice. That choice is not one of the available choices."
]
From the docs: "assigned_object_type - The content type of the assigned object, defined as <app>.<model>".

It is noticed that the parameter accepts numeric values ​​of identifiers from api/extras/object-types for GET requests and filtering works. However, for POST it responds with "'assigned_object_type': ["Invalid value. Specify a content type as '<app_label>.<model_name>'."]" and working with values defined as <app>.<model>.

Initially the problem was noticed after the update from 3.7.1 to 4.0.8, however, the behavior is the same on a clean installation of 4.1.1.

[arthanson]

@Konunacmep which previous version of NetBox were you seeing this working in? I tried with v3.7 and it is not returning the interfaces using this query (see screenshot).

[Konunacmep]

Hi @arthanson, just checked, yes you are right. On 3.7.1, filtering by assigned_object_type does not return an error, but passes unfiltered values ​​into the result. In my opinion, this is also incorrect behavior, because to search by a assigned object, filtering must be performed by a set of assigned_object_type and assigned_object_id fields (polymorphic relationship), assigned_object_id alone is not enough.
Based on this, filtering by the specified field did not work on the 3rd version, but starting with version 4, a problem with the format of the received values ​​appeared.
I apologize for not correctly indicating the version in which the problem appeared.
This does not cancel the impossibility of filtering by the assigned_object_type field declared in this case.
This functionality is necessary to search for IP addresses assigned to an interface, if it is possible to obtain this data in another way, please indicate.

[github-actions]

This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.

[Konunacmep]

Please do not close the case, as we are already talking about 2 unclosed bugs in the REST API ipam.ipaddresses:

• non-working filtering by the assigned_object_type field since 3.7 or earlier
• a problem with the accepted format and type of values ​​for the assigned_object_type field in GET requests that appeared since version 4

[jeremystretch]

IP addresses can filter be filtered by specifying the numeric ID of the assigned content type, e.g. ?assigned_object_type=39. While this is inconsistent with filters which take the content type name rather than the ID, the functionality does exist. Any changes to this filter would require a feature request as it would break the existing behavior.

[Konunacmep]

Thanks for the answer. This is the "workaround" I am currently using to get around the problem. Although, as we found out in this case, this filter does not work at all.

In my opinion, this is definitely a bug that appeared after the update from version 3 to 4. In GET requests, you will have to pass numeric ids, and in POST - strings, in responses also string type. The field should both accept and return the string type, as it was in version 3 and it described in the documentation: https://demo.netbox.dev/static/docs/rest-api/overview/#generic-relations.
I also can't call non-working filtering by key field normal.
But the developers know better.
If fixes are not planned, then the case can be closed, I don't see the point in further discussion.

I would like to note for those who encountered this bug that when using numeric values ​​of assigned_object_type id, these id's can be unique for each specific Netbox instance. The id values ​​of the current Netbox instance should be looked up in /api/extras/object-types/