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

OpenAPI schema is incorrect for the ipam_prefixes_available-prefixes_create endpoint #7631

New Issue
Closed
opened 2025-12-29 20:26:15 +01:00 by adam · 7 comments
adam commented 2025-12-29 20:26:15 +01:00
Owner
Copy Link

Originally created by @Gaardsholt on GitHub (Feb 10, 2023).

NetBox version

v3.4.5-dev

Python version

3.9

Steps to Reproduce

  1. Open the API docs at /api/docs/
  2. Find the /ipam/prefixes/{id}/available-prefixes/endpoint
  3. See that it says that you can only specify the prefix_length in the body

Expected Behavior

That I can use all the fields set on a prefix.

I have successfully tested with the following fields:

{
  "prefix_length": 0,
  "site": 0,
  "role": 0,
  "tenant": 0,
  "vrf": 0,
  "vlan": 0,
  "status": "container",
  "is_pool": true,
  "mark_utilized": true,
  "description": "string",
  "comments": "string"
}

Observed Behavior

That the API docs shows all the available fields that I can set.

I have been playing around with it locally, so I will be happy to do a pull request for it.

Originally created by @Gaardsholt on GitHub (Feb 10, 2023). ### NetBox version v3.4.5-dev ### Python version 3.9 ### Steps to Reproduce 1. Open the API docs at `/api/docs/` 2. Find the `/ipam/prefixes/{id}/available-prefixes/`endpoint 3. See that it says that you can only specify the `prefix_length` in the body ### Expected Behavior That I can use all the fields set on a prefix. I have successfully tested with the following fields: ```json { "prefix_length": 0, "site": 0, "role": 0, "tenant": 0, "vrf": 0, "vlan": 0, "status": "container", "is_pool": true, "mark_utilized": true, "description": "string", "comments": "string" } ``` ### Observed Behavior That the API docs shows all the available fields that I can set. I have been playing around with it locally, so I will be happy to do a pull request for it.
adam closed this issue 2025-12-29 20:26:15 +01:00
adam commented 2025-12-29 20:26:16 +01:00
Author
Owner
Copy Link

@arthanson commented on GitHub (Mar 22, 2023):

This looks like it is still an issue for OpenAPI 3, but blocked till #9608 gets in.

@arthanson commented on GitHub (Mar 22, 2023): This looks like it is still an issue for OpenAPI 3, but blocked till #9608 gets in.
adam commented 2025-12-29 20:26:16 +01:00
Author
Owner
Copy Link

@arthanson commented on GitHub (Apr 13, 2023):

@Gaardsholt I don't think this is actually a bug. prefix_length is the only valid field to pass for available_prefixes. By default DRF (which is used to create the API endpoints) by default doesn't error on extra fields passed in (see: https://stackoverflow.com/questions/22178266/django-rest-framework-raise-error-when-extra-fields-are-present-on-post). You could open a feature request to enable this (but should be done on all APIs, not just this one) if this is a problem. Closing for now.

@arthanson commented on GitHub (Apr 13, 2023): @Gaardsholt I don't think this is actually a bug. prefix_length is the only valid field to pass for available_prefixes. By default DRF (which is used to create the API endpoints) by default doesn't error on extra fields passed in (see: https://stackoverflow.com/questions/22178266/django-rest-framework-raise-error-when-extra-fields-are-present-on-post). You could open a feature request to enable this (but should be done on all APIs, not just this one) if this is a problem. Closing for now.
adam commented 2025-12-29 20:26:16 +01:00
Author
Owner
Copy Link

@Gaardsholt commented on GitHub (Apr 13, 2023):

@arthanson I guess it shouldn't error on the extra fields?
Because when I set those extra fields, they are applied, so it has to be a bug in the API schema, right?

@Gaardsholt commented on GitHub (Apr 13, 2023): @arthanson I guess it shouldn't error on the extra fields? Because when I set those extra fields, they are applied, so it has to be a bug in the API schema, right?
adam commented 2025-12-29 20:26:17 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Apr 14, 2023):

@arthanson

prefix_length is the only valid field to pass for available_prefixes.

As Gaardsholt said this is incorrect. available_prefixes accepts and persists all prefix fields as far as I can tell.

Simple payload as this shows it:

https://demo.netbox.dev/api/ipam/prefixes/98/available-prefixes/

{
  "prefix_length": 30,
  "description": "test"
}

image

@kkthxbye-code commented on GitHub (Apr 14, 2023): @arthanson > prefix_length is the only valid field to pass for available_prefixes. As Gaardsholt said this is incorrect. available_prefixes accepts and persists all prefix fields as far as I can tell. Simple payload as this shows it: https://demo.netbox.dev/api/ipam/prefixes/98/available-prefixes/ ``` { "prefix_length": 30, "description": "test" } ``` ![image](https://user-images.githubusercontent.com/400797/231981466-0017f627-5538-4bda-94d0-e4dd63704e43.png)
adam commented 2025-12-29 20:26:17 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 14, 2023):

I think this was my mistake. I told @arthanson that PrefixLengthSerializer only accepts a prefix_length field (which is technically true, hence the bug), but it also passes other data into the Prefix instance. Ultimately the serializer itself really should be rebuilt more cleanly.

@jeremystretch commented on GitHub (Apr 14, 2023): I think this was my mistake. I told @arthanson that `PrefixLengthSerializer` only accepts a `prefix_length` field (which is technically true, hence the bug), but it also passes other data into the Prefix instance. Ultimately the serializer itself really should be rebuilt more cleanly.
adam commented 2025-12-29 20:26:17 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Sep 22, 2023):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Sep 22, 2023): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 20:26:18 +01:00
Author
Owner
Copy Link

@MinDBreaK commented on GitHub (Oct 4, 2023):

It seems that since the 3.6 release, the documentation has been updated for this API, but now it is missing the prefix_length from the documentation (Which now break codegen for the API). Should a new ticket be opened or we can use this one even if the bug is not exactly the same (but same place, same type of bug) ?

@MinDBreaK commented on GitHub (Oct 4, 2023): It seems that since the 3.6 release, the documentation has been updated for this API, but now it is missing the `prefix_length` from the documentation (Which now break codegen for the API). Should a new ticket be opened or we can use this one even if the bug is not exactly the same (but same place, same type of bug) ?
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 pending closure severity: low status: needs owner topic: OpenAPI 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#7631
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?