Addressed comments

Signed-off-by: keithhc2 <keithhc2@users.noreply.github.com>
This commit is contained in:
keithhc2 2022-01-18 15:33:18 -08:00
parent 2da97978d4
commit d5cebf02e3
1 changed files with 1 additions and 1 deletions

View File

@ -31,7 +31,7 @@ Later, the user `psantos` wants to edit the monitor to run every two hours, but
After making the change, the monitor now runs with the same permissions as `psantos`, including any [document-level security]({{site.url}}{{site.baseurl}}/security-plugin/access-control/document-level-security/) queries, [excluded fields]({{site.url}}{{site.baseurl}}/security-plugin/access-control/field-level-security/), and [masked fields]({{site.url}}{{site.baseurl}}/security-plugin/access-control/field-masking/). If you use an extraction query to define your monitor, use the **Run** button to ensure that the response includes the fields you need.
Once a monitor is created, the Alerting plugin will continue executing the monitor, even if the user who created the monitor has write access permissions removed. To stop a monitor, a user with at least `alerting_write_access` permissions must manually disable or delete the monitor. This rule applies to all types of monitors, regardless of destination or any other setting.
Once a monitor is created, the Alerting plugin will continue executing the monitor, even if the user who created the monitor has write access permissions removed. To stop a monitor, a user with at least `alerting_write_access` permissions must manually disable or delete the monitor. This rule applies to all types of monitors, regardless of destination or any other setting. If your monitor's trigger has alerts configured, the Alerting plugin continues to send out alerts unless the trigger's action is manually deleted.
{: .note}
## (Advanced) Limit access by backend role