闭社主体 forked from https://github.com/tootsuite/mastodon
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

667 lines
19 KiB

Optional notification muting (#5087) * Add a hide_notifications column to mutes * Add muting_notifications? and a notifications argument to mute! * block notifications in notify_service from hard muted accounts * Add specs for how mute! interacts with muting_notifications? * specs testing that hide_notifications in mutes actually hides notifications * Add support for muting notifications in MuteService * API support for muting notifications (and specs) * Less gross passing of notifications flag * Break out a separate mute modal with a hide-notifications checkbox. * Convert profile header mute to use mute modal * Satisfy eslint. * specs for MuteService notifications params * add trailing newlines to files for Pork :) * Put the label for the hide notifications checkbox in a label element. * Add a /api/v1/mutes/details route that just returns the array of mutes. * Define a serializer for /api/v1/mutes/details * Add more specs for the /api/v1/mutes/details endpoint * Expose whether a mute hides notifications in the api/v1/relationships endpoint * Show whether muted users' notifications are muted in account lists * Allow modifying the hide_notifications of a mute with the /api/v1/accounts/:id/mute endpoint * make the hide/unhide notifications buttons work * satisfy eslint * In probably dead code, replace a dispatch of muteAccount that was skipping the modal with launching the mute modal. * fix a missing import * add an explanatory comment to AccountInteractions * Refactor handling of default params for muting to make code cleaner * minor code style fixes oops * Fixed a typo that was breaking the account mute API endpoint * Apply white-space: nowrap to account relationships icons * Fix code style issues * Remove superfluous blank line * Rename /api/v1/mutes/details -> /api/v2/mutes * Don't serialize "account" in MuteSerializer Doing so is somewhat unnecessary since it's always the current user's account. * Fix wrong variable name in api/v2/mutes * Use Toggle in place of checkbox in the mute modal. * Make the Toggle in the mute modal look better * Code style changes in specs and removed an extra space * Code review suggestions from akihikodaki Also fixed a syntax error in tests for AccountInteractions. * Make AddHideNotificationsToMute Concurrent It's not clear how much this will benefit instances in practice, as the number of mutes tends to be pretty small, but this should prevent any blocking migrations nonetheless. * Fix up migration things * Remove /api/v2/mutes
5 years ago
Add follower synchronization mechanism (#14510) * Add support for followers synchronization on the receiving end Check the `collectionSynchronization` attribute on `Create` and `Announce` activities and synchronize followers from provided collection if possible. * Add tests for followers synchronization on the receiving end * Add support for follower synchronization on the sender's end * Add tests for the sending end * Switch from AS attributes to HTTP header Replace the custom `collectionSynchronization` ActivityStreams attribute by an HTTP header (`X-AS-Collection-Synchronization`) with the same syntax as the `Signature` header and the following fields: - `collectionId` to specify which collection to synchronize - `digest` for the SHA256 hex-digest of the list of followers known on the receiving instance (where “receiving instance” is determined by accounts sharing the same host name for their ActivityPub actor `id`) - `url` of a collection that should be fetched by the instance actor Internally, move away from the webfinger-based `domain` attribute and use account `uri` prefix to group accounts. * Add environment variable to disable followers synchronization Since the whole mechanism relies on some new preconditions that, in some extremely rare cases, might not be met, add an environment variable (DISABLE_FOLLOWERS_SYNCHRONIZATION) to disable the mechanism altogether and avoid followers being incorrectly removed. The current conditions are: 1. all managed accounts' actor `id` and inbox URL have the same URI scheme and netloc. 2. all accounts whose actor `id` or inbox URL share the same URI scheme and netloc as a managed account must be managed by the same Mastodon instance as well. As far as Mastodon is concerned, breaking those preconditions require extensive configuration changes in the reverse proxy and might also cause other issues. Therefore, this environment variable provides a way out for people with highly unusual configurations, and can be safely ignored for the overwhelming majority of Mastodon administrators. * Only set follower synchronization header on non-public statuses This is to avoid unnecessary computations and allow Follow-related activities to be handled by the usual codepath instead of going through the synchronization mechanism (otherwise, any Follow/Undo/Accept activity would trigger the synchronization mechanism even if processing the activity itself would be enough to re-introduce synchronization) * Change how ActivityPub::SynchronizeFollowersService handles follow requests If the remote lists a local follower which we only know has sent a follow request, consider the follow request as accepted instead of sending an Undo. * Integrate review feeback - rename X-AS-Collection-Synchronization to Collection-Synchronization - various minor refactoring and code style changes * Only select required fields when computing followers_hash * Use actor URI rather than webfinger domain in synchronization endpoint * Change hash computation to be a XOR of individual hashes Makes it much easier to be memory-efficient, and avoid sorting discrepancy issues. * Marginally improve followers_hash computation speed * Further improve hash computation performances by using pluck_each
2 years ago
Add follower synchronization mechanism (#14510) * Add support for followers synchronization on the receiving end Check the `collectionSynchronization` attribute on `Create` and `Announce` activities and synchronize followers from provided collection if possible. * Add tests for followers synchronization on the receiving end * Add support for follower synchronization on the sender's end * Add tests for the sending end * Switch from AS attributes to HTTP header Replace the custom `collectionSynchronization` ActivityStreams attribute by an HTTP header (`X-AS-Collection-Synchronization`) with the same syntax as the `Signature` header and the following fields: - `collectionId` to specify which collection to synchronize - `digest` for the SHA256 hex-digest of the list of followers known on the receiving instance (where “receiving instance” is determined by accounts sharing the same host name for their ActivityPub actor `id`) - `url` of a collection that should be fetched by the instance actor Internally, move away from the webfinger-based `domain` attribute and use account `uri` prefix to group accounts. * Add environment variable to disable followers synchronization Since the whole mechanism relies on some new preconditions that, in some extremely rare cases, might not be met, add an environment variable (DISABLE_FOLLOWERS_SYNCHRONIZATION) to disable the mechanism altogether and avoid followers being incorrectly removed. The current conditions are: 1. all managed accounts' actor `id` and inbox URL have the same URI scheme and netloc. 2. all accounts whose actor `id` or inbox URL share the same URI scheme and netloc as a managed account must be managed by the same Mastodon instance as well. As far as Mastodon is concerned, breaking those preconditions require extensive configuration changes in the reverse proxy and might also cause other issues. Therefore, this environment variable provides a way out for people with highly unusual configurations, and can be safely ignored for the overwhelming majority of Mastodon administrators. * Only set follower synchronization header on non-public statuses This is to avoid unnecessary computations and allow Follow-related activities to be handled by the usual codepath instead of going through the synchronization mechanism (otherwise, any Follow/Undo/Accept activity would trigger the synchronization mechanism even if processing the activity itself would be enough to re-introduce synchronization) * Change how ActivityPub::SynchronizeFollowersService handles follow requests If the remote lists a local follower which we only know has sent a follow request, consider the follow request as accepted instead of sending an Undo. * Integrate review feeback - rename X-AS-Collection-Synchronization to Collection-Synchronization - various minor refactoring and code style changes * Only select required fields when computing followers_hash * Use actor URI rather than webfinger domain in synchronization endpoint * Change hash computation to be a XOR of individual hashes Makes it much easier to be memory-efficient, and avoid sorting discrepancy issues. * Marginally improve followers_hash computation speed * Further improve hash computation performances by using pluck_each
2 years ago
Add follower synchronization mechanism (#14510) * Add support for followers synchronization on the receiving end Check the `collectionSynchronization` attribute on `Create` and `Announce` activities and synchronize followers from provided collection if possible. * Add tests for followers synchronization on the receiving end * Add support for follower synchronization on the sender's end * Add tests for the sending end * Switch from AS attributes to HTTP header Replace the custom `collectionSynchronization` ActivityStreams attribute by an HTTP header (`X-AS-Collection-Synchronization`) with the same syntax as the `Signature` header and the following fields: - `collectionId` to specify which collection to synchronize - `digest` for the SHA256 hex-digest of the list of followers known on the receiving instance (where “receiving instance” is determined by accounts sharing the same host name for their ActivityPub actor `id`) - `url` of a collection that should be fetched by the instance actor Internally, move away from the webfinger-based `domain` attribute and use account `uri` prefix to group accounts. * Add environment variable to disable followers synchronization Since the whole mechanism relies on some new preconditions that, in some extremely rare cases, might not be met, add an environment variable (DISABLE_FOLLOWERS_SYNCHRONIZATION) to disable the mechanism altogether and avoid followers being incorrectly removed. The current conditions are: 1. all managed accounts' actor `id` and inbox URL have the same URI scheme and netloc. 2. all accounts whose actor `id` or inbox URL share the same URI scheme and netloc as a managed account must be managed by the same Mastodon instance as well. As far as Mastodon is concerned, breaking those preconditions require extensive configuration changes in the reverse proxy and might also cause other issues. Therefore, this environment variable provides a way out for people with highly unusual configurations, and can be safely ignored for the overwhelming majority of Mastodon administrators. * Only set follower synchronization header on non-public statuses This is to avoid unnecessary computations and allow Follow-related activities to be handled by the usual codepath instead of going through the synchronization mechanism (otherwise, any Follow/Undo/Accept activity would trigger the synchronization mechanism even if processing the activity itself would be enough to re-introduce synchronization) * Change how ActivityPub::SynchronizeFollowersService handles follow requests If the remote lists a local follower which we only know has sent a follow request, consider the follow request as accepted instead of sending an Undo. * Integrate review feeback - rename X-AS-Collection-Synchronization to Collection-Synchronization - various minor refactoring and code style changes * Only select required fields when computing followers_hash * Use actor URI rather than webfinger domain in synchronization endpoint * Change hash computation to be a XOR of individual hashes Makes it much easier to be memory-efficient, and avoid sorting discrepancy issues. * Marginally improve followers_hash computation speed * Further improve hash computation performances by using pluck_each
2 years ago
Add follower synchronization mechanism (#14510) * Add support for followers synchronization on the receiving end Check the `collectionSynchronization` attribute on `Create` and `Announce` activities and synchronize followers from provided collection if possible. * Add tests for followers synchronization on the receiving end * Add support for follower synchronization on the sender's end * Add tests for the sending end * Switch from AS attributes to HTTP header Replace the custom `collectionSynchronization` ActivityStreams attribute by an HTTP header (`X-AS-Collection-Synchronization`) with the same syntax as the `Signature` header and the following fields: - `collectionId` to specify which collection to synchronize - `digest` for the SHA256 hex-digest of the list of followers known on the receiving instance (where “receiving instance” is determined by accounts sharing the same host name for their ActivityPub actor `id`) - `url` of a collection that should be fetched by the instance actor Internally, move away from the webfinger-based `domain` attribute and use account `uri` prefix to group accounts. * Add environment variable to disable followers synchronization Since the whole mechanism relies on some new preconditions that, in some extremely rare cases, might not be met, add an environment variable (DISABLE_FOLLOWERS_SYNCHRONIZATION) to disable the mechanism altogether and avoid followers being incorrectly removed. The current conditions are: 1. all managed accounts' actor `id` and inbox URL have the same URI scheme and netloc. 2. all accounts whose actor `id` or inbox URL share the same URI scheme and netloc as a managed account must be managed by the same Mastodon instance as well. As far as Mastodon is concerned, breaking those preconditions require extensive configuration changes in the reverse proxy and might also cause other issues. Therefore, this environment variable provides a way out for people with highly unusual configurations, and can be safely ignored for the overwhelming majority of Mastodon administrators. * Only set follower synchronization header on non-public statuses This is to avoid unnecessary computations and allow Follow-related activities to be handled by the usual codepath instead of going through the synchronization mechanism (otherwise, any Follow/Undo/Accept activity would trigger the synchronization mechanism even if processing the activity itself would be enough to re-introduce synchronization) * Change how ActivityPub::SynchronizeFollowersService handles follow requests If the remote lists a local follower which we only know has sent a follow request, consider the follow request as accepted instead of sending an Undo. * Integrate review feeback - rename X-AS-Collection-Synchronization to Collection-Synchronization - various minor refactoring and code style changes * Only select required fields when computing followers_hash * Use actor URI rather than webfinger domain in synchronization endpoint * Change hash computation to be a XOR of individual hashes Makes it much easier to be memory-efficient, and avoid sorting discrepancy issues. * Marginally improve followers_hash computation speed * Further improve hash computation performances by using pluck_each
2 years ago
Add follower synchronization mechanism (#14510) * Add support for followers synchronization on the receiving end Check the `collectionSynchronization` attribute on `Create` and `Announce` activities and synchronize followers from provided collection if possible. * Add tests for followers synchronization on the receiving end * Add support for follower synchronization on the sender's end * Add tests for the sending end * Switch from AS attributes to HTTP header Replace the custom `collectionSynchronization` ActivityStreams attribute by an HTTP header (`X-AS-Collection-Synchronization`) with the same syntax as the `Signature` header and the following fields: - `collectionId` to specify which collection to synchronize - `digest` for the SHA256 hex-digest of the list of followers known on the receiving instance (where “receiving instance” is determined by accounts sharing the same host name for their ActivityPub actor `id`) - `url` of a collection that should be fetched by the instance actor Internally, move away from the webfinger-based `domain` attribute and use account `uri` prefix to group accounts. * Add environment variable to disable followers synchronization Since the whole mechanism relies on some new preconditions that, in some extremely rare cases, might not be met, add an environment variable (DISABLE_FOLLOWERS_SYNCHRONIZATION) to disable the mechanism altogether and avoid followers being incorrectly removed. The current conditions are: 1. all managed accounts' actor `id` and inbox URL have the same URI scheme and netloc. 2. all accounts whose actor `id` or inbox URL share the same URI scheme and netloc as a managed account must be managed by the same Mastodon instance as well. As far as Mastodon is concerned, breaking those preconditions require extensive configuration changes in the reverse proxy and might also cause other issues. Therefore, this environment variable provides a way out for people with highly unusual configurations, and can be safely ignored for the overwhelming majority of Mastodon administrators. * Only set follower synchronization header on non-public statuses This is to avoid unnecessary computations and allow Follow-related activities to be handled by the usual codepath instead of going through the synchronization mechanism (otherwise, any Follow/Undo/Accept activity would trigger the synchronization mechanism even if processing the activity itself would be enough to re-introduce synchronization) * Change how ActivityPub::SynchronizeFollowersService handles follow requests If the remote lists a local follower which we only know has sent a follow request, consider the follow request as accepted instead of sending an Undo. * Integrate review feeback - rename X-AS-Collection-Synchronization to Collection-Synchronization - various minor refactoring and code style changes * Only select required fields when computing followers_hash * Use actor URI rather than webfinger domain in synchronization endpoint * Change hash computation to be a XOR of individual hashes Makes it much easier to be memory-efficient, and avoid sorting discrepancy issues. * Marginally improve followers_hash computation speed * Further improve hash computation performances by using pluck_each
2 years ago
Add follower synchronization mechanism (#14510) * Add support for followers synchronization on the receiving end Check the `collectionSynchronization` attribute on `Create` and `Announce` activities and synchronize followers from provided collection if possible. * Add tests for followers synchronization on the receiving end * Add support for follower synchronization on the sender's end * Add tests for the sending end * Switch from AS attributes to HTTP header Replace the custom `collectionSynchronization` ActivityStreams attribute by an HTTP header (`X-AS-Collection-Synchronization`) with the same syntax as the `Signature` header and the following fields: - `collectionId` to specify which collection to synchronize - `digest` for the SHA256 hex-digest of the list of followers known on the receiving instance (where “receiving instance” is determined by accounts sharing the same host name for their ActivityPub actor `id`) - `url` of a collection that should be fetched by the instance actor Internally, move away from the webfinger-based `domain` attribute and use account `uri` prefix to group accounts. * Add environment variable to disable followers synchronization Since the whole mechanism relies on some new preconditions that, in some extremely rare cases, might not be met, add an environment variable (DISABLE_FOLLOWERS_SYNCHRONIZATION) to disable the mechanism altogether and avoid followers being incorrectly removed. The current conditions are: 1. all managed accounts' actor `id` and inbox URL have the same URI scheme and netloc. 2. all accounts whose actor `id` or inbox URL share the same URI scheme and netloc as a managed account must be managed by the same Mastodon instance as well. As far as Mastodon is concerned, breaking those preconditions require extensive configuration changes in the reverse proxy and might also cause other issues. Therefore, this environment variable provides a way out for people with highly unusual configurations, and can be safely ignored for the overwhelming majority of Mastodon administrators. * Only set follower synchronization header on non-public statuses This is to avoid unnecessary computations and allow Follow-related activities to be handled by the usual codepath instead of going through the synchronization mechanism (otherwise, any Follow/Undo/Accept activity would trigger the synchronization mechanism even if processing the activity itself would be enough to re-introduce synchronization) * Change how ActivityPub::SynchronizeFollowersService handles follow requests If the remote lists a local follower which we only know has sent a follow request, consider the follow request as accepted instead of sending an Undo. * Integrate review feeback - rename X-AS-Collection-Synchronization to Collection-Synchronization - various minor refactoring and code style changes * Only select required fields when computing followers_hash * Use actor URI rather than webfinger domain in synchronization endpoint * Change hash computation to be a XOR of individual hashes Makes it much easier to be memory-efficient, and avoid sorting discrepancy issues. * Marginally improve followers_hash computation speed * Further improve hash computation performances by using pluck_each
2 years ago
Add follower synchronization mechanism (#14510) * Add support for followers synchronization on the receiving end Check the `collectionSynchronization` attribute on `Create` and `Announce` activities and synchronize followers from provided collection if possible. * Add tests for followers synchronization on the receiving end * Add support for follower synchronization on the sender's end * Add tests for the sending end * Switch from AS attributes to HTTP header Replace the custom `collectionSynchronization` ActivityStreams attribute by an HTTP header (`X-AS-Collection-Synchronization`) with the same syntax as the `Signature` header and the following fields: - `collectionId` to specify which collection to synchronize - `digest` for the SHA256 hex-digest of the list of followers known on the receiving instance (where “receiving instance” is determined by accounts sharing the same host name for their ActivityPub actor `id`) - `url` of a collection that should be fetched by the instance actor Internally, move away from the webfinger-based `domain` attribute and use account `uri` prefix to group accounts. * Add environment variable to disable followers synchronization Since the whole mechanism relies on some new preconditions that, in some extremely rare cases, might not be met, add an environment variable (DISABLE_FOLLOWERS_SYNCHRONIZATION) to disable the mechanism altogether and avoid followers being incorrectly removed. The current conditions are: 1. all managed accounts' actor `id` and inbox URL have the same URI scheme and netloc. 2. all accounts whose actor `id` or inbox URL share the same URI scheme and netloc as a managed account must be managed by the same Mastodon instance as well. As far as Mastodon is concerned, breaking those preconditions require extensive configuration changes in the reverse proxy and might also cause other issues. Therefore, this environment variable provides a way out for people with highly unusual configurations, and can be safely ignored for the overwhelming majority of Mastodon administrators. * Only set follower synchronization header on non-public statuses This is to avoid unnecessary computations and allow Follow-related activities to be handled by the usual codepath instead of going through the synchronization mechanism (otherwise, any Follow/Undo/Accept activity would trigger the synchronization mechanism even if processing the activity itself would be enough to re-introduce synchronization) * Change how ActivityPub::SynchronizeFollowersService handles follow requests If the remote lists a local follower which we only know has sent a follow request, consider the follow request as accepted instead of sending an Undo. * Integrate review feeback - rename X-AS-Collection-Synchronization to Collection-Synchronization - various minor refactoring and code style changes * Only select required fields when computing followers_hash * Use actor URI rather than webfinger domain in synchronization endpoint * Change hash computation to be a XOR of individual hashes Makes it much easier to be memory-efficient, and avoid sorting discrepancy issues. * Marginally improve followers_hash computation speed * Further improve hash computation performances by using pluck_each
2 years ago
Add follower synchronization mechanism (#14510) * Add support for followers synchronization on the receiving end Check the `collectionSynchronization` attribute on `Create` and `Announce` activities and synchronize followers from provided collection if possible. * Add tests for followers synchronization on the receiving end * Add support for follower synchronization on the sender's end * Add tests for the sending end * Switch from AS attributes to HTTP header Replace the custom `collectionSynchronization` ActivityStreams attribute by an HTTP header (`X-AS-Collection-Synchronization`) with the same syntax as the `Signature` header and the following fields: - `collectionId` to specify which collection to synchronize - `digest` for the SHA256 hex-digest of the list of followers known on the receiving instance (where “receiving instance” is determined by accounts sharing the same host name for their ActivityPub actor `id`) - `url` of a collection that should be fetched by the instance actor Internally, move away from the webfinger-based `domain` attribute and use account `uri` prefix to group accounts. * Add environment variable to disable followers synchronization Since the whole mechanism relies on some new preconditions that, in some extremely rare cases, might not be met, add an environment variable (DISABLE_FOLLOWERS_SYNCHRONIZATION) to disable the mechanism altogether and avoid followers being incorrectly removed. The current conditions are: 1. all managed accounts' actor `id` and inbox URL have the same URI scheme and netloc. 2. all accounts whose actor `id` or inbox URL share the same URI scheme and netloc as a managed account must be managed by the same Mastodon instance as well. As far as Mastodon is concerned, breaking those preconditions require extensive configuration changes in the reverse proxy and might also cause other issues. Therefore, this environment variable provides a way out for people with highly unusual configurations, and can be safely ignored for the overwhelming majority of Mastodon administrators. * Only set follower synchronization header on non-public statuses This is to avoid unnecessary computations and allow Follow-related activities to be handled by the usual codepath instead of going through the synchronization mechanism (otherwise, any Follow/Undo/Accept activity would trigger the synchronization mechanism even if processing the activity itself would be enough to re-introduce synchronization) * Change how ActivityPub::SynchronizeFollowersService handles follow requests If the remote lists a local follower which we only know has sent a follow request, consider the follow request as accepted instead of sending an Undo. * Integrate review feeback - rename X-AS-Collection-Synchronization to Collection-Synchronization - various minor refactoring and code style changes * Only select required fields when computing followers_hash * Use actor URI rather than webfinger domain in synchronization endpoint * Change hash computation to be a XOR of individual hashes Makes it much easier to be memory-efficient, and avoid sorting discrepancy issues. * Marginally improve followers_hash computation speed * Further improve hash computation performances by using pluck_each
2 years ago
Optional notification muting (#5087) * Add a hide_notifications column to mutes * Add muting_notifications? and a notifications argument to mute! * block notifications in notify_service from hard muted accounts * Add specs for how mute! interacts with muting_notifications? * specs testing that hide_notifications in mutes actually hides notifications * Add support for muting notifications in MuteService * API support for muting notifications (and specs) * Less gross passing of notifications flag * Break out a separate mute modal with a hide-notifications checkbox. * Convert profile header mute to use mute modal * Satisfy eslint. * specs for MuteService notifications params * add trailing newlines to files for Pork :) * Put the label for the hide notifications checkbox in a label element. * Add a /api/v1/mutes/details route that just returns the array of mutes. * Define a serializer for /api/v1/mutes/details * Add more specs for the /api/v1/mutes/details endpoint * Expose whether a mute hides notifications in the api/v1/relationships endpoint * Show whether muted users' notifications are muted in account lists * Allow modifying the hide_notifications of a mute with the /api/v1/accounts/:id/mute endpoint * make the hide/unhide notifications buttons work * satisfy eslint * In probably dead code, replace a dispatch of muteAccount that was skipping the modal with launching the mute modal. * fix a missing import * add an explanatory comment to AccountInteractions * Refactor handling of default params for muting to make code cleaner * minor code style fixes oops * Fixed a typo that was breaking the account mute API endpoint * Apply white-space: nowrap to account relationships icons * Fix code style issues * Remove superfluous blank line * Rename /api/v1/mutes/details -> /api/v2/mutes * Don't serialize "account" in MuteSerializer Doing so is somewhat unnecessary since it's always the current user's account. * Fix wrong variable name in api/v2/mutes * Use Toggle in place of checkbox in the mute modal. * Make the Toggle in the mute modal look better * Code style changes in specs and removed an extra space * Code review suggestions from akihikodaki Also fixed a syntax error in tests for AccountInteractions. * Make AddHideNotificationsToMute Concurrent It's not clear how much this will benefit instances in practice, as the number of mutes tends to be pretty small, but this should prevent any blocking migrations nonetheless. * Fix up migration things * Remove /api/v2/mutes
5 years ago
Allow hiding of reblogs from followed users (#5762) * Allow hiding of reblogs from followed users This adds a new entry to the account menu to allow users to hide future reblogs from a user (and then if they've done that, to show future reblogs instead). This does not remove or add historical reblogs from/to the user's timeline; it only affects new statuses. The API for this operates by sending a "reblogs" key to the follow endpoint. If this is sent when starting a new follow, it will be respected from the beginning of the follow relationship (even if the follow request must be approved by the followee). If this is sent when a follow relationship already exists, it will simply update the existing follow relationship. As with the notification muting, this will now return an object ({reblogs: [true|false]}) or false for each follow relationship when requesting relationship information for an account. This should cause few issues due to an object being truthy in many languages, but some modifications may need to be made in pickier languages. Database changes: adds a show_reblogs column (default true, non-nullable) to the follows and follow_requests tables. Because these are non-nullable, we use the existing MigrationHelpers to perform this change without locking those tables, although the tables are likely to be small anyway. Tests included. See also <https://github.com/glitch-soc/mastodon/pull/212>. * Rubocop fixes * Code review changes * Test fixes This patchset closes #648 and resolves #3271. * Rubocop fix * Revert reblogs defaulting in argument, fix tests It turns out we needed this for the same reason we needed it in muting: if nil gets passed in somehow (most usually by an API client not passing any value), we need to detect and handle it. We could specify a default in the parameter and then also catch nil, but there's no great reason to duplicate the default value.
5 years ago
Optional notification muting (#5087) * Add a hide_notifications column to mutes * Add muting_notifications? and a notifications argument to mute! * block notifications in notify_service from hard muted accounts * Add specs for how mute! interacts with muting_notifications? * specs testing that hide_notifications in mutes actually hides notifications * Add support for muting notifications in MuteService * API support for muting notifications (and specs) * Less gross passing of notifications flag * Break out a separate mute modal with a hide-notifications checkbox. * Convert profile header mute to use mute modal * Satisfy eslint. * specs for MuteService notifications params * add trailing newlines to files for Pork :) * Put the label for the hide notifications checkbox in a label element. * Add a /api/v1/mutes/details route that just returns the array of mutes. * Define a serializer for /api/v1/mutes/details * Add more specs for the /api/v1/mutes/details endpoint * Expose whether a mute hides notifications in the api/v1/relationships endpoint * Show whether muted users' notifications are muted in account lists * Allow modifying the hide_notifications of a mute with the /api/v1/accounts/:id/mute endpoint * make the hide/unhide notifications buttons work * satisfy eslint * In probably dead code, replace a dispatch of muteAccount that was skipping the modal with launching the mute modal. * fix a missing import * add an explanatory comment to AccountInteractions * Refactor handling of default params for muting to make code cleaner * minor code style fixes oops * Fixed a typo that was breaking the account mute API endpoint * Apply white-space: nowrap to account relationships icons * Fix code style issues * Remove superfluous blank line * Rename /api/v1/mutes/details -> /api/v2/mutes * Don't serialize "account" in MuteSerializer Doing so is somewhat unnecessary since it's always the current user's account. * Fix wrong variable name in api/v2/mutes * Use Toggle in place of checkbox in the mute modal. * Make the Toggle in the mute modal look better * Code style changes in specs and removed an extra space * Code review suggestions from akihikodaki Also fixed a syntax error in tests for AccountInteractions. * Make AddHideNotificationsToMute Concurrent It's not clear how much this will benefit instances in practice, as the number of mutes tends to be pretty small, but this should prevent any blocking migrations nonetheless. * Fix up migration things * Remove /api/v2/mutes
5 years ago
  1. require 'rails_helper'
  2. describe AccountInteractions do
  3. let(:account) { Fabricate(:account, username: 'account') }
  4. let(:account_id) { account.id }
  5. let(:account_ids) { [account_id] }
  6. let(:target_account) { Fabricate(:account, username: 'target') }
  7. let(:target_account_id) { target_account.id }
  8. let(:target_account_ids) { [target_account_id] }
  9. describe '.following_map' do
  10. subject { Account.following_map(target_account_ids, account_id) }
  11. context 'account with Follow' do
  12. it 'returns { target_account_id => true }' do
  13. Fabricate(:follow, account: account, target_account: target_account)
  14. is_expected.to eq(target_account_id => { reblogs: true, notify: false })
  15. end
  16. end
  17. context 'account without Follow' do
  18. it 'returns {}' do
  19. is_expected.to eq({})
  20. end
  21. end
  22. end
  23. describe '.followed_by_map' do
  24. subject { Account.followed_by_map(target_account_ids, account_id) }
  25. context 'account with Follow' do
  26. it 'returns { target_account_id => true }' do
  27. Fabricate(:follow, account: target_account, target_account: account)
  28. is_expected.to eq(target_account_id => true)
  29. end
  30. end
  31. context 'account without Follow' do
  32. it 'returns {}' do
  33. is_expected.to eq({})
  34. end
  35. end
  36. end
  37. describe '.blocking_map' do
  38. subject { Account.blocking_map(target_account_ids, account_id) }
  39. context 'account with Block' do
  40. it 'returns { target_account_id => true }' do
  41. Fabricate(:block, account: account, target_account: target_account)
  42. is_expected.to eq(target_account_id => true)
  43. end
  44. end
  45. context 'account without Block' do
  46. it 'returns {}' do
  47. is_expected.to eq({})
  48. end
  49. end
  50. end
  51. describe '.muting_map' do
  52. subject { Account.muting_map(target_account_ids, account_id) }
  53. context 'account with Mute' do
  54. before do
  55. Fabricate(:mute, target_account: target_account, account: account, hide_notifications: hide)
  56. end
  57. context 'if Mute#hide_notifications?' do
  58. let(:hide) { true }
  59. it 'returns { target_account_id => { notifications: true } }' do
  60. is_expected.to eq(target_account_id => { notifications: true })
  61. end
  62. end
  63. context 'unless Mute#hide_notifications?' do
  64. let(:hide) { false }
  65. it 'returns { target_account_id => { notifications: false } }' do
  66. is_expected.to eq(target_account_id => { notifications: false })
  67. end
  68. end
  69. end
  70. context 'account without Mute' do
  71. it 'returns {}' do
  72. is_expected.to eq({})
  73. end
  74. end
  75. end
  76. describe '#follow!' do
  77. it 'creates and returns Follow' do
  78. expect do
  79. expect(account.follow!(target_account)).to be_kind_of Follow
  80. end.to change { account.following.count }.by 1
  81. end
  82. end
  83. describe '#block' do
  84. it 'creates and returns Block' do
  85. expect do
  86. expect(account.block!(target_account)).to be_kind_of Block
  87. end.to change { account.block_relationships.count }.by 1
  88. end
  89. end
  90. describe '#mute!' do
  91. subject { account.mute!(target_account, notifications: arg_notifications) }
  92. context 'Mute does not exist yet' do
  93. context 'arg :notifications is nil' do
  94. let(:arg_notifications) { nil }
  95. it 'creates Mute, and returns Mute' do
  96. expect do
  97. expect(subject).to be_kind_of Mute
  98. end.to change { account.mute_relationships.count }.by 1
  99. end
  100. end
  101. context 'arg :notifications is false' do
  102. let(:arg_notifications) { false }
  103. it 'creates Mute, and returns Mute' do
  104. expect do
  105. expect(subject).to be_kind_of Mute
  106. end.to change { account.mute_relationships.count }.by 1
  107. end
  108. end
  109. context 'arg :notifications is true' do
  110. let(:arg_notifications) { true }
  111. it 'creates Mute, and returns Mute' do
  112. expect do
  113. expect(subject).to be_kind_of Mute
  114. end.to change { account.mute_relationships.count }.by 1
  115. end
  116. end
  117. end
  118. context 'Mute already exists' do
  119. before do
  120. account.mute_relationships << mute
  121. end
  122. let(:mute) do
  123. Fabricate(:mute,
  124. account: account,
  125. target_account: target_account,
  126. hide_notifications: hide_notifications)
  127. end
  128. context 'mute.hide_notifications is true' do
  129. let(:hide_notifications) { true }
  130. context 'arg :notifications is nil' do
  131. let(:arg_notifications) { nil }
  132. it 'returns Mute without updating mute.hide_notifications' do
  133. expect do
  134. expect(subject).to be_kind_of Mute
  135. end.not_to change { mute.reload.hide_notifications? }.from(true)
  136. end
  137. end
  138. context 'arg :notifications is false' do
  139. let(:arg_notifications) { false }
  140. it 'returns Mute, and updates mute.hide_notifications false' do
  141. expect do
  142. expect(subject).to be_kind_of Mute
  143. end.to change { mute.reload.hide_notifications? }.from(true).to(false)
  144. end
  145. end
  146. context 'arg :notifications is true' do
  147. let(:arg_notifications) { true }
  148. it 'returns Mute without updating mute.hide_notifications' do
  149. expect do
  150. expect(subject).to be_kind_of Mute
  151. end.not_to change { mute.reload.hide_notifications? }.from(true)
  152. end
  153. end
  154. end
  155. context 'mute.hide_notifications is false' do
  156. let(:hide_notifications) { false }
  157. context 'arg :notifications is nil' do
  158. let(:arg_notifications) { nil }
  159. it 'returns Mute, and updates mute.hide_notifications true' do
  160. expect do
  161. expect(subject).to be_kind_of Mute
  162. end.to change { mute.reload.hide_notifications? }.from(false).to(true)
  163. end
  164. end
  165. context 'arg :notifications is false' do
  166. let(:arg_notifications) { false }
  167. it 'returns Mute without updating mute.hide_notifications' do
  168. expect do
  169. expect(subject).to be_kind_of Mute
  170. end.not_to change { mute.reload.hide_notifications? }.from(false)
  171. end
  172. end
  173. context 'arg :notifications is true' do
  174. let(:arg_notifications) { true }
  175. it 'returns Mute, and updates mute.hide_notifications true' do
  176. expect do
  177. expect(subject).to be_kind_of Mute
  178. end.to change { mute.reload.hide_notifications? }.from(false).to(true)
  179. end
  180. end
  181. end
  182. end
  183. end
  184. describe '#mute_conversation!' do
  185. let(:conversation) { Fabricate(:conversation) }
  186. subject { account.mute_conversation!(conversation) }
  187. it 'creates and returns ConversationMute' do
  188. expect do
  189. is_expected.to be_kind_of ConversationMute
  190. end.to change { account.conversation_mutes.count }.by 1
  191. end
  192. end
  193. describe '#block_domain!' do
  194. let(:domain) { 'example.com' }
  195. subject { account.block_domain!(domain) }
  196. it 'creates and returns AccountDomainBlock' do
  197. expect do
  198. is_expected.to be_kind_of AccountDomainBlock
  199. end.to change { account.domain_blocks.count }.by 1
  200. end
  201. end
  202. describe '#unfollow!' do
  203. subject { account.unfollow!(target_account) }
  204. context 'following target_account' do
  205. it 'returns destroyed Follow' do
  206. account.active_relationships.create(target_account: target_account)
  207. is_expected.to be_kind_of Follow
  208. expect(subject).to be_destroyed
  209. end
  210. end
  211. context 'not following target_account' do
  212. it 'returns nil' do
  213. is_expected.to be_nil
  214. end
  215. end
  216. end
  217. describe '#unblock!' do
  218. subject { account.unblock!(target_account) }
  219. context 'blocking target_account' do
  220. it 'returns destroyed Block' do
  221. account.block_relationships.create(target_account: target_account)
  222. is_expected.to be_kind_of Block
  223. expect(subject).to be_destroyed
  224. end
  225. end
  226. context 'not blocking target_account' do
  227. it 'returns nil' do
  228. is_expected.to be_nil
  229. end
  230. end
  231. end
  232. describe '#unmute!' do
  233. subject { account.unmute!(target_account) }
  234. context 'muting target_account' do
  235. it 'returns destroyed Mute' do
  236. account.mute_relationships.create(target_account: target_account)
  237. is_expected.to be_kind_of Mute
  238. expect(subject).to be_destroyed
  239. end
  240. end
  241. context 'not muting target_account' do
  242. it 'returns nil' do
  243. is_expected.to be_nil
  244. end
  245. end
  246. end
  247. describe '#unmute_conversation!' do
  248. let(:conversation) { Fabricate(:conversation) }
  249. subject { account.unmute_conversation!(conversation) }
  250. context 'muting the conversation' do
  251. it 'returns destroyed ConversationMute' do
  252. account.conversation_mutes.create(conversation: conversation)
  253. is_expected.to be_kind_of ConversationMute
  254. expect(subject).to be_destroyed
  255. end
  256. end
  257. context 'not muting the conversation' do
  258. it 'returns nil' do
  259. is_expected.to be nil
  260. end
  261. end
  262. end
  263. describe '#unblock_domain!' do
  264. let(:domain) { 'example.com' }
  265. subject { account.unblock_domain!(domain) }
  266. context 'blocking the domain' do
  267. it 'returns destroyed AccountDomainBlock' do
  268. account_domain_block = Fabricate(:account_domain_block, domain: domain)
  269. account.domain_blocks << account_domain_block
  270. is_expected.to be_kind_of AccountDomainBlock
  271. expect(subject).to be_destroyed
  272. end
  273. end
  274. context 'unblocking the domain' do
  275. it 'returns nil' do
  276. is_expected.to be_nil
  277. end
  278. end
  279. end
  280. describe '#following?' do
  281. subject { account.following?(target_account) }
  282. context 'following target_account' do
  283. it 'returns true' do
  284. account.active_relationships.create(target_account: target_account)
  285. is_expected.to be true
  286. end
  287. end
  288. context 'not following target_account' do
  289. it 'returns false' do
  290. is_expected.to be false
  291. end
  292. end
  293. end
  294. describe '#blocking?' do
  295. subject { account.blocking?(target_account) }
  296. context 'blocking target_account' do
  297. it 'returns true' do
  298. account.block_relationships.create(target_account: target_account)
  299. is_expected.to be true
  300. end
  301. end
  302. context 'not blocking target_account' do
  303. it 'returns false' do
  304. is_expected.to be false
  305. end
  306. end
  307. end
  308. describe '#domain_blocking?' do
  309. let(:domain) { 'example.com' }
  310. subject { account.domain_blocking?(domain) }
  311. context 'blocking the domain' do
  312. it' returns true' do
  313. account_domain_block = Fabricate(:account_domain_block, domain: domain)
  314. account.domain_blocks << account_domain_block
  315. is_expected.to be true
  316. end
  317. end
  318. context 'not blocking the domain' do
  319. it 'returns false' do
  320. is_expected.to be false
  321. end
  322. end
  323. end
  324. describe '#muting?' do
  325. subject { account.muting?(target_account) }
  326. context 'muting target_account' do
  327. it 'returns true' do
  328. mute = Fabricate(:mute, account: account, target_account: target_account)
  329. account.mute_relationships << mute
  330. is_expected.to be true
  331. end
  332. end
  333. context 'not muting target_account' do
  334. it 'returns false' do
  335. is_expected.to be false
  336. end
  337. end
  338. end
  339. describe '#muting_conversation?' do
  340. let(:conversation) { Fabricate(:conversation) }
  341. subject { account.muting_conversation?(conversation) }
  342. context 'muting the conversation' do
  343. it 'returns true' do
  344. account.conversation_mutes.create(conversation: conversation)
  345. is_expected.to be true
  346. end
  347. end
  348. context 'not muting the conversation' do
  349. it 'returns false' do
  350. is_expected.to be false
  351. end
  352. end
  353. end
  354. describe '#muting_notifications?' do
  355. before do
  356. mute = Fabricate(:mute, target_account: target_account, account: account, hide_notifications: hide)
  357. account.mute_relationships << mute
  358. end
  359. subject { account.muting_notifications?(target_account) }
  360. context 'muting notifications of target_account' do
  361. let(:hide) { true }
  362. it 'returns true' do
  363. is_expected.to be true
  364. end
  365. end
  366. context 'not muting notifications of target_account' do
  367. let(:hide) { false }
  368. it 'returns false' do
  369. is_expected.to be false
  370. end
  371. end
  372. end
  373. describe '#requested?' do
  374. subject { account.requested?(target_account) }
  375. context 'requested by target_account' do
  376. it 'returns true' do
  377. Fabricate(:follow_request, account: account, target_account: target_account)
  378. is_expected.to be true
  379. end
  380. end
  381. context 'not requested by target_account' do
  382. it 'returns false' do
  383. is_expected.to be false
  384. end
  385. end
  386. end
  387. describe '#favourited?' do
  388. let(:status) { Fabricate(:status, account: account, favourites: favourites) }
  389. subject { account.favourited?(status) }
  390. context 'favorited' do
  391. let(:favourites) { [Fabricate(:favourite, account: account)] }
  392. it 'returns true' do
  393. is_expected.to be true
  394. end
  395. end
  396. context 'not favorited' do
  397. let(:favourites) { [] }
  398. it 'returns false' do
  399. is_expected.to be false
  400. end
  401. end
  402. end
  403. describe '#reblogged?' do
  404. let(:status) { Fabricate(:status, account: account, reblogs: reblogs) }
  405. subject { account.reblogged?(status) }
  406. context 'reblogged' do
  407. let(:reblogs) { [Fabricate(:status, account: account)] }
  408. it 'returns true' do
  409. is_expected.to be true
  410. end
  411. end
  412. context 'not reblogged' do
  413. let(:reblogs) { [] }
  414. it 'returns false' do
  415. is_expected.to be false
  416. end
  417. end
  418. end
  419. describe '#pinned?' do
  420. let(:status) { Fabricate(:status, account: account) }
  421. subject { account.pinned?(status) }
  422. context 'pinned' do
  423. it 'returns true' do
  424. Fabricate(:status_pin, account: account, status: status)
  425. is_expected.to be true
  426. end
  427. end
  428. context 'not pinned' do
  429. it 'returns false' do
  430. is_expected.to be false
  431. end
  432. end
  433. end
  434. describe '#remote_followers_hash' do
  435. let(:me) { Fabricate(:account, username: 'Me') }
  436. let(:remote_1) { Fabricate(:account, username: 'alice', domain: 'example.org', uri: 'https://example.org/users/alice') }
  437. let(:remote_2) { Fabricate(:account, username: 'bob', domain: 'example.org', uri: 'https://example.org/users/bob') }
  438. let(:remote_3) { Fabricate(:account, username: 'instance-actor', domain: 'example.org', uri: 'https://example.org') }
  439. let(:remote_4) { Fabricate(:account, username: 'eve', domain: 'foo.org', uri: 'https://foo.org/users/eve') }
  440. before do
  441. remote_1.follow!(me)
  442. remote_2.follow!(me)
  443. remote_3.follow!(me)
  444. remote_4.follow!(me)
  445. me.follow!(remote_1)
  446. end
  447. it 'returns correct hash for remote domains' do
  448. expect(me.remote_followers_hash('https://example.org/')).to eq '20aecbe774b3d61c25094370baf370012b9271c5b172ecedb05caff8d79ef0c7'
  449. expect(me.remote_followers_hash('https://foo.org/')).to eq 'ccb9c18a67134cfff9d62c7f7e7eb88e6b803446c244b84265565f4eba29df0e'
  450. expect(me.remote_followers_hash('https://foo.org.evil.com/')).to eq '0000000000000000000000000000000000000000000000000000000000000000'
  451. expect(me.remote_followers_hash('https://foo')).to eq '0000000000000000000000000000000000000000000000000000000000000000'
  452. end
  453. it 'invalidates cache as needed when removing or adding followers' do
  454. expect(me.remote_followers_hash('https://example.org/')).to eq '20aecbe774b3d61c25094370baf370012b9271c5b172ecedb05caff8d79ef0c7'
  455. remote_3.unfollow!(me)
  456. expect(me.remote_followers_hash('https://example.org/')).to eq '707962e297b7bd94468a21bc8e506a1bcea607a9142cd64e27c9b106b2a5f6ec'
  457. remote_1.unfollow!(me)
  458. expect(me.remote_followers_hash('https://example.org/')).to eq '241b00794ce9b46aa864f3220afadef128318da2659782985bac5ed5bd436bff'
  459. remote_1.follow!(me)
  460. expect(me.remote_followers_hash('https://example.org/')).to eq '707962e297b7bd94468a21bc8e506a1bcea607a9142cd64e27c9b106b2a5f6ec'
  461. end
  462. end
  463. describe '#local_followers_hash' do
  464. let(:me) { Fabricate(:account, username: 'Me') }
  465. let(:remote_1) { Fabricate(:account, username: 'alice', domain: 'example.org', uri: 'https://example.org/users/alice') }
  466. before do
  467. me.follow!(remote_1)
  468. end
  469. it 'returns correct hash for local users' do
  470. expect(remote_1.local_followers_hash).to eq Digest::SHA256.hexdigest(ActivityPub::TagManager.instance.uri_for(me))
  471. end
  472. it 'invalidates cache as needed when removing or adding followers' do
  473. expect(remote_1.local_followers_hash).to eq Digest::SHA256.hexdigest(ActivityPub::TagManager.instance.uri_for(me))
  474. me.unfollow!(remote_1)
  475. expect(remote_1.local_followers_hash).to eq '0000000000000000000000000000000000000000000000000000000000000000'
  476. me.follow!(remote_1)
  477. expect(remote_1.local_followers_hash).to eq Digest::SHA256.hexdigest(ActivityPub::TagManager.instance.uri_for(me))
  478. end
  479. end
  480. describe 'muting an account' do
  481. let(:me) { Fabricate(:account, username: 'Me') }
  482. let(:you) { Fabricate(:account, username: 'You') }
  483. context 'with the notifications option unspecified' do
  484. before do
  485. me.mute!(you)
  486. end
  487. it 'defaults to muting notifications' do
  488. expect(me.muting_notifications?(you)).to be true
  489. end
  490. end
  491. context 'with the notifications option set to false' do
  492. before do
  493. me.mute!(you, notifications: false)
  494. end
  495. it 'does not mute notifications' do
  496. expect(me.muting_notifications?(you)).to be false
  497. end
  498. end
  499. context 'with the notifications option set to true' do
  500. before do
  501. me.mute!(you, notifications: true)
  502. end
  503. it 'does mute notifications' do
  504. expect(me.muting_notifications?(you)).to be true
  505. end
  506. end
  507. end
  508. describe 'ignoring reblogs from an account' do
  509. before do
  510. @me = Fabricate(:account, username: 'Me')
  511. @you = Fabricate(:account, username: 'You')
  512. end
  513. context 'with the reblogs option unspecified' do
  514. before do
  515. @me.follow!(@you)
  516. end
  517. it 'defaults to showing reblogs' do
  518. expect(@me.muting_reblogs?(@you)).to be(false)
  519. end
  520. end
  521. context 'with the reblogs option set to false' do
  522. before do
  523. @me.follow!(@you, reblogs: false)
  524. end
  525. it 'does mute reblogs' do
  526. expect(@me.muting_reblogs?(@you)).to be(true)
  527. end
  528. end
  529. context 'with the reblogs option set to true' do
  530. before do
  531. @me.follow!(@you, reblogs: true)
  532. end
  533. it 'does not mute reblogs' do
  534. expect(@me.muting_reblogs?(@you)).to be(false)
  535. end
  536. end
  537. end
  538. end