followed has "auto_follow" turned on, the request is automatically
granted. If the follower is remote, they automatically get sent an
Accept activity. This fixes a regression.
As part of this, bowler_pub.create() now sends the ID of the Follow
activity through the signal.
Also, trilby_api.receivers now uses sensible renames for the
"sender" parameters-- they're really the activities which caused
the signal.
(and failing, obviously). This should have been mocked but wasn't.
This need some deeper investigation so I've @skip()ped them for now.
(One of the tests was previously @expected_failure.)
There's still a remaining issue: we always decode the bytestring as UTF-8, but it might not be. Marked with XXX.
Hence also: log.info() the incoming message before attempting to decode the bytestring.
Also: don't bother logging when we've launched the validation task, since that always succeeds.
Previously we allowed callers to specify them as arguments, if the argument name was preceded by "f_".
This caused ambiguities and was too much faff to be useful.
Tests updated accordingly.
Also, one test message copied from the ActivityPub spec was slightly in breach of actual usage conventions. Fixed.
This is because when we validate the message, a little further
down the line, we need access to the exact content of the message.
Parsing it here would destroy the exact content, because Django
doesn't let you read request bodies twice.
Previously they were all marked @skip. They are no longer skipped, but they don't pass.
Clearly there's work to be done there. More work will probably also be needed in modernising the tests.
CollectionView.get() correctly passes username and listname through to activity_get().
This fixes a regression.
CollectionView.get() dereferences the result of activity_get() if it's an ActivityResponse.
This should have been part of commit d02042f2 but I missed it.
This fixes a regression.
CollectionView.get() uses len() to get the length of the result of activity_get(), and
not the result's count() method. This allows the result to be a list as well as a queryset.
CollectionView.activity_get()'s logging is slightly tidier.
The refactoring is more complicated than it sounds. The file activitypub.py
was created by merging two sets of views from the old bowler_heavy
branch. This resulted in two classes called InboxView, and of course
the second one in the file won out. I have merged them and fixed
the errors therein.
As part of this, I have discovered that d-r-f adds the requirement
that view methods return HttpResponse objects. Therefore we've had
to add a new class, ActivityResponse, whose only purpose is to
get around this requirement.
fetch() has been updated as appropriate.
This is a bit complicated. We used to have two functions called
create_local_person(): one of them was in bowler_pub and the other
was in trilby_api. The bowler_pub one worked better because it
defaulted to using test keys rather than expecting the system
to make new ones, which is slow and wasteful.
Therefore, we have moved the c_l_p() from bowler into trilby,
and thrown the trilby one out.
While we're at it, we have also moved create_local_status and
create_local_like from bowler into trilby, and deleted trilby's
create_local_note.
This makes everything faster and easier.
On a LocalPerson, our own models are the authoritative source for their followers.
On a RemotePerson, we have to grab the list from the remote server.
I've made some tests for the LocalPerson part, but the RemotePerson part
still needs testing. This has involved creating a test_person module
in trilby, because test_account is for integration tests.
Tests for local delivery added. These tests don't yet check the results. When they do, they will fail because of
issue #37.
No tests for remote delivery yet. They're coming soon.
This is for consistency with "inbox" for RemotePerson, which is merely the URL.
At some point it will need to be "get_inbox_collection", but that will
make it visible via ActivityPub and we need to make sure permissions are checked.
Marnanel Thurman