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

Allow ordering by custom fields when using the REST API #9200

New Issue
Open
opened 2025-12-29 20:46:53 +01:00 by adam · 4 comments
adam commented 2025-12-29 20:46:53 +01:00
Owner
Copy Link

Originally created by @Yutsuten on GitHub (Feb 6, 2024).

NetBox version

v3.7.1

Feature type

Change to existing functionality

Proposed functionality

This is a continuation of #14854

Currently the ordering parameter on API requests do not allow the usage of custom fields. It only allows predetermined fields (name, site, etc) to be used.

I propose that we could also use custom fields on ordering too. So when generating a GET request to /api/dcim/devices/?ordering=cf_cpu, for instance, the data would be sorted by the custom field cpu.

We can do that on the NetBox's web interface already, where the sort parameter is used instead. The expected output is the same, but using the API interface.

Use case

There are two reasons for my project to need this:

  1. Usage of NetBox as a component (it is part of a bigger project)
  2. The extensive usage of custom fields

Starting with 1. NetBox is an excellent tool to organize devices in a network. That's why we're using it. But we want to do more than just organize the data. We want to access it's data from another components. We want to extend it's functionality. So, for instance, we want to take actions on the devices that are registered on NetBox: Component "ABC" get NetBox data, run some commands over the network, and finally it may make some updates to NetBox.
All of this "communication" between components happens using the REST API. We do stuff that is out of scope of NetBox itself. That's why the API exists after all, right?

Now with 2. In my use case, a device, for example, goes beyond what NetBox means it to be. It may mean an actual server, with CPU, memory, disk capacity, etc. And custom fields are used to store these data. (In fact there is much more than that. There are things that are so specific to my use case that it is out of scope for asking to add these to NetBox.).

The component used to store data (NetBox) and the component used to run actions (let's call it Component "ABC") are different. The Component "ABC" also have an user interface, and it may show data in a similar way NetBox does. That's why we want to allow custom field sorting using the API too.

Database changes

Not required.

External dependencies

Not required.

Originally created by @Yutsuten on GitHub (Feb 6, 2024). ### NetBox version v3.7.1 ### Feature type Change to existing functionality ### Proposed functionality This is a continuation of #14854 Currently the `ordering` parameter on API requests do not allow the usage of custom fields. It only allows predetermined fields (name, site, etc) to be used. I propose that we could also use custom fields on `ordering` too. So when generating a GET request to `/api/dcim/devices/?ordering=cf_cpu`, for instance, the data would be sorted by the custom field `cpu`. We can do that on the NetBox's web interface already, where the `sort` parameter is used instead. The expected output is the same, but using the API interface. ### Use case There are two reasons for my project to need this: 1. Usage of NetBox as a component (it is part of a bigger project) 2. The extensive usage of custom fields Starting with 1. NetBox is an excellent tool to organize devices in a network. That's why we're using it. But we want to do more than just organize the data. We want to access it's data from another components. We want to extend it's functionality. So, for instance, we want to take actions on the devices that are registered on NetBox: Component "ABC" get NetBox data, run some commands over the network, and finally it may make some updates to NetBox. All of this "communication" between components happens using the REST API. We do stuff that is out of scope of NetBox itself. That's why the API exists after all, right? Now with 2. In my use case, a `device`, for example, goes beyond what NetBox means it to be. It may mean an actual server, with CPU, memory, disk capacity, etc. And custom fields are used to store these data. (In fact there is much more than that. There are things that are **so** specific to my use case that it is out of scope for asking to add these to NetBox.). The component used to store data (NetBox) and the component used to run actions (let's call it Component "ABC") are different. The Component "ABC" also have an user interface, and it may show data in a similar way NetBox does. That's why we want to allow custom field sorting using the API too. ### Database changes Not required. ### External dependencies Not required.
adam commented 2025-12-29 20:46:53 +01:00
Author
Owner
Copy Link

@jeffgdotorg commented on GitHub (Feb 6, 2024):

Thank you for the additional detail in this issue versus its bug precursor.

At the moment we're in something of a freeze where custom field work is concerned, so I'm marking this issue as blocked by #14000. Once that work to re-architect the representation of custom fields is done, we can work on scheduling this feature work.

@jeffgdotorg commented on GitHub (Feb 6, 2024): Thank you for the additional detail in this issue versus its bug precursor. At the moment we're in something of a freeze where custom field work is concerned, so I'm marking this issue as blocked by #14000. Once that work to re-architect the representation of custom fields is done, we can work on scheduling this feature work.
adam commented 2025-12-29 20:46:54 +01:00
Author
Owner
Copy Link

@kidonson commented on GitHub (May 31, 2024):

I'm also interested in this feature, and I noticed #14000 has been closed. Is this no longer blocked?

@kidonson commented on GitHub (May 31, 2024): I'm also interested in this feature, and I noticed #14000 has been closed. Is this no longer blocked?
adam commented 2025-12-29 20:46:54 +01:00
Author
Owner
Copy Link

@michi-sab commented on GitHub (Jul 23, 2024):

Also interested in this feature. Is there any plan for implementing it?

@michi-sab commented on GitHub (Jul 23, 2024): Also interested in this feature. Is there any plan for implementing it?
adam commented 2025-12-29 20:46:54 +01:00
Author
Owner
Copy Link

@sylvia-cs commented on GitHub (Jan 2, 2025):

Would also be interested in this feature.

@sylvia-cs commented on GitHub (Jan 2, 2025): Would also be interested in this feature.
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 complexity: medium needs milestone netbox status: backlog 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#9200
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?