You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Building integrations for our own on-prem Catalog server, I've found that an empty value prevents resource patching. Let me give you an example.
I've added questions which supply parameters to a check command. Many of these parameters are optional, and I'd like to supply empty values ("") to the check command if the question is left blank.
They've provided this example with details:
I have a certificate expiration check, and I'd like to give the user the option to skip CA validation and just look at the expiration dates.
- type: question
name: extra
required: false
input:
type: string
title: Any extra parameters?
description: >-
For example, add "-k" to ignore certificate validation and just check the expiration
default: ""
It would have been cool to make this a boolean instead of a string and automagically add -k to the check command when the user opts for true, but that's a whole other ticket. Instead, I made my question a text string where the user can type in "-k".
If extra is left blank, the check command is unchanged from sensu-resources.yaml, ignoring values from location and warning and critical. I can kind of work around this one by setting default: " " for extra, as the extra space is harmless to check-cert.
In an internal conversation, the team suggested that instead of doing --warning "[[ warning ]]", to do [[ warning ]] and have it include the warning flag with a default.
However, they provided the following feedback:
Technically, yes, that should work, and I think I'll take this approach for now. However, I believe it presents a poor user experience, since one must carefully position the insertion cursor, instead of just, you know, clicking anywhere in the box and typing what you want. See the attached screeenshot for an example of how this would look.
The text was updated successfully, but these errors were encountered:
For context, see internal ref: https://secure.helpscout.net/conversation/2152482078/30839?folderId=5845954.
The main thrust of the issue is this:
They've provided this example with details:
In an internal conversation, the team suggested that instead of doing
--warning "[[ warning ]]"
, to do[[ warning ]]
and have it include the warning flag with a default.However, they provided the following feedback:
The text was updated successfully, but these errors were encountered: