This is not (and as far as I know, was never) used. If we want to make
standalone photos commentable, we can always add it back, but it would
also need to change federation for it to work, because comments support
only posts there. But for now it makes the code cleaner and easier to
remove it.
Previously we had only a Rails validation which ensured poll participation
uniqueness but this adds uniqueness control to the database level, so that
uniqueness is guaranteed even when changing data with avoiding Rails
validations.
closes#7798
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
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.
we released that in 0.5.0.0 in 2015, we do not support skipping majors
anyway, and this is broken in Rails 5, so let's remove this. If people
upgrade from before 0.5.0.0, they have to upgrade via 0.6.0.0, but
that's written in the documenation.
Although this is contrary to rails best-practises, we cannot provide a schema.rb that works for both MySQL and PostgreSQL, so we have no choice. Our migrations are maintained, so it should always be possible to get back to a "clean" database schema anyway.
... this breaks the Rails 5 upgrade, and it's actually no longer needed.
New installations will have the right size anyway, and even if some
older installations miss the migration by not updating for 2 years, it
still doesn't matter since there is no risk that we will ever have
emojis in our migration filenames.