Health checks are often done directly against an IP address rather than using a
full hostname. This is annoying to set up if the IP address can be one from a
large range.
The things that ALLOWED_HOSTS defend against don't really apply for health
endpoints, so better not have the check.
Fix#140
* in 1abc30a760 the hardcoding of ="dark" (during development)
was accidentally checked in; it never should have been.
* in e14b3eaaa6 I mixed up the bare*base templates. It's actually
bare_base.html that's for 404/500 etc; barest_base is more bare
visually (it's the box-based layout for login etc), but it doesn't
need to be so careful not to use variables.
See #40
In the light of the discussion on #134, this implements the "clean up later"
solution: a vacuum task that deletes IssueTags no longer referenced by any
EventTag on the same Issue.
In the same sweep TagValues are pruned.
Performance-wise, this is a relatively safe path forward; it can run off-hours
or not at all, depending on preferences.
Semantically it's the least clear: whether an Issue appears to be tagged may
now depend on whether vacuum has run, and `IssueTag.count` (representing total
observed) is left in a "weird place" in the sense that it may disappear from
the total more or less at random (i.e. depending on calling a command, and
depending on the current state of not-yet-evicted Events).
In the light of the discussion on #134, this implements the "clean up later"
solution: a vacuum task that deletes IssueTags no longer referenced by any
EventTag on the same Issue.
This doesn't prevent stale IssueTags from being created but ensures they are
eventually removed, enabling follow-up cleanup (e.g. of TagValues).
Performance-wise, this is a relatively safe path forward; it can run off-hours
or not at all, depending on preferences. Semantically it's the least clear:
whether an Issue appears to be tagged may now depend on whether vacuum has run.
No tests yet; no immediate TagValue cleanup.
My thinking:
* Avoid Dependabot spam for harmless version bumps. (sentry-SDK
has the most upgrades by an order of magnitude)
* In princple, there should be no breakage, b/c they do semver and
"minor version when you add functionality in a backward compatible manner"
* This is dev tooling; it shouldn’t be a source of friction.
* As it stands: I'm not thoroughly reviewing these anyway (b/c of the spammyness)
The alternative would have been to "just freeze" it; if we ever run into
problems because of the unpinning I certainly will.
my chatbot tells me it felt ugly because
> bg-yellow-900 [..] is a very saturated, reddish mustard — almost
> brown-orange. That’s why it feels so jarring in dark mode: it's too warm,
> too saturated, and clashes with a cool-dark UI. [..] Try bg-amber-800
> instead. Tailwind's amber palette is warmer and more muted than yellow,
> designed to fit better in dark UIs.
No idea if the reasoning is sound, but it "looks good" so I'm pushing ahead.
I've done a full grep on Issue.objects, Project.objects and get_object_or_404
equivelents, and applying some common sense. The goal: avoid having
confusing/half-broken pages in the UI.
On index-usage: I've decided not to update the indexes. The assumption is:
`is_deleted` items will be a tiny minority of items in general, making the
cost/benefit analysis not turn out favorably (just scanning them out as a final
step is more efficient). Also: sqlite is able to use the correct index without
adding a special one, proof:
```
EXPLAIN QUERY PLAN SELECT [..] WHERE ("issues_issue"."project_id" = 1 AND "issues_issue"."is_muted" = (0) AND "issues_issue"."is_resolved" = (0)) ORDER BY "issues_issue"."last_seen" DESC LIMIT 250;
QUERY PLAN
`--SEARCH issues_issue USING INDEX issue_list_open (project_id=? AND is_resolved=? AND is_muted=?)
EXPLAIN QUERY PLAN SELECT [..] WHERE ("issues_issue"."project_id" = 1 AND "issues_issue"."is_muted" = (0) AND "issues_issue"."is_resolved" = (0) AND "issues_issue"."is_deleted" = 0) ORDER BY "issues_issue"."last_seen" DESC LIMIT 250;
QUERY PLAN
`--SEARCH issues_issue USING INDEX issue_list_open (project_id=? AND is_resolved=? AND is_muted=?)
```
See #139 for the 0/1 notation in the above.
(Project-indexes: not an issue, the scale is "below relevance for indexes")
Implement delete functionality with confirmation modals for projects.
cherry picked (by Klaas) from commit 6764fbf343fb; but:
* projects only
* `delete_deferred`
* flake8
See #84 for the original PR
Removes the following 2 redundant queries from the deletion process:
```
SELECT "tags_tagkey"."id" FROM "tags_tagkey" WHERE "tags_tagkey"."project_id" IN (1) ORDER BY "tags_tagkey"."project_id" ASC, "tags_tagkey"."id" ASC LIMIT 498
UPDATE "projects_project" SET "stored_event_count" = ("projects_project"."stored_event_count" - 1) WHERE "projects_project"."id" = 1
```
Like e45c61d6f0, but for .project.
I originally thought `SET_NULL` would be a good way to "do stuff later", but
that's only so the degree that [1] updates are cheaper than deletes and [2]
2nd-order effects (further deletes in the dep-tree) are avoided.
Now that we have explicit Project-deletion (deps-first, delayed, properly batched)
the SET_NULL behavior is always a no-op (but with cost in queries).
As a result, in the test for project deletion (which has deletes for many
of the altered models), the following 12 queries are no longer done:
```
SELECT "projects_project"."id", [..many fields..] FROM "projects_project" WHERE "projects_project"."id" = 1
DELETE FROM "projects_projectmembership" WHERE "projects_projectmembership"."project_id" IN (1)
DELETE FROM "alerts_messagingserviceconfig" WHERE "alerts_messagingserviceconfig"."project_id" IN (1)
UPDATE "releases_release" SET "project_id" = NULL WHERE "releases_release"."project_id" IN (1)
UPDATE "issues_issue" SET "project_id" = NULL WHERE "issues_issue"."project_id" IN (1)
UPDATE "issues_grouping" SET "project_id" = NULL WHERE "issues_grouping"."project_id" IN (1)
UPDATE "events_event" SET "project_id" = NULL WHERE "events_event"."project_id" IN (1)
UPDATE "tags_tagkey" SET "project_id" = NULL WHERE "tags_tagkey"."project_id" IN (1)
UPDATE "tags_tagvalue" SET "project_id" = NULL WHERE "tags_tagvalue"."project_id" IN (1)
UPDATE "tags_eventtag" SET "project_id" = NULL WHERE "tags_eventtag"."project_id" IN (1)
UPDATE "tags_issuetag" SET "project_id" = NULL WHERE "tags_issuetag"."project_id" IN (1)
```
Implemented using a batch-wise dependency-scanner in delayed
(snappea) style.
* no real point-of-entry in the (regular, non-admin) UI yet.
* no hiding of Projects which are delete-in-progress from the UI
* lack of DRY
* some unnessary work (needed in the Issue-context, but not here)
is still being done.
See #50
I originally thought `SET_NULL` would be a good way to "do stuff later", but
that's only so the degree that [1] updates are cheaper than deletes and [2]
2nd-order effects (further deletes in the dep-tree) are avoided.
Now that we have explicit Issue-deletion (deps-first, delayed, properly batched)
the SET_NULL behavior is always a no-op (but with cost in queries).
As a result, in the test for issue deletion (which has deletes for many
of the altered models), the following 8 queries are no longer done:
```
SELECT "issues_grouping"."id", [..many fields..] FROM "issues_grouping" WHERE "issues_grouping"."id" IN (1)
UPDATE "events_event" SET "grouping_id" = NULL WHERE "events_event"."grouping_id" IN (1)
[.. a few moments later..]
SELECT "issues_issue"."id", [..many fields..] FROM "issues_issue" WHERE "issues_issue"."id" = 'uuid'
UPDATE "issues_grouping" SET "issue_id" = NULL WHERE "issues_grouping"."issue_id" IN ('uuid')
UPDATE "issues_turningpoint" SET "issue_id" = NULL WHERE "issues_turningpoint"."issue_id" IN ('uuid')
UPDATE "events_event" SET "issue_id" = NULL WHERE "events_event"."issue_id" IN ('uuid')
UPDATE "tags_eventtag" SET "issue_id" = NULL WHERE "tags_eventtag"."issue_id" IN ('uuid')
UPDATE "tags_issuetag" SET "issue_id" = NULL WHERE "tags_issuetag"."issue_id" IN ('uuid')
```
(breaks the tests b/c of constraints and not always using factories; will fix next)
