Support CustomField UI visibility in 3.8 #1136
Conversation
Add ui_editable and ui_visible parameters.
|
Tests are missing at this point. I see that they will need to be changed also. |
|
Not sure what to do with the CI sanity test failure. I get that Ansible "helpfully" treats yes/true & no/false as the same. |
|
YAML converts |
It would be very disappointing to not have full feature parity especially since I would definitely want to use the
I have opened a probably futile discussion item in netbox-community/netbox, let's see if there is any feedback before going down the route of 2 boolean parameters. Added: quoting the values seem to work. Not sure how good of a practice that is, any comments? |
Use docs semantic markup to refer to other options and fix a typo in markup.
Quote truthy looking values to treat them as strings.
| required: false | ||
| choices: | ||
| - "yes" | ||
| - "no" |
There was a problem hiding this comment.
These values are going to cause a lot of confusion, people are going to just use yes and no without strings and YAML will convert them to booleans, and then the module will throw an error and they'll come here asking why it doesn't work.
There was a problem hiding this comment.
Exactly and that is what my comments above are about.
I 100% agree.
I need feedback on what is the preferred solution to work around this. I do not think forcing users to quote values to just one module parameter is reasonable, at all.
Two other possible options:
- Present 2 different boolean parameters instead of presenting
ui_editableas a string value:ui_editableandui_editable_hidden. Based on the combined value of these 2 parameters decide if giveyesnoorhiddento NetBox API. - Use some other values than
yesandnoas valuesui_editable: module parameters takes other values for exampleread-writeand calls NetBox API withyes; valueread-onlymeansnoandhiddenstays the same.
Open to other suggestions or feedback on these 2. I had an open discussion item at the netbox project and suggestions to not use yes and no in the NetBox API were ignored.
Both will make the module API diverge from NetBox API which will be sad.
There was a problem hiding this comment.
I think Option 1 of the other options is the best one. If we're diverging from the NetBox API we may as well do it the best way we can. Thanks for your work on this @bluikko
There was a problem hiding this comment.
I also think option 1 is the best solution. I'm not crazy about this trilean that the netbox API is exposing.
There was a problem hiding this comment.
Will rework this to 2x boolean then.
There was a problem hiding this comment.
In looking to address the problem of ui_visible and ui_editable, I came across this old pull request.
I understand the concern of yes and no values being treated as booleans when not wrapped in quotes. However, when I was testing this out, it appears that as long as the argument_spec dict is declaring ui_editable and ui_visible as a type=str in netbox_custom_field.py, it will convert the yes and no values into strings automatically.
To examine it further, I logged module output and observed the following:
When using ui_editable: no (declared as a bool) in the Ansible task, the module.params in netbox_custom_field.py ended up as a string of 'no'. The task worked as expected and the object was created in NetBox.
Log details:
2025-01-02 14:55:10,774 - __main__ (netbox_custom_field.py) - DEBUG - Module params: {'netbox_url': 'https://netbox.example.io', 'netbox_token': 'SomeToken', 'data': {'description': 'Security Onion Hostname', 'filter_logic': 'exact', 'group_name': 'A Group', 'label': 'Hostname', 'name': 'somehostname', 'object_types': ['virtualization.virtualmachine'], 'required': True, 'type': 'text', 'ui_visible': 'if-set', 'ui_editable': 'no', 'validation_regex': '^[a-z0-9\\-]+$', 'weight': 5, 'content_types': None, 'object_type': None, 'default': None, 'search_weight': None, 'ui_visibility': None, 'validation_minimum': None, 'validation_maximum': None, 'choices': None}, 'state': 'present', 'validate_certs': True, 'query_params': None, 'cert': None}
When converting ui_editable to type=bool and removing the choices, only then was ui_editable: no treated as a bool and appeared as False in the module params. This did throw an error, as predicted.
I'm new to using Ansible, so I'm not sure if this was a change in the library or if my testing is flawed, but it appears there shouldn't be an issue even if users use no or yes without quotes. In light of this, I'd like to be able to just use yes, no, and hidden as it is documented in the API. Similar with ui_visibile: I'd prefer just to have the API values available.
Would this information contribute to this pull request being approved?
Versions and Misc.:
- Netbox version --> NetBox Community v4.1.10 (2024-12-23)
- ansible version --> ansible [core 2.18.1]
- netbox.netbox version --> 3.20.0
- Had to update the
required_ifblock innetbox_custom_field.pyto be("state", "present", ["object_types", "name"])instead of("state", "present", ["content_types", "name"]). Maybe a change due to more recent netbox version? content_types wasn't useable for me and produced an error.
There was a problem hiding this comment.
Excellent research, this would remove my concern.
Related Issue
#1135
New Behavior
Add to CustomField the 2 new UI visibility parameters.
Contrast to Current Behavior
Add ui_editable and ui_visible parameters that are new in NetBox 3.8.
Discussion: Benefits and Drawbacks
Just add the new parameters and keep the old
ui_visibilityfor backwardscompatibility with pre-3.7.
Changes to the Documentation
Added the 2 new parameters to module documentation.
Proposed Release Note Entry
Support CustomField UI visibility in NetBox 3.8.
Double Check
develbranch.