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

API: Accept single‑value integer ranges in IntegerRangeSerializer #11684

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

Originally created by @pheus on GitHub (Oct 3, 2025).

NetBox version

v4.4.2

Feature type

Change to existing functionality

Proposed functionality

Extend the integer range serializer to accept single values in addition to the current 2‑value range format. Specifically, accept any of:

  • 53
  • [53, 53]

This is most visible for VLANGroup VLAN ID ranges but applies to any field using the integer range serializer. The change is fully backward‑compatible: existing inputs (two‑element lists) continue to work, and output/representation remains unchanged.

Use case

When working with VLAN groups or other range fields, API clients often need to submit a single value. Allowing a bare integer avoids forcing clients to wrap a singleton as a two‑element range, reduces friction for simple operations, and matches user expectations from the UI (where singletons are common).

Changes required

  • Update IntegerRangeSerializer.to_internal_value() to normalize:
    • int → (lo=val, hi=val)
    • list|tuple of length 2 → (lo, hi)
  • Keep storage/representation semantics unchanged.

Database changes

None.

External dependencies

None.

Example:

53

[53, 53]
Originally created by @pheus on GitHub (Oct 3, 2025). ### NetBox version v4.4.2 ### Feature type Change to existing functionality ### Proposed functionality Extend the integer range serializer to accept **single values** in addition to the current 2‑value range format. Specifically, accept any of: - `53` - `[53, 53]` This is most visible for **VLANGroup** VLAN ID ranges but applies to any field using the integer range serializer. The change is fully backward‑compatible: existing inputs (two‑element lists) continue to work, and output/representation remains unchanged. ### Use case When working with VLAN groups or other range fields, API clients often need to submit a **single** value. Allowing a bare integer avoids forcing clients to wrap a singleton as a two‑element range, reduces friction for simple operations, and matches user expectations from the UI (where singletons are common). ### Changes required - Update `IntegerRangeSerializer.to_internal_value()` to normalize: - `int` → `(lo=val, hi=val)` - `list|tuple` of length 2 → `(lo, hi)` - Keep storage/representation semantics unchanged. ### Database changes None. ### External dependencies None. --- **Example:** ```json 53 ``` ```json [53, 53] ```
adam added the type: feature label 2025-12-29 21:48:36 +01:00
adam closed this issue 2025-12-29 21:48:36 +01:00
adam commented 2025-12-29 21:48:36 +01:00
Author
Owner
Copy Link

@pheus commented on GitHub (Oct 3, 2025):

I’m happy to open a PR if this enhancement is accepted.

@pheus commented on GitHub (Oct 3, 2025): I’m happy to open a PR if this enhancement is accepted.
adam commented 2025-12-29 21:48:37 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 9, 2025):

While I certainly appreciate the goal here, I have two concerns. The first is ensuring consistency between read and write operations. For example, the user would not expect to write

"vid_ranges": [10, [100, 199]]

and get back

"vid_ranges": [[10, 10], [100, 199]]

Which leads to my second concern: introducing heterogeneous types within the array. A list containing both tuples and integers, such as

[10, [100, 199]]

is more difficult to parse programmatically than one with only tuples, e.g.

[[10, 10], [100, 199]]

While the form is more natural to a human, humans aren't the primary users of the API.

@jeremystretch commented on GitHub (Oct 9, 2025): While I certainly appreciate the goal here, I have two concerns. The first is ensuring consistency between read and write operations. For example, the user would not expect to write ``` "vid_ranges": [10, [100, 199]] ``` and get back ``` "vid_ranges": [[10, 10], [100, 199]] ``` Which leads to my second concern: introducing heterogeneous types within the array. A list containing both tuples and integers, such as ``` [10, [100, 199]] ``` is more difficult to parse programmatically than one with only tuples, e.g. ``` [[10, 10], [100, 199]] ``` While the form is more natural to a human, humans aren't the primary users of the API.
adam commented 2025-12-29 21:48:37 +01:00
Author
Owner
Copy Link

@pheus commented on GitHub (Oct 9, 2025):

Thanks for taking a look at the feature request and for the thoughtful feedback.

For a bit of context: while working on port‑range support for the NetBox ACL plugin (which today deals with single ports), I was hoping to keep API usage simple by allowing single values. It felt reasonable to upstream, especially with potential UI support for singleton ranges in vid_ranges.

That said, I agree with your concerns: read/write symmetry and keeping a homogeneous type within arrays are more important for API consumers. Introducing inputs like [10, [100, 199]] would make parsing harder and could be surprising on round‑trip.

I’m happy to withdraw this proposal.

Thanks again for the quick review and guidance.

@pheus commented on GitHub (Oct 9, 2025): Thanks for taking a look at the feature request and for the thoughtful feedback. For a bit of context: while working on port‑range support for the NetBox ACL plugin (which today deals with single ports), I was hoping to keep API usage simple by allowing single values. It felt reasonable to upstream, especially with potential UI support for singleton ranges in `vid_ranges`. That said, I agree with your concerns: read/write symmetry and keeping a homogeneous type within arrays are more important for API consumers. Introducing inputs like `[10, [100, 199]]` would make parsing harder and could be surprising on round‑trip. I’m happy to withdraw this proposal. Thanks again for the quick review and guidance.
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 type: feature
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#11684
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?