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.
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.
`Rails.application.assets` is only available when `config.assets.compile`
is true (which is false in production). So the old way with a separate
rake task doesn't work in production. But we can get the filename of the
precompiled file from `Rails.application.assets_manifest.assets`.
* 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
* snippet now in a separate JS file - compiled and uglified with the other assets
* popup gets centered in opening browser window
* publisher gets pre-filled with markdown-styled content
This allows us to reuse any CSS we have, unify
their look and unify their look with the regular
page design.
This works by instantiating ActionView and rendering
templates in a rake task.
Inspired by the errgent gem.
Add Sidetiq webview to the Sidekiq monitoring panel
Add rake task maintenance:queue_users_for_removal
This basically just triggers an immediate run of the normal maintenance remove old users functionality that is normally (if enabled) scheduled to run once a day via sidetiq
Add extra safety when checking for user removal due to inactivity.
Now also user.last_seen will also be checked to make sure a user will not be removed in the event that the Devise rememember me login functionality has stopped the users remove_after timestamp from being removed.
Add initializer for maintenance job.
Add warning about mail being disabled if remove_old_users maintenance is enabled.
* Wrap it into a transaction
* Use destroy over delete so dependent destroys get triggered
and we thus don't fail on the foreign key constraits
* Check if a photos status message actually exists before accessing
it
* Add missing dependent destroys
* Dropped all references to Resque
* Moved all jobs under app/workers since that's the Sidekiq convention
* Renamed Jobs module to Worker to match new location
* Adapted all jobs to Sidekiq
* Replaced all enqueue calls with perform_async
* Dropped Resque hacks from specs and features, replaced with
sidekig/testing in RSpec and sidekig/testing/inline in Cucumber
* Updated scripts to start a Sidekiq server
* Inline Sidekiq sinatra app
* Let Sidekiq create the actual Redis instance
* Workaround already initialized constant warnings in service models
* Resolved ToDo in one job definition by creating proper exception clases
for some errors in receiving posts
* Added sidekiq section to configuration to make it completly
configurable to the user
* Add Sidekiq middleware for clean backtraces
* Delay HttpMulti retry to give offline pods a chance to come back up
* Do not retry on GUID already taken and alike errors
* Be graceful about deleted posts in GatherOEmbedData
