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

Different default value for 'custom_field' if created via WebUI vs RestAPI #1940

New Issue
Closed
opened 2025-12-29 17:20:45 +01:00 by adam · 10 comments
adam commented 2025-12-29 17:20:45 +01:00
Owner
Copy Link

Originally created by @bdlamprecht on GitHub (Aug 14, 2018).

Environment

  • Python version: 3.6
  • NetBox version: 2.4.3

This was a feature request in #2159.

I don't recall if it used to work the same way consistently, but I just verified that the result is different if the operation is performed via the WebUI vs the API.

Steps to Reproduce

  1. Create a new custom_field and set it up against an Object (I chose to apply this to dcim > site).
  2. Choose type Selection and setup the Custom Field Choices appropriately.
  3. Then add a value for the "default" that matches exactly to one of the previously defined Choices.
  4. Create a new Object via the WebUI, and it works as expected.
  5. Attempt the same type of creation via the API, and the default gets left alone.

Expected Behavior

Have both the WebUI and API operate the same way.

Observed Behavior

The default value is correctly applied ONLY if done in the WebUI.

Originally created by @bdlamprecht on GitHub (Aug 14, 2018). ### Environment * Python version: 3.6 * NetBox version: 2.4.3 This was a feature request in #2159. I don't recall if it _used_ to work the same way consistently, but I just verified that the result is different if the operation is performed via the WebUI vs the API. ### Steps to Reproduce 1. Create a new `custom_field` and set it up against an `Object` (I chose to apply this to `dcim > site`). 2. Choose type `Selection` and setup the `Custom Field Choices` appropriately. 3. Then add a value for the "default" that matches **exactly** to one of the previously defined `Choices`. 4. Create a new `Object` via the WebUI, and it works as expected. 5. Attempt the same type of creation via the API, and the default gets left alone. ### Expected Behavior Have both the WebUI and API operate the same way. ### Observed Behavior The `default` value is correctly applied **ONLY** if done in the WebUI.
adam added the type: bugstatus: accepted labels 2025-12-29 17:20:45 +01:00
adam closed this issue 2025-12-29 17:20:45 +01:00
adam commented 2025-12-29 17:20:46 +01:00
Author
Owner
Copy Link

@cimnine commented on GitHub (Aug 15, 2018):

You are aware that you must put the ID of the choice in your request, rather than the value of the choice via the API, right?

Maybe post your POST/PUT/PATCH request for easier debugging.

At least that's how I remember it to be.

@cimnine commented on GitHub (Aug 15, 2018): You are aware that you must put _the ID of the choice_ in your request, rather than _the value of the choice_ via the API, right? Maybe post your POST/PUT/PATCH request for easier debugging. At least that's how I remember it to be.
adam commented 2025-12-29 17:20:46 +01:00
Author
Owner
Copy Link

@cimnine commented on GitHub (Aug 15, 2018):

Yes, I even opened an issue: #1792

@cimnine commented on GitHub (Aug 15, 2018): Yes, I even opened an issue: #1792
adam commented 2025-12-29 17:20:46 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Aug 15, 2018):

I'm not sure what you're trying to communicate here, so if there's a question, I would appreciate if you re-phrased it so I can respond appropriately.

@bdlamprecht commented on GitHub (Aug 15, 2018): I'm not sure what you're trying to communicate here, so if there's a question, I would appreciate if you re-phrased it so I can respond appropriately.
adam commented 2025-12-29 17:20:46 +01:00
Author
Owner
Copy Link

@cimnine commented on GitHub (Aug 15, 2018):

So you said you made a selection custom field.
And that you tried to use the API to set the value of the custom field to one of the configured choices.

I tried to say that I suspect that you have sent the actual value of the coice via the API. But you must rather send the ID of the choice, not the actual value. (i.e. a number, not a string.)

But there is no way (via the API) yet to get the id of a certain choice. That's what the issue which I mentioned is all about.

Clearer?

@cimnine commented on GitHub (Aug 15, 2018): So you said you made a selection custom field. And that you tried to use the API to set the value of the custom field to one of the configured choices. I tried to say that I suspect that you have sent the actual value of the coice via the API. But you must rather send the ID of the choice, not the actual value. (i.e. a number, not a string.) But there is no way (via the API) yet to get the id of a certain choice. That's what the issue which I mentioned is all about. Clearer?
adam commented 2025-12-29 17:20:47 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Aug 15, 2018):

I probably didn't make this clear in my "Steps to Reproduce" above, but I'm not any setting information via the WebUI or via the API except for the required fields (in my case, for dcim.Site, is name, slug, and status).

I'm expecting that the default value which I specified to be set occurs when a NEW object is created via both the WebUI and via the API.

Does that clarify the problem I'm reporting it at all?

@bdlamprecht commented on GitHub (Aug 15, 2018): I probably didn't make this clear in my "**Steps to Reproduce**" above, but I'm not _any_ setting information via the WebUI or via the API _except_ for the `required` fields (in my case, for `dcim.Site`, is `name`, `slug`, and `status`). I'm expecting that the `default` value which I specified to be set occurs when a **NEW** object is created via both the WebUI _and_ via the API. Does that clarify the problem I'm reporting it at all?
adam commented 2025-12-29 17:20:47 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 22, 2018):

I'm not sure that it makes sense to implement this change. Just because a custom field has a default value doesn't necessarily imply that the field should be set on every new instance. The default makes sense for the web UI, since the field is merely pre-populated and the user must confirm (or remove/modify) the field value before submitting the form. When using the API, the user never has this opportunity.

@jeremystretch commented on GitHub (Aug 22, 2018): I'm not sure that it makes sense to implement this change. Just because a custom field has a default value doesn't necessarily imply that the field should be set on every new instance. The default makes sense for the web UI, since the field is merely pre-populated and the user must confirm (or remove/modify) the field value before submitting the form. When using the API, the user never has this opportunity.
adam commented 2025-12-29 17:20:47 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Aug 22, 2018):

I'm not sure I agree with that assessment and here's why...

If I create a new object in the WebUI that has a custom_field with a default value set in the /admin area, it should work the same way if the object gets created via the API as well.

As an example, and to demonstrate my use case, our WAN is being upgraded from using a 4 class-of-service queuing to a 6 class-of-service queuing, one site at a time (500+ sites total).

When applied to this scenario, all sites should be set to have a their CE devices use a 4_cos setting. When a site gets upgraded with CE devices that support the additional queuing classes, then the default value of 4_cos can be changed to 6_cos manually.

If the default value is not set via the API, the value will be null which, in this instance, is worthless.

Does that make sense?

@bdlamprecht commented on GitHub (Aug 22, 2018): I'm not sure I agree with that assessment and here's why... If I create a new object in the WebUI that has a `custom_field` with a default value set in the `/admin` area, it **should** work the same way if the object gets created via the API as well. As an example, and to demonstrate my use case, our WAN is being upgraded from using a `4 class-of-service queuing` to a `6 class-of-service queuing`, one site at a time (500+ sites total). When applied to this scenario, all `sites` should be set to have a their `CE` devices use a `4_cos` setting. When a `site` gets upgraded with `CE` devices that support the additional queuing classes, then the default value of `4_cos` can be changed to `6_cos` manually. If the default value is _**not**_ set via the API, the value will be `null` which, in this instance, is worthless. Does that make sense?
adam commented 2025-12-29 17:20:47 +01:00
Author
Owner
Copy Link

@cimnine commented on GitHub (Aug 22, 2018):

I see another reason to implement this:

When creating an object via API, how does the client know, what the default value is? It simply doesn't and must have this knowledge from somewhere else.

Now if the default value changes in Netbox, the client must be updated as well because he would otherwise create objects with the previous default value, as he has no way to receive the new default value.

And if the client does not want the default value to be filled in by Netbox, he could still pass "cf_field_name": null.

@cimnine commented on GitHub (Aug 22, 2018): I see another reason to implement this: When creating an object via API, how does the client know, what the default value is? It simply doesn't and must have this knowledge from somewhere else. Now if the default value changes in Netbox, the client must be updated as well because he would otherwise create objects with the previous default value, as he has no way to receive the new default value. --- And if the client does not want the default value to be filled in by Netbox, he could still pass `"cf_field_name": null`.
adam commented 2025-12-29 17:20:47 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Sep 5, 2018):

I'm not sure where this ended up at so I thought I would comment again...

Has a decision been made to fix this bug or implement this FR?

I really don't like having to keep track of how an object was created (via the WebUI versus the API).
However, this is what is required in the current implementation.

I understand there is only so much development that can be done, but the idea of not being deterministic in the creation of new objects is of concern to me.

I suppose all I'm asking is for a decision to be made and this issue to be updated to reflect that.

@bdlamprecht commented on GitHub (Sep 5, 2018): I'm not sure where this ended up at so I thought I would comment again... Has a decision been made to fix this `bug` or implement this `FR`? I really don't like having to keep track of how an object was created (via the `WebUI` versus the `API`). However, this is what is required in the current implementation. I understand there is only so much development that can be done, but the idea of not being deterministic in the creation of new objects is of concern to me. I suppose all I'm asking is for a decision to be made and this issue to be updated to reflect that.
adam commented 2025-12-29 17:20:47 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Feb 12, 2019):

Just checking in on the status of this issue...

I think @cimnine's comment above is as straightforward as it can be:

When creating an object via API, how does the client know, what the default value is? It simply doesn't and must have this knowledge from somewhere else.

When setting the default value in the for a custom_field, that value should be populated no matter how the object was created (via the API or the WebUI).

@bdlamprecht commented on GitHub (Feb 12, 2019): Just checking in on the status of this issue... I think @cimnine's comment above is as straightforward as it can be: >When creating an object via API, how does the client know, what the default value is? It simply doesn't and must have this knowledge from somewhere else. When setting the default value in the for a `custom_field`, that value should be populated no matter how the object was created (via the API or the WebUI).
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 status: accepted 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#1940
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?