Commit Graph

6 Commits

Author SHA1 Message Date
Ted Johansson
93625ef07c
FIX: Make problem check tracker unique constraint work on PG13 (#29272)
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.
2024-10-21 10:45:09 +08:00
Ted Johansson
e60876ce49
FIX: Appropriately handle uninstalled problem checks (#28771)
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
2024-09-18 10:11:52 +08:00
Ted Johansson
be33363f13
FEATURE: Add ability to dismiss admin notices (#28916)
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.
2024-09-17 14:43:34 +08:00
Ted Johansson
3137e60653
DEV: Database backed admin notices (#26192)
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.
2024-05-23 09:29:08 +08:00
Ted Johansson
5875b25e68
DEV: Add the ability for problem checks to specify 'max blips' (#26388)
This was originally introduced in #26071, but that PR was closed, because the requirements changed. This PR lifts only the relevant parts, since they are a prerequisite for the new admin notice system.
2024-03-27 10:07:56 +08:00
Ted Johansson
1bcb521fbf
DEV: Add DB backed problem checks to support perform_every config (#25834)
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.
2024-02-27 11:17:39 +08:00