See https://github.com/Sija/raven.cr/issues/100 for the thing that triggered this
Caused by spotting this in the (shared on discord) logs of one of our users:
```
RuntimeWarning: DateTimeField Event.timestamp received a naive datetime (2025-10-26 16:01:08) while time zone support is active.
```
See #252
This is not backwards compatible (it will now hard-break), but given snappea's
rather particular design decisions this is probably for the best, and given
what else was just discovered on #252 I strongly doubt anyone was actually using
it in such setups anyway.
See #252 where the following error was triggered:
> django.db.transaction.TransactionManagementError: select_for_update cannot be
> used outside of a transaction.
I believe that this is caused by using a non-sqlite database for the snappea DB.
"You probably shouldn't" but at least our own behavior should be consistent.
I haven't been able to reproduce this particular error BTW, but at least I've
reproduced _some_ error conditions that this commit fixes.
Bugsink 2.0 upgraded to Django 5.2 (from 4.2) under the hood. However, Django
5.0 made it so that on MariaDB >= 10.7, UUIDFields are stored as native UUID
fields, and special conversion steps are required.
The Django 5.0 release notes suggest basically downgrading your existing UUIDs
to CharField values and sticking with that forever, but that's not a workable
solution for us for many reasons:
* Bugsink is multi-DB-backend, and this change would affect them all. I don't
want to force postgres-users to downgrade just for this.
* Bugsink 2.0 is already out in the wild, and people who've deployed it on
MariaDB >= 10.7 would already "be in the correct future" (have UUID columns).
i.e. the "solution" would just create the inverse problem.
* What with new models with new UUID fields? We'd run the rist of a "mix" with
all the future complexity that comes with _that_.
So I've decided to just bite the bullet and force an upgrade. The provided
command allows users to upgrade their data. Just run:
```
bugsink-manage convert_mariadb_uuids
```
I have not (yet) provided this as a migration (it's always an option for the
future)... mostly for lack of time but also because we "need this as a command
anyway"... because people that would be on MariaDB < 10.7 still need this
tool whenever they migrate to >= 10.7.
Fix#226
See #236 (for context, not for something that's solved by this):
> I did just notice that whatever the form validation error on-login is, the
> above message is shown. I will fix that at least to make debugging the above
> easier in the future. (i.e.: to make it so that if the form data is missing
> entirely, you'd get a "this field is required" for both fields)
This also gets rid of the lock/person but I don't care enough for those
to keep them around.
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)
Move DRF/OpenAPI authentication import out of bugsink/__init__.py into
bugsink/authentication.py.
Before: running bugsink-manage imported the bugsink package, whose __init__
pulled in drf_spectacular → DRF → DRF’s api_settings before Django settings
were configured, raising ImproperlyConfigured. (Did not happen in dev where
apps are loaded after settings.)
After: DRF is first touched during server load via urls → routers → views →
schemas. Only then does DRF’s api_settings resolve DEFAULT_AUTHENTICATION_CLASSES,
importing bugsink.authentication at a point where settings are already ready.
Chose to fix output, not loosen the test: trailing spaces are invisible
noise, vary by editors/OS, and break deterministic rendering in Markdown.
Stripping them makes output more useful in general and avoids flaky diffs.
Adds a `stacktrace_md` field to EventSerializer and a `/stacktrace` action
returning the same markdown (but as the full response).
Also switches `data` to use `get_parsed_data()` (as it should have) and
in json dict format (rather than str).
