Skip to content

Support CustomField UI visibility in 3.8 #1136

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.

Sign up for GitHub

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

Draft
wants to merge 4 commits into
base: devel
Choose a base branch
from
Draft

Support CustomField UI visibility in 3.8 #1136

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
01e41df
Support CustomField UI visibility in 3.8
bluikko Dec 22, 2023
4d9735b
Add docs for 3.8 CustomField UI visibility
bluikko Dec 22, 2023
0ebab1f
Use docs semantic markup
bluikko Dec 25, 2023
ef6c251
Quote ui_editable values
bluikko Dec 27, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
92 changes: 92 additions & 0 deletions docs/plugins/netbox_custom_field_module.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -612,6 +612,98 @@ Parameters
- :ansible-option-choices-entry:`"multiobject"`


.. raw:: html

</div>

* - .. raw:: html

<div class="ansible-option-indent"></div><div class="ansible-option-cell">
<div class="ansibleOptionAnchor" id="parameter-data/ui_editable"></div>

.. _ansible_collections.netbox.netbox.netbox_custom_field_module__parameter-data/ui_editable:

.. rst-class:: ansible-option-title

**ui_editable**

.. raw:: html

<a class="ansibleOptionLink" href="#parameter-data/ui_editable" title="Permalink to this option"></a>

.. rst-class:: ansible-option-type-line

:ansible-option-type:`string`

:ansible-option-versionadded:`added in netbox.netbox 3.17.0`


.. raw:: html

</div>

- .. raw:: html

<div class="ansible-option-indent-desc"></div><div class="ansible-option-cell">

Whether the custom field is editable in the UI


.. rst-class:: ansible-option-line

:ansible-option-choices:`Choices:`

- :ansible-option-choices-entry:`"yes"`
- :ansible-option-choices-entry:`"no"`
- :ansible-option-choices-entry:`"hidden"`


.. raw:: html

</div>

* - .. raw:: html

<div class="ansible-option-indent"></div><div class="ansible-option-cell">
<div class="ansibleOptionAnchor" id="parameter-data/ui_visible"></div>

.. _ansible_collections.netbox.netbox.netbox_custom_field_module__parameter-data/ui_visible:

.. rst-class:: ansible-option-title

**ui_visible**

.. raw:: html

<a class="ansibleOptionLink" href="#parameter-data/ui_visible" title="Permalink to this option"></a>

.. rst-class:: ansible-option-type-line

:ansible-option-type:`string`

:ansible-option-versionadded:`added in netbox.netbox 3.17.0`


.. raw:: html

</div>

- .. raw:: html

<div class="ansible-option-indent-desc"></div><div class="ansible-option-cell">

Whether the custom field is displayed in the UI


.. rst-class:: ansible-option-line

:ansible-option-choices:`Choices:`

- :ansible-option-choices-entry:`"always"`
- :ansible-option-choices-entry:`"if-set"`
- :ansible-option-choices-entry:`"hidden"`


.. raw:: html

</div>
Expand Down
39 changes: 39 additions & 0 deletions plugins/modules/netbox_custom_field.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -106,9 +106,30 @@
required: false
type: str
version_added: "3.10.0"
ui_editable:
description:
- Whether the custom field is editable in the UI
required: false
choices:
- "yes"
- "no"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

  1. Present 2 different boolean parameters instead of presenting ui_editable as a string value: ui_editable and ui_editable_hidden. Based on the combined value of these 2 parameters decide if give yes no or hidden to NetBox API.
  2. Use some other values than yes and no as values ui_editable: module parameters takes other values for example read-write and calls NetBox API with yes; value read-only means no and hidden stays 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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@sc68cal sc68cal Jan 7, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also think option 1 is the best solution. I'm not crazy about this trilean that the netbox API is exposing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will rework this to 2x boolean then.

Copy link

@Jacob-gr Jacob-gr Jan 2, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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_if block in netbox_custom_field.py to 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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excellent research, this would remove my concern.

- hidden
type: str
version_added: "3.17.0"
ui_visible:
description:
- Whether the custom field is displayed in the UI
required: false
choices:
- always
- if-set
- hidden
type: str
version_added: "3.17.0"
ui_visibility:
description:
- The UI visibility of the custom field
- Replaced by O(ui_visible) and O(ui_editable) in NetBox 3.7
required: false
choices:
- read-write
Expand Down Expand Up @@ -245,6 +266,24 @@ def main():
weight=dict(required=False, type="int"),
search_weight=dict(required=False, type="int"),
group_name=dict(required=False, type="str"),
ui_editable=dict(
required=False,
choices=[
"yes",
"no",
"hidden",
],
type="str",
),
ui_visible=dict(
required=False,
choices=[
"always",
"if-set",
"hidden",
],
type="str",
),
ui_visibility=dict(
required=False,
choices=[
Expand Down