[Alerting] Should we use custom deprecated messages for removing .enabled config?

[chrisronline]

Relates to #114188

In #114188, the core team is advising plugin authors to ensure the default messaging around the .enabled deprecation is the best UX. If not, they are recommending to use custom messaging with examples of how to do that.

Plugin	Should we?
Actions	?
Alerting	?
Stack alerts	?
Task manager	?
Event log	?

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[pmuellr]

Wondering if we want to add some doc on the new enabled/disabled config going away, and how to tell users to perform equivalent functionality. For instance, using feature controls to make sure no one has access to the feature ...

We could leave the message as is, and customize it later if we find it's confusing users - by including a link to the docs, for instance.

[chrisronline]

@pmuellr Which plugins have something like that to even mention in the docs? I know we added #111036 to give users a way to disable tasks from execution (which we felt was a replacement for disabling actions/alerting plugins directly)

[pmuellr]

I doubt any other plugins have anything like that in their doc, but alerting is special! :-)

I believe we did recently update a logged message to include a link to the doc, since it remediation wasn't something we'd really want in just an error message - can't remember what message that was though.

I was thinking of it more as a way to not have to bake details into the messages, but instead bake it into the doc, since it's probably a good thing to doc anyway (hmmm, didn't it just come up in an internal conversation? :-) )

[mikecote]

I believe we did recently update a logged message to include a link to the doc, since it remediation wasn't something we'd really want in just an error message - can't remember what message that was though.

I was thinking of it more as a way to not have to bake details into the messages, but instead bake it into the doc, since it's probably a good thing to doc anyway (hmmm, didn't it just come up in an internal conversation? :-) )

This was the thread we had back in August around linking to documentation on the server side: #109741 (comment) 🙂 The limitation was around not knowing the documentation URL + version suffix. But the thread explored a way to work around it for now.

[ymao1]

It looks like enabled is not part of the Alerting plugin config (and looking through the code history, has never been?) so setting xpack.alerting.enabled doesn't generate a deprecation message, just an error message due to invalid config.

[ymao1]

Closed with #120151