I got feedback from many users, that they don't understand how the "my
activity" stream is sorted, because they have posts on the top, but
don't see why. The user doesn't see if a like was added, and it is also
not imported for the user to see the post again then. And we have
notifications if someone likes a users own posts, so no need to move it on
top of the "my activity" stream here too.
closes#7030
* accounts:run_deletions: was added with 0.4.0.0 two years ago for one-time usage.
* db:rebuild: db:reset does basically the same
* db:integration:preprare: the integration environments are not used.
* db:reset: there is a default db:reset, no need to write our own.
* db:drop_integration: the integration environments are not used.
* db:fix_diaspora_handle: really old migration from 2010
* db:move_private_key: also old migration from 2010
* maintenance:clear_carrierwave_temp_uploads: tmp/uploads doesn't exist anymore. And we have CleanCachedFiles as cronjob.
* maintenance:install_logrotate_config: diaspora has built-in logrotate support now, and people who want to use logrotate instead can write their own configs with the values they want.
* migrations:copy_hidden_share_visibilities_to_users: old migration from 2012
* migrations:invitations: legacy invitations were removed with #6976
* migrations:absolutify_image_references: old migration from 2010
* migrations:rewire_uppercase_hashtags: old migration from 2012
* migrations:remove_uppercase_hashtags: old migration from 2012
The desktop frontend now treats the "name" parameter of mention as
a string to display unconditionally. But the Diaspora::Mentionable
renders mentions the different way: "name" is treated as a fallback
string which is rendered only if the person's name is unavailable.
This reflects on the mobile version ATM. This patch makes it behave
the same way as the current desktop version does.
ignoring the error message
Previously it returned the return value of Logging::Logger#warn, which
is true for loggers that log the warn level. However
Diaspora::Federation::Receive::receive_relayable checks the return value
for truthiness in order to decide whether to attempt to relay it,
resulting in a NoMethodError: undefined method `parent' for
true:TrueClass in Diaspora::Federation::Receive::relay_relayable
This change is cosmetic as the exception raised prevented any action
that shouldn't happen anyway, so there's no actual logic change.
