starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Unable to filter ip-addresses by assigned_object_type via REST API #10271

New Issue
Closed
opened 2025-12-29 21:29:13 +01:00 by adam · 6 comments
adam commented 2025-12-29 21:29:13 +01:00
Owner
Copy Link

Originally created by @Konunacmep on GitHub (Sep 20, 2024).

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:

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.

Originally created by @Konunacmep on GitHub (Sep 20, 2024). ### 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.
adam added the type: bugnetbox labels 2025-12-29 21:29:13 +01:00
adam closed this issue 2025-12-29 21:29:13 +01:00
adam commented 2025-12-29 21:29:13 +01:00
Author
Owner
Copy Link

@arthanson commented on GitHub (Oct 4, 2024):

@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).
IP Address | NetBox REST API 2024-10-04 08-20-22

@arthanson commented on GitHub (Oct 4, 2024): @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). ![IP Address | NetBox REST API 2024-10-04 08-20-22](https://github.com/user-attachments/assets/edda803b-0dab-4285-baf3-40b2ba54b029)
adam commented 2025-12-29 21:29:13 +01:00
Author
Owner
Copy Link

@Konunacmep commented on GitHub (Oct 7, 2024):

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.

@Konunacmep commented on GitHub (Oct 7, 2024): 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.
adam commented 2025-12-29 21:29:14 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Oct 15, 2024):

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.

@github-actions[bot] commented on GitHub (Oct 15, 2024): 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.
adam commented 2025-12-29 21:29:14 +01:00
Author
Owner
Copy Link

@Konunacmep commented on GitHub (Oct 15, 2024):

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
@Konunacmep commented on GitHub (Oct 15, 2024): 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
adam commented 2025-12-29 21:29:14 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 22, 2024):

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.

@jeremystretch commented on GitHub (Oct 22, 2024): 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](https://github.com/netbox-community/netbox/issues/new?assignees=&labels=type%3A+feature%2Cstatus%3A+needs+triage&projects=&template=01-feature_request.yaml) as it would break the existing behavior.
adam commented 2025-12-29 21:29:15 +01:00
Author
Owner
Copy Link

@Konunacmep commented on GitHub (Oct 31, 2024):

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/

@Konunacmep commented on GitHub (Oct 31, 2024): 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/
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label netbox type: bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#10271
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?