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

[bdlamprecht]

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.

[cimnine]

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]

Yes, I even opened an issue: #1792

[bdlamprecht]

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.

[cimnine]

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?

[bdlamprecht]

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?

[jeremystretch]

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.

[bdlamprecht]

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?

[cimnine]

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.

[bdlamprecht]

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]

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).