Support CustomField UI visibility in 3.8

[bluikko]

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.

[bluikko]

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]

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]

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]

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.

[sc68cal]

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.

[bluikko]

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.

[rodvand]

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

[sc68cal]

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

[bluikko]

Will rework this to 2x boolean then.