- /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.
This was introduced in commit 047aec. AcActor's activity_form() expects to get
a field named "publicKey" from its parent method, and to rearrange that.
But renaming f_publicKey to publicKey meant that the parent method
assumed it wasn't public, and didn't put it into its result.
Test included.
Closes issue #35.
"f_publicKey" would mean it can be set automatically. Because it's
typically a JSON object, it can't be represented with a simple type,
so it can't be set automatically; it must be represented in ThingField.
This didn't make a practical difference before, but since commit 6ce087
create() has honoured the "f_*" convention.
then sets the others by subscripting.
"As many fields as it can" means
- the id field
- any field whose name begins with "f_".
Previously, create() filled in as few fields as it could
(typically only the id, if supplied), then set the others by subscripting.
This change increases efficiency, but also allows the save() method
of AcObject and its subclasses to take account of the intial values of
the f_* fields.
is now only applied to incoming activities, as the spec requires.
For local activities, the actor is *always* told about their own activities.
Tests updated.
Marnanel Thurman