When a problem check is run with an invalid target, which can happen if
a target is dynamically removed from the list, we destroy the problem
check tracker.
This makes it so that we also clean up any associated admin notices when
this happens.
It also marks `target` as required. This is because we now use
`__NULL__` to indicate "no target". This allows us to clean up the Ruby
implementation a bit. (Context: this is required for uniqueness checks
to work, since PostgreSQL considers `NULL` values to be distinct.)
When running scheduled problem checks (which happens every 10 minutes), it uses the next_run_at to see if enough time has passed to check again. This causes the check to run every 10 minutes, regardless of its perform_every config.
This timestamp isn't getting updated when the problem check passed without detecting any problems. (It works correctly when there are problems.)
We have many problem check trackers, and some of them
like `OutOfDateThemes` can have a message which has variable
data in it shown to admins. In this case, a list of themes
that need updating. Currently if you resolve one of these
out of date themes and refresh the list of problems, you
do not see any change.
This is happening because we are only updating the `details`
of the `ProblemCheckTracker` record, not the corresponding
`AdminNotice` record which is what is displayed to the admins
on their dashboard. This commit fixes the issue by updating the
details of the notice at the same time as the problem check
tracker details.
In #29169 we added a NULLS NOT DISTINCT option to the unique index on problem_check_trackers. This is to enforce uniqueness even when the target is NULL. (Postgres considers all NULLs to be distinct by default.)
However, this only works in PG15. In PG13 it does nothing.
This commit adds a default dummy string value __NULL__ to target. Since it's a string, PG13 will be able to correctly identify duplicate records.
When running checks, we look to the existing problem check trackers and try to grab their ProblemCheck classes.
In some cases this is no longer in the problem check repository, e.g. when the check was part of a plugin that has been uninstalled.
In the case where the check was scheduled, this would lead to an error in one of the jobs
his is a new feature that lets admins dismiss notices from the dashboard. This helps with self-service in cases where a notice is "stuck", while we work on provisions to prevent "sticking" in the first place.
This PR introduces a basic AdminNotice model to store these notices. Admin notices are categorized by their source/type (currently only notices from problem check.) They also have a priority.
As part of problem checks refactoring, we're moving some data to be DB backed. In this PR it's the tracking of problem check execution. When was it last run, when was the last problem, when should it run next, how many consecutive checks had problems, etc.
This allows us to implement the perform_every feature in scheduled problem checks for checks that don't need to be run every 10 minutes.
Ted Johansson
Martin Brennan