Some people may remove their birthday date after the notification was
sent, which then breaks the notification page for other users. Let's
just display the date when the notification was created, and not display
the users updated birthday date. When users update from date A to B it
always looks weird anyway, when we display the same new date B twice on
different days, or display two different dates for the same user.
We could remove notifications when users change or remove their
birthday, but that would be way more complex and also we usually don't
remove notifications (not even for deleted posts).
Fixes#7689closes#7691
The notifications need to be grouped by the same date as they are
sorted, otherwise the date used for the group doesn't match all
timestamps in the group and also the groups are sorted by the wrong
date.
This fixes#7647, a regression of #7568.
closes#7648
When we should have the signature but don't have it, the user data
export fails. There are a few comments from back in 2011 where the
signature is missing.
Also some podmins maybe messed with signatures in their database, which
would also break the exports now.
closes#7637
There are a few old oEmbed caches which have the title saved in binary
(because they contain Chinese characters). This fails with
`ActionView::Template::Error ("å" from ASCII-8BIT to UTF-8)`. Since I
found only very old OEmbed caches with this problem (newest from 2012),
I think we can just remove these. When I create a new oEmbed cache for
the same URL it creates it without `!binary`.
closes#7620
- Removed posts and non contacts from other's data
- Collections are exported in batches to lower memory footprint
- In base exporters create User object instead of keeping instance because it caches all associations
closes#7627
It was possible to run migration locally without providing old private
key. This way migration was performed but not dispatched, which obviously
leads to desynchronization of the federation state so let's validate sender
before performing any actual actions.
closes#7558
