Before the Tailwind 4 migration, checkboxes behaved as follows:
Light mode
checked → cyan bg + white checkmark
unchecked → white bg
Dark mode
checked → cyan bg + white checkmark
unchecked → dark bg
In the last commit, we fixed white-on-white, but because we removed
dark:bg-... as well, unchecked boxes in dark mode regressed to white,
standing out like a sore thumb against the dark background.
The current commit adds back the pre-migration behavior; it's not
actually a value-judgement on it other than "it was at least functioning".
(this non-value-judgement is directed at "do I really like cyan bg + white
checkmark in dark mode... I might not)
Fix#225
After upgrading to Tailwind 4, the styled checkbox showed no checkmark when
checked. DevTools inspection showed a white-on-white rendering: the checkmark
SVG was filled white while the background was also white. Removing the
bg-white class restores the intended text-* color, making the checkmark
visible again.
The class bg-white was added in 4c8fb20daa i.e. in our first attempt
to get a non-ugly checkbox styling; whether it was "ever needed for realz"
is of historic interest mostly.
Fix#225
Tailwind 3 -> 4 migration renamed `ring` -> `ring-3`, but colors like
`ring-cyan-200` were also changed to `ring-3-cyan-200` which doesn't
actually exist.
broken in ac8e2e8cd6
See #225 (the present commit is related, but not a full fix)
This more exactly expresses semantics by itself, and is also in preparation of
creating releases through the API (which have no triggering event)
See #146
"In principle" setting `SCRIPT_NAME` is enough. The way we do this is [1] using
`FORCE_SCRIPT_NAME` (which does not depend on messing with reverse proxy
settings and [2] by deducing the correct value from `BASE_URL` (which must be
set anyway) automatically.
By works I mean: `reverse` and `{% url` pick it up from there.
However, there are subtleties / extra work:
* `STATIC_URL` is needed too b/c https://code.djangoproject.com/ticket/34028
* in many pre-existing code I just created a path manually in the html. Such
hrefs are obviously not magically fixed for script_name. Rather than doing
the "full rewrite" (into `{% url`) this commit just prepends the
`script_name` in those cases. That's the way forward that will least likely
break and it gives us something to grep for if we ever want to 'do it
right'.
* `LOGIN_REDIRECT_URL` and `LOGIN_URL` needed to use a view-name for this to
work (using a view-name gets revolved using the thing that introduces
`script_name`)
Checked, no work needed:
* views (`redirect` and `HttpResponseRedirect`)
* html uses of action="..."
Fix#93
in the correct timezone, with smaller milis
According to the spec, this should work because:
> The timestamp of the breadcrumb. Recommended. A timestamp representing when
> the breadcrumb occurred. The format is either a string as defined in [RFC
> 3339](https://tools.ietf.org/html/rfc3339) or a numeric (integer or float)
> value representing the number of seconds that have elapsed since the [Unix
> epoch](https://en.wikipedia.org/wiki/Unix_time). Breadcrumbs are most useful
> when they include a timestamp, as it creates a timeline leading up to an
> event.
* The "collapse" etc. buttons get shown below the search box and < << >> > from
a certain width downwards.
* similar stacking for the date/type/value and the buttons at an even smaller width.
See #120
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")
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
