Add Support for Hidden Relationships, Custom, and Computed Fields

Overview

There may be a need to store non-user facing data as a custom or computed field. It may be an ID or UUID that corresponds with other automation systems that need that data to do its job. There may also be a need to store custom fields or large computed fields that are primarily used for automation and there is no need for a user to see them in the UI. Having a radio button that is: “Display on Advanced Tab: Yes/No” should do the trick. This should be done with a boolean attribute named advanced_ui. The default should be current behavior.

User Story

As Austin a Network Automation Engineer, I want to be able to hide a custom and computed field within the UI, but still have it available in the API, So that users don’t need to see data that is mainly for machine-to-machine communication (and not meant for user consumption).

I know this is done when:

• When I can flag relationships, custom and computed fields to not be displayed on the object detail tab
• I can view the “hidden” fields on the “Advanced” tab
• No breaking changes should happen to the API, although the advanced_ui attribute should be exposed.

[brobare]

One example use case I can think of on the Device model: Some of our external platforms (NMS and secrets vault) use integers as identifying information. I’d like to be able to sore this in a Custom Field, but, its not really going to provide much use for an operator looking at the device in the UI.

For example https://secrets.example.com/?secretid=1234. I’d want to store 1234 as a CF on the Device model, but this is not going to provide much (usable) information for a user looking at the device.

I would use the CF data for Custom Links (linked directly to the asset in the secrets platform). This way, I’d have a Custom Link that took the user directly to the entry in the secrets platform without having to search for it.

[glennmatthews]

Should there be an option in the UI to show hidden fields temporarily? To me it feels a bit counter to the general goal of UI/REST/GraphQL/API feature parity to have things that are specifically blocked from ever being available to one of them.