This implements archive import feature.
The feature is divided in two main subfeatures: archive validation and archive import.
Archive validation performs different validation on input user archive. This can be
used without actually running import, e.g. when user wants to check the archive
before import from the frontend. Validators may add messages and modify the archive.
Validators are separated in two types: critical validators and non-critical validators.
If validations by critical validators fail it means we can't import archive.
If non-critical validations fail, we can import archive, but some warning messages
are rendered.
Also validators may change archive contents, e.g. when some entity can't be
imported it may be removed from the archive.
Validators' job is to take away complexity from the importer and perform the validations
which are not implemented in other parts of the system, e.g. DB validations or
diaspora_federation entity validations.
Archive importer then takes the modified archive from the validator and imports it.
In order to incapsulate high-level migration logic a MigrationService is
introduced. MigrationService links ArchiveValidator, ArchiveImporter and
AccountMigration.
Also here is introduced a rake task which may be used by podmins to run archive
import.
This commit introduces support for AccountMigration federation message
receive. It covers the cases when the new home pod for a user is remote
respective to the recepient pod of the message. It also allows to initiate
migration locally by a podmin from the rails console. This will give the
pods a possibility to understand the account migration event on the
federation level and thus future version which will implement migration
will be backward compatible with the pods starting from this commit.
This commit introduces changes to the user data export archive format.
This extends data set which is included in the archive. This data can be
then imported to other pods when this feature is implemented.
Also the commit adds the archive format json schema. ATM it is used in
automatic tests only, but in future it will also be used to validate
incoming archives.
Breaking a public key of a person can be used to "block" receiving posts
from this person on the pod. So we should handle that case better and
not just trigger many retries for something that will fail again.
closes#7448
These are some initial tests, more to come.
It tests some features of Request, StatusMessage, Comment, Like,
Participation, Retraction, SignedRetraction, RelayableRetraction entities
receive process.
This adds a new boolean field "public_details" to person model.
By default it is false and represents old behaviour. When it is
set to true, extended profile (bio,location,gender,birthday)
get available to people who didn't log into diaspora and to
people you don't share with (i.e. it is made public).
In UI, a bootstrap-switch added on the profile-edit page in order to
change the setting.
This also changes wording from public/private profile to basic/extended.
The latter could be public and limited.
