Deprecation of _choices broke ability to read choices from accounts without write permissions on object model #4266

New Issue

adam · 2025-12-29T18:34:18+01:00

adam commented

2025-12-29 18:34:18 +01:00

Originally created by @ajknv on GitHub (Nov 10, 2020).

Environment

Python version: 3.6.8
NetBox version: 2.9.9

Steps to Reproduce

Create a user with read-only permissions and an associated API token.
Use the API token to make an OPTIONS request, for example to "dcim/devices".
Inspect response and observe that the "actions" key is missing, and thus the "choices" subkey that would provide information on the available choices.

Expected Behavior

The response should contain a nested key structure providing access to the choices, e.g. as readable by a lookup of the type response["actions"]["POST"]["type"]["choices"] or similar. This worked with the old "_choices" endpoint regardless of the permissions of the underlying user.

Observed Behavior

A degenerate response is returned lacking the "actions" key entirely:
{ "parses": [ "application/json", "application/x-www-form-urlencoded", "multipart/form-data" ], "renders": [ "application/json", "text/html" ], "name": "Device", "description": "" }
Given that the expected response places this information under a "POST" subkey (a write capability), it can be surmised that this is being impacted by the permissions of the underlying user. A comparison to a request made with an API token for a user with full write permissions appears to confirm this.
Clients without write permissions should still be able to obtain the set of choices, so as to be able to use Netbox itself as the authoritative source to construct enum abstractions that eliminate the need to scatter hardcoded magic constants throughout code.

Originally created by @ajknv on GitHub (Nov 10, 2020). ### Environment * Python version: 3.6.8 * NetBox version: 2.9.9 ### Steps to Reproduce 1. Create a user with read-only permissions and an associated API token. 2. Use the API token to make an OPTIONS request, for example to "dcim/devices". 3. Inspect response and observe that the "actions" key is missing, and thus the "choices" subkey that would provide information on the available choices. ### Expected Behavior The response should contain a nested key structure providing access to the choices, e.g. as readable by a lookup of the type response["actions"]["POST"]["type"]["choices"] or similar. This worked with the old "_choices" endpoint regardless of the permissions of the underlying user. ### Observed Behavior A degenerate response is returned lacking the "actions" key entirely: `{ "parses": [ "application/json", "application/x-www-form-urlencoded", "multipart/form-data" ], "renders": [ "application/json", "text/html" ], "name": "Device", "description": "" } ` Given that the expected response places this information under a "POST" subkey (a write capability), it can be surmised that this is being impacted by the permissions of the underlying user. A comparison to a request made with an API token for a user with full write permissions appears to confirm this. Clients without write permissions should still be able to obtain the set of choices, so as to be able to use Netbox itself as the authoritative source to construct enum abstractions that eliminate the need to scatter hardcoded magic constants throughout code.

adam closed this issue

2025-12-29 18:34:18 +01:00

adam commented

2025-12-29 18:34:19 +01:00

@jeremystretch commented on GitHub (Nov 16, 2020):

This is expected behavior: The response to the OPTIONS request is indicating the options available to the currently-authenticated user, and an API consumer may reasonably rely on this behavior.

While I can appreciate the desire for an alternative mechanism for retrieving the available options, one would need to be proposed via a detailed feature request. Please be sure to specify the particular mechanism you'd like to propose, bearing in mind that the behavior of the OPTIONS responses will not change.

@jeremystretch commented on GitHub (Nov 16, 2020): This is expected behavior: The response to the `OPTIONS` request is indicating the options available to the currently-authenticated user, and an API consumer may reasonably rely on this behavior. While I can appreciate the desire for an alternative mechanism for retrieving the available options, one would need to be proposed via a detailed feature request. Please be sure to specify the particular mechanism you'd like to propose, bearing in mind that the behavior of the `OPTIONS` responses will not change.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#4266