- /api/v1/instance is also at /api/v1/instance/
- the version reported is always 1.0.0. This is because we're
mimicking the Mastodon API, so we reply giving the corresponding
Mastodon version. (Or, as in this case, we guess and see what works.)
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.
rather than attempting to do it via a database filter.
Database filters will fail because public-ness is based on
several possible considerations.
trilby_api.tests.create_local_status gains a "to" parameter.
Tests added.
====================
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.
Because of this, the side_effect routines take **kwargs,
as does run_side_effects() in AcObject.
The side_effect routine for Update can update cached data for remote objects.
It doesn't attempt to modify the "id" or "type" fields on any object.
AcObject gains an items() method, by analogy with dicts etc.
It's just syntactic sugar around activity_form.
Marnanel Thurman