all objects, remote and local, now have serial numbers.
This is partly to make it easier for trilby_api to provide
decimal "id" numbers, and partly so that status URLs can contain
monotonically increasing decimal numbers. This last part
has not yet been implemented; status URLs still contain the
hex ID of the status.
It's possible that we can simplify this design a bit;
we should think about refactoring.
The regexp for local hex numbers is renamed to LOCAL_NUMBER_REGEXP
because it used to contain the word "SERIAL", which was misleading.
trilby_api now returns the "serial" field as "id"; see above.
Tests updated.
====================
Notification uses constants within the class
to represent notification types, as the docs recommend, rather than
using enum.Enum.
Notification.about_account is added. The existing "account" field
is renamed for_account for clarity.
Notification also gains a __str__() method.
on_follow modified to work properly with these changes.
Several migrations added. Note that trilby's 0006 migration is
deleted but there's a new 0006; you might have to wind back to
0005 to allow this migration to work. There are dependency
reasons for doing it like this.
In trilby_api.serializers
=========================
NotificationSerializer modified to return about_account.
It also gets immediately monkey-patched to return
notification_type as "type". Rather messy hack,
but StackExchange says this is the way to do it.
In trilby_api.views
===================
Notifications requires authentication(!) and returns
only the authenticated user's notifications.
In tests
========
test_notifications's test_follow fixed. It didn't work
before, despite the claim in commit 37095e; that was wrong
because the results weren't actually being checked.
Marnanel Thurman