Skip to content

Default values for custom_fields are ignored in API when custom_fields section is used #18669

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
antonvdl opened this issue Feb 19, 2025 · 3 comments · Fixed by #19115
Closed
Assignees
Labels
severity: low Does not significantly disrupt application functionality, or a workaround is available status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application
Milestone

Comments

@antonvdl
Copy link

Deployment Type

Self-hosted

NetBox Version

v4.2.3

Python Version

3.12

Steps to Reproduce

  1. Create multiple custom_fields with object type IPAM > Prefix
  • primary_subnet, type: boolean, required: yes, default value: true
  • ripe_admin, type: text, required: no, default value: "xxx-RIPE"
  • ripe_tech, type: text, required:no
  • ripe_netname, type: text, required: no
  1. Create a new prefix using API without custom_fields
    { "prefix": "10.0.0.0/24", "status": "active", "description": "Test prefix", "vlan": "147", "is_pool": false, "tenant": 6 }
  2. Create a new prefix using API with only "primary_subnet" as custom_field
    { "prefix": "10.0.0.0/24", "status": "active", "description": "Test prefix", "vlan": "147", "is_pool": false, "tenant": 6, "custom_fields": { "primary_subnet": true } }
  3. Create a new prefix using API with only "ripe_netname" as custom_field
    { "prefix": "10.0.0.0/24", "status": "active", "description": "Test prefix", "vlan": "147", "is_pool": false, "tenant": 6, "custom_fields": { "ripe_netname": "test" } }

Expected Behavior

  1. Custom fields are created
  2. Prefix is created with default values for custom_fields primary_subnet and ripe_admin. Other custom_fields are null
  3. Prefix is created with supplied value for custom_field primary_subnet, default value for ripe_admin. Other custom_fields are null
  4. Prefix is created with default values for custom_fields primary_subnet and ripe_admin. ripe_netname gets the supplied value and ripe_tech remains null

Observed Behavior

As soon as a custom_fields section is available in the POST Body then the default values for all custom_fields are ignored.
When I do not send the custom_fields section at all then the default values are used correctly.

  1. Custom fields are created (OK)
  2. Prefix is created with default values for primary_subnet and ripe_admin (OK)
  3. Prefix is created with primary_subnet set to true but other custom_fields are empty -> default value for ripe_admin is ignored
  4. Prefix is not created because primary_subnet (required) is not supplied -> default value for primary_subnet is ignored
@antonvdl antonvdl added status: needs triage This issue is awaiting triage by a maintainer type: bug A confirmed report of unexpected behavior in the application labels Feb 19, 2025
@bctiemann bctiemann added status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation severity: low Does not significantly disrupt application functionality, or a workaround is available and removed status: needs triage This issue is awaiting triage by a maintainer labels Feb 24, 2025
@atownson
Copy link
Contributor

atownson commented Mar 17, 2025

The same is also true for scripts that create instances of objects. Omitting the custom_field_data dict creates the object with the custom field default values as expected, but including the custom_field_data dict and omitting a required field does not set a value for the custom field.

You can deal with this in scripts like such (which might indicate how to solve this issue):

ip_address = IPAddress(
	address = '192.168.0.1/32'
)
ip_address.populate_custom_field_defaults()
ip_address.custom_field_data['my_custom_field'] = 'hard-coded value'
ip_address.full_clean()
ip_address.save()

@atownson
Copy link
Contributor

atownson commented Apr 7, 2025

I believe the issue is that the default values are not populated in CustomFieldsDataField.to_internal_value().

@atownson
Copy link
Contributor

atownson commented Apr 7, 2025

I can submit a PR for this.

@bctiemann bctiemann added status: accepted This issue has been accepted for implementation and removed status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation labels Apr 7, 2025
@jnovinger jnovinger added this to the v4.2.7 milestone Apr 8, 2025
@jeremystretch jeremystretch modified the milestones: v4.2.7, v4.2.8 Apr 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
severity: low Does not significantly disrupt application functionality, or a workaround is available status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants