Skip to content
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

Support CustomField UI visibility in 3.8 #1136

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

Conversation

bluikko
Copy link
Contributor

@bluikko bluikko commented Dec 22, 2023

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_visibility for backwards
compatibility 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

  • I have read the comments and followed the CONTRIBUTING.md.
  • I have explained my PR according to the information in the comments or in a linked issue.
  • My PR targets the devel branch.

Add ui_editable and ui_visible parameters.
@bluikko
Copy link
Contributor Author

bluikko commented Dec 22, 2023

Tests are missing at this point. I see that they will need to be changed also.
It looks like 2 new files are needed, tests/integration/targets/v3.7/tasks/main.yml that includes for now only testtests/integration/targets/v3.7/tasks/netbox_custom_field.yml.

@bluikko
Copy link
Contributor Author

bluikko commented Dec 22, 2023

Not sure what to do with the CI sanity test failure. I get that Ansible "helpfully" treats yes/true & no/false as the same.
But these are not boolean values they are strings, and in the module doc block listed accordingly as string.

@sc68cal
Copy link
Contributor

sc68cal commented Dec 23, 2023

YAML converts yes and no to boolean fields, you cannot use those values as strings. Consider changing it to a boolean and just supporting true/false and not have the hidden value

@bluikko
Copy link
Contributor Author

bluikko commented Dec 25, 2023

Consider changing it to a boolean and just supporting true/false and not have the hidden value

It would be very disappointing to not have full feature parity especially since I would definitely want to use the hidden feature.
I believe a workaround would be to split this into 2 different boolean parameters:

  1. ui_editable.
  2. ui_editable_hidden.

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?
Any user of the module wanting to use ui_visible will then need to quote "yes" and "no" in the module parameters if they are using ansible-lint.

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"
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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants