ui_editable and NetBox Ansible module compatibility

[bluikko]

This might sound like a ridiculous request. While the new ui_editable CustomField attribute is nice but it does not work with the NetBox Ansible module.

Ansible modules are ran through a CI pipeline that cannot work with values yes and no because they are treated as boolean and required to be true and false instead.
AFAIK this test is part of ansible-test and is not a part of NetBox Ansible module. Getting this changed in ansible-test is most likely not possible since they want to make sure everyone uses true / false instead of yes/no.

I wonder if it would be possible to re-think how ui_editable works and perhaps not use "yes" and "no" as values.

Otherwise the Ansible module is forced to present 2 boolean parameters to the user: one for whether the field is editable and second for whether it is hidden while editing.

I'd also hope that this raises awareness of the issue so that such a situation might be avoided in the future.

[jeremystretch]

The ui_editable field is not a boolean field: It supports three choices, hence the use of "yes" and "no," in addition to "hidden." This is similar to the field it replaced, ui_visibility (see #13299), so I'm not sure why this is being presented as a new thing.

If it's necessary for the Ansible module to interact with these fields, it will need to be updated to function with all the available choices.

[bluikko]

I'm not sure I understand what you are saying. Aren't the values of the old ui_visbility: read-write read-only hidden etc.; not yes and no that are special in Ansible (and I've been told in YAML as well)?

I will try to summarize the issue: the new ui_editable uses values of yes and no that cannot be passed to Ansible modules as parameter values due to how Ansible modules are tested. This will leave 2 options for the module:

1. Present ui_editable to Ansible users as 2 different parameters ui_editable and ui_editable_hidden that are of type boolean. The module will then call NetBox API with either yes no or hidden based on the combination of those 2 parameters.
2. Use something else as Ansible module parameter values instead of yes and no and just pass them as yes and no respectively to NetBox API.

Some other options exist but I believe the above are better options.

Option 1 is rather simple to implement. Option 2 would make the module differ from NetBox API in a different subtle way. The Ansible module has so far, to my limited knowledge, conformed to the NetBox API with regards to module parameters which is good.

At minimum I hope that this discussion might affect future features: using yes and no as API values will never work with the NetBox Ansible module. The Ansible module will be forced to be called with different values instead of yes and no.

[jeremystretch]

They're all string values, not booleans, and need to be treated as such. You may be running into an issue where an older version of the YAML spec interprets "yes" as "true;" in this case, make sure you're encasing the value in quotes. See this thread for more detail.

[bluikko]

It does not matter how they are treated.

The Ansible module parameters are tested and it simply won't accept yes and no as values.

Correction: quoting the values in the Ansible module docs does make the testing succeed. So thanks for your suggestion.
Then any user of the NetBox Ansible module will also need to quote those "yes" and "no" values in module parameters if they use ansible-lint (or add directives to skip linting of those).

I'm not convinced this will be an acceptable solution for the Ansible module so we will see...

Is there a reason why the values to ui_editable are not simply true false hidden? Or, similar to ui_visible something like read-write read-only hidden?

[jeremystretch]

I'm not convinced this will be an acceptable solution for the Ansible module so we will see...

It's not a matter of acceptance: It's how older versions of the YAML spec work. Fortunately, this has been corrected in in YAML 1.2.0 so that only true and false are interpreted as booleans. So, you can either stick with the older spec and encapsulate these values in quotes, or update to the newer spec.

Is there a reason why the values to ui_editable are not simply true false hidden?

Yes: The values of true and false strongly imply a boolean attribute, which ui_editable is not. We intentionally avoid using these as string values to prevent confusion.

[bluikko]

I'm not convinced this will be an acceptable solution for the Ansible module so we will see...

It's not a matter of acceptance: It's how older versions of the YAML spec work. Fortunately, this has been corrected in in YAML 1.2.0 so that only true and false are interpreted as booleans. So, you can either stick with the older spec and encapsulate these values in quotes, or update to the newer spec.

I mean if it is acceptable for the Ansible module project to force users to quote values for one certain module parameter.
In the end the Ansible module project will need to decide which workaround is the least bad one.

Thanks for your help. I don't think there's any more to say and I will close this discussion.