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.
being an object, not a string. This was a regression.
Tests updated. Thanks to vpzom for catching this.
Also, the same representation's "endpoints" object is now generated
on the fly. This means that changes to the TESTSERVER variable
during testing are correctly represented.
There is one difference, which I think isn't important in the circumstances.
If lookup() is asked about a remote person that we don't already know about,
it either creates a blank record for them and returns it, or raises an error.
In these circumstances, fetch() will perform a lookup and populate the record
accordingly.
local_form() and remote_form() class methods. This is to
allow fetch() to check whether something is already cached
before fetching it.
LocalPerson also gains a status() method for symmetry with
RemotePerson; it always returns 200.
Tests updated.
This regressed in commit a2a790f1. Before then, handlers could be defined for particular object types.
When we moved to general-case handlers for each Activity type, we should have added object type checks
to replace the checks implicit in the type-specific handlers.
Marnanel Thurman