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
When an event is submitted which does not include an entry for that field
Then the slack message sent should not include the field element
Scenario
Using fields for tips or url links in alert configurations. Sometimes our alerts include them, sometimes they dont. In all cases currently the message includes blank sections which isn't very attractive.
There may be an argument for showing the field name and not including a value at all to demonstrate that the user hasn't included this information, but that seems to be implict based on its absence on a message?
The text was updated successfully, but these errors were encountered:
I definitely see the value although I think there should be an option for it but the default should be off.
Reasons why it should default off:
remaining backwards compatible
I think that is an excellent way to prompt people to start writing those tips/links/runbooks when they resolve the incident they should think about adding it.
Such that the assigned value is used as a default, and if set to nil is simply omitted from display if no client value has set it.
Note; I have an extended use case/pull request to develop which will include event field custom values in this listing, such that events themselves can include metadata to submit on alerts
How about include_missing_fields with a default of true. I generally dislike having "negative" variable/option names in code when dealing with booleans. The reason is that it is much clearer and avoids needing to eval true as false when I am quickly reviewing code/documentation I am unfamiliar with.
I suppose we could make a more structural change and have a render flag and if evals nil||true we would include it. If it evals as false we would not render.
Scenario
Using fields for tips or url links in alert configurations. Sometimes our alerts include them, sometimes they dont. In all cases currently the message includes blank sections which isn't very attractive.
There may be an argument for showing the field name and not including a value at all to demonstrate that the user hasn't included this information, but that seems to be implict based on its absence on a message?
The text was updated successfully, but these errors were encountered: