* add more context to user export page
* fix BookData fields wrong for files
* use to_activity and to_model where possible
* fixes for import and export
- use AP JSON where possible
- minor template wording updates
* import fixes and updates tests
* minor cleanup
* remove todo for mastodon
This way, we need not list every value again to create the enum.
N.B.: enum values are now accessed as `models.NotificationType.FOO`,
instead of `models.Notification.FOO`.
* update User model to allow for moved_to and also_known_as values
* allow users to add aliases (also_known_as) in UI
* allow users to move account to another one (moved_to)
* redirect webfinger to the new account after a move
* present notification to followers inviting to follow at new account
Note: unlike Mastodon we're not running any unfollow/autofollow action here: users can decide for themselves
This makes undoing moves easier.
TODO
There is still a bug with incoming Moves, at least from Mastodon.
This seems to be something to do with Update activities (rather than Move, strictly).
Right now notifications are a mix of post-save signals and clauses in
the save function of the model. I'm not actually sure which is better,
but I'm moving them to signals where it's straightforward to be
consistent.
In the new paradigm, a notification related to a status has users added
to it and removed from it, rather than a new notification being added
every time. These helper functions make this behavior consistent.
these were named as BookwyrmGroup and BookwyrmGroupMember due to a misunderstanding about related_name and a dodgy development environment. This naming makes more sense.
- notify group members when a new member accepts an invitation
- notify all group members when a member leaves or is removed
- notify ex-member when they are removed