2023-02-22 11:55:31 +11:00
|
|
|
# frozen_string_literal: true
|
|
|
|
|
2017-05-07 07:06:52 +10:00
|
|
|
require 'rails_helper'
|
|
|
|
|
2018-05-03 02:58:48 +10:00
|
|
|
RSpec.describe NotifyService, type: :service do
|
2022-03-28 21:43:58 +11:00
|
|
|
subject { described_class.new.call(recipient, type, activity) }
|
2017-05-07 07:06:52 +10:00
|
|
|
|
|
|
|
let(:user) { Fabricate(:user) }
|
|
|
|
let(:recipient) { user.account }
|
Account domain blocks (#2381)
* Add <ostatus:conversation /> tag to Atom input/output
Only uses ref attribute (not href) because href would be
the alternate link that's always included also.
Creates new conversation for every non-reply status. Carries
over conversation for every reply. Keeps remote URIs verbatim,
generates local URIs on the fly like the rest of them.
* Conversation muting - prevents notifications that reference a conversation
(including replies, favourites, reblogs) from being created. API endpoints
/api/v1/statuses/:id/mute and /api/v1/statuses/:id/unmute
Currently no way to tell when a status/conversation is muted, so the web UI
only has a "disable notifications" button, doesn't work as a toggle
* Display "Dismiss notifications" on all statuses in notifications column, not just own
* Add "muted" as a boolean attribute on statuses JSON
For now always false on contained reblogs, since it's only relevant for
statuses returned from the notifications endpoint, which are not nested
Remove "Disable notifications" from detailed status view, since it's
only relevant in the notifications column
* Up max class length
* Remove pending test for conversation mute
* Add tests, clean up
* Rename to "mute conversation" and "unmute conversation"
* Raise validation error when trying to mute/unmute status without conversation
* Adding account domain blocks that filter notifications and public timelines
* Add tests for domain blocks in notifications, public timelines
Filter reblogs of blocked domains from home
* Add API for listing and creating account domain blocks
* API for creating/deleting domain blocks, tests for Status#ancestors
and Status#descendants, filter domain blocks from them
* Filter domains in streaming API
* Update account_domain_block_spec.rb
2017-05-19 09:14:30 +10:00
|
|
|
let(:sender) { Fabricate(:account, domain: 'example.com') }
|
Feature conversations muting (#3017)
* Add <ostatus:conversation /> tag to Atom input/output
Only uses ref attribute (not href) because href would be
the alternate link that's always included also.
Creates new conversation for every non-reply status. Carries
over conversation for every reply. Keeps remote URIs verbatim,
generates local URIs on the fly like the rest of them.
* Conversation muting - prevents notifications that reference a conversation
(including replies, favourites, reblogs) from being created. API endpoints
/api/v1/statuses/:id/mute and /api/v1/statuses/:id/unmute
Currently no way to tell when a status/conversation is muted, so the web UI
only has a "disable notifications" button, doesn't work as a toggle
* Display "Dismiss notifications" on all statuses in notifications column, not just own
* Add "muted" as a boolean attribute on statuses JSON
For now always false on contained reblogs, since it's only relevant for
statuses returned from the notifications endpoint, which are not nested
Remove "Disable notifications" from detailed status view, since it's
only relevant in the notifications column
* Up max class length
* Remove pending test for conversation mute
* Add tests, clean up
* Rename to "mute conversation" and "unmute conversation"
* Raise validation error when trying to mute/unmute status without conversation
2017-05-15 11:04:13 +10:00
|
|
|
let(:activity) { Fabricate(:follow, account: sender, target_account: recipient) }
|
2020-09-19 01:26:45 +10:00
|
|
|
let(:type) { :follow }
|
2017-05-07 07:06:52 +10:00
|
|
|
|
2022-03-28 21:43:58 +11:00
|
|
|
it { expect { subject }.to change(Notification, :count).by(1) }
|
2017-05-07 07:06:52 +10:00
|
|
|
|
Feature conversations muting (#3017)
* Add <ostatus:conversation /> tag to Atom input/output
Only uses ref attribute (not href) because href would be
the alternate link that's always included also.
Creates new conversation for every non-reply status. Carries
over conversation for every reply. Keeps remote URIs verbatim,
generates local URIs on the fly like the rest of them.
* Conversation muting - prevents notifications that reference a conversation
(including replies, favourites, reblogs) from being created. API endpoints
/api/v1/statuses/:id/mute and /api/v1/statuses/:id/unmute
Currently no way to tell when a status/conversation is muted, so the web UI
only has a "disable notifications" button, doesn't work as a toggle
* Display "Dismiss notifications" on all statuses in notifications column, not just own
* Add "muted" as a boolean attribute on statuses JSON
For now always false on contained reblogs, since it's only relevant for
statuses returned from the notifications endpoint, which are not nested
Remove "Disable notifications" from detailed status view, since it's
only relevant in the notifications column
* Up max class length
* Remove pending test for conversation mute
* Add tests, clean up
* Rename to "mute conversation" and "unmute conversation"
* Raise validation error when trying to mute/unmute status without conversation
2017-05-15 11:04:13 +10:00
|
|
|
it 'does not notify when sender is blocked' do
|
|
|
|
recipient.block!(sender)
|
2022-03-28 21:43:58 +11:00
|
|
|
expect { subject }.to_not change(Notification, :count)
|
Feature conversations muting (#3017)
* Add <ostatus:conversation /> tag to Atom input/output
Only uses ref attribute (not href) because href would be
the alternate link that's always included also.
Creates new conversation for every non-reply status. Carries
over conversation for every reply. Keeps remote URIs verbatim,
generates local URIs on the fly like the rest of them.
* Conversation muting - prevents notifications that reference a conversation
(including replies, favourites, reblogs) from being created. API endpoints
/api/v1/statuses/:id/mute and /api/v1/statuses/:id/unmute
Currently no way to tell when a status/conversation is muted, so the web UI
only has a "disable notifications" button, doesn't work as a toggle
* Display "Dismiss notifications" on all statuses in notifications column, not just own
* Add "muted" as a boolean attribute on statuses JSON
For now always false on contained reblogs, since it's only relevant for
statuses returned from the notifications endpoint, which are not nested
Remove "Disable notifications" from detailed status view, since it's
only relevant in the notifications column
* Up max class length
* Remove pending test for conversation mute
* Add tests, clean up
* Rename to "mute conversation" and "unmute conversation"
* Raise validation error when trying to mute/unmute status without conversation
2017-05-15 11:04:13 +10:00
|
|
|
end
|
|
|
|
|
2017-11-15 13:56:41 +11:00
|
|
|
it 'does not notify when sender is muted with hide_notifications' do
|
|
|
|
recipient.mute!(sender, notifications: true)
|
2022-03-28 21:43:58 +11:00
|
|
|
expect { subject }.to_not change(Notification, :count)
|
2017-11-15 13:56:41 +11:00
|
|
|
end
|
|
|
|
|
|
|
|
it 'does notify when sender is muted without hide_notifications' do
|
|
|
|
recipient.mute!(sender, notifications: false)
|
2022-03-28 21:43:58 +11:00
|
|
|
expect { subject }.to change(Notification, :count)
|
2017-11-15 13:56:41 +11:00
|
|
|
end
|
|
|
|
|
Account domain blocks (#2381)
* Add <ostatus:conversation /> tag to Atom input/output
Only uses ref attribute (not href) because href would be
the alternate link that's always included also.
Creates new conversation for every non-reply status. Carries
over conversation for every reply. Keeps remote URIs verbatim,
generates local URIs on the fly like the rest of them.
* Conversation muting - prevents notifications that reference a conversation
(including replies, favourites, reblogs) from being created. API endpoints
/api/v1/statuses/:id/mute and /api/v1/statuses/:id/unmute
Currently no way to tell when a status/conversation is muted, so the web UI
only has a "disable notifications" button, doesn't work as a toggle
* Display "Dismiss notifications" on all statuses in notifications column, not just own
* Add "muted" as a boolean attribute on statuses JSON
For now always false on contained reblogs, since it's only relevant for
statuses returned from the notifications endpoint, which are not nested
Remove "Disable notifications" from detailed status view, since it's
only relevant in the notifications column
* Up max class length
* Remove pending test for conversation mute
* Add tests, clean up
* Rename to "mute conversation" and "unmute conversation"
* Raise validation error when trying to mute/unmute status without conversation
* Adding account domain blocks that filter notifications and public timelines
* Add tests for domain blocks in notifications, public timelines
Filter reblogs of blocked domains from home
* Add API for listing and creating account domain blocks
* API for creating/deleting domain blocks, tests for Status#ancestors
and Status#descendants, filter domain blocks from them
* Filter domains in streaming API
* Update account_domain_block_spec.rb
2017-05-19 09:14:30 +10:00
|
|
|
it 'does not notify when sender\'s domain is blocked' do
|
|
|
|
recipient.block_domain!(sender.domain)
|
2022-03-28 21:43:58 +11:00
|
|
|
expect { subject }.to_not change(Notification, :count)
|
Account domain blocks (#2381)
* Add <ostatus:conversation /> tag to Atom input/output
Only uses ref attribute (not href) because href would be
the alternate link that's always included also.
Creates new conversation for every non-reply status. Carries
over conversation for every reply. Keeps remote URIs verbatim,
generates local URIs on the fly like the rest of them.
* Conversation muting - prevents notifications that reference a conversation
(including replies, favourites, reblogs) from being created. API endpoints
/api/v1/statuses/:id/mute and /api/v1/statuses/:id/unmute
Currently no way to tell when a status/conversation is muted, so the web UI
only has a "disable notifications" button, doesn't work as a toggle
* Display "Dismiss notifications" on all statuses in notifications column, not just own
* Add "muted" as a boolean attribute on statuses JSON
For now always false on contained reblogs, since it's only relevant for
statuses returned from the notifications endpoint, which are not nested
Remove "Disable notifications" from detailed status view, since it's
only relevant in the notifications column
* Up max class length
* Remove pending test for conversation mute
* Add tests, clean up
* Rename to "mute conversation" and "unmute conversation"
* Raise validation error when trying to mute/unmute status without conversation
* Adding account domain blocks that filter notifications and public timelines
* Add tests for domain blocks in notifications, public timelines
Filter reblogs of blocked domains from home
* Add API for listing and creating account domain blocks
* API for creating/deleting domain blocks, tests for Status#ancestors
and Status#descendants, filter domain blocks from them
* Filter domains in streaming API
* Update account_domain_block_spec.rb
2017-05-19 09:14:30 +10:00
|
|
|
end
|
|
|
|
|
2017-05-20 05:05:32 +10:00
|
|
|
it 'does still notify when sender\'s domain is blocked but sender is followed' do
|
|
|
|
recipient.block_domain!(sender.domain)
|
|
|
|
recipient.follow!(sender)
|
2022-03-28 21:43:58 +11:00
|
|
|
expect { subject }.to change(Notification, :count)
|
2017-05-20 05:05:32 +10:00
|
|
|
end
|
|
|
|
|
Feature conversations muting (#3017)
* Add <ostatus:conversation /> tag to Atom input/output
Only uses ref attribute (not href) because href would be
the alternate link that's always included also.
Creates new conversation for every non-reply status. Carries
over conversation for every reply. Keeps remote URIs verbatim,
generates local URIs on the fly like the rest of them.
* Conversation muting - prevents notifications that reference a conversation
(including replies, favourites, reblogs) from being created. API endpoints
/api/v1/statuses/:id/mute and /api/v1/statuses/:id/unmute
Currently no way to tell when a status/conversation is muted, so the web UI
only has a "disable notifications" button, doesn't work as a toggle
* Display "Dismiss notifications" on all statuses in notifications column, not just own
* Add "muted" as a boolean attribute on statuses JSON
For now always false on contained reblogs, since it's only relevant for
statuses returned from the notifications endpoint, which are not nested
Remove "Disable notifications" from detailed status view, since it's
only relevant in the notifications column
* Up max class length
* Remove pending test for conversation mute
* Add tests, clean up
* Rename to "mute conversation" and "unmute conversation"
* Raise validation error when trying to mute/unmute status without conversation
2017-05-15 11:04:13 +10:00
|
|
|
it 'does not notify when sender is silenced and not followed' do
|
2019-05-15 03:05:02 +10:00
|
|
|
sender.silence!
|
2022-03-28 21:43:58 +11:00
|
|
|
expect { subject }.to_not change(Notification, :count)
|
Feature conversations muting (#3017)
* Add <ostatus:conversation /> tag to Atom input/output
Only uses ref attribute (not href) because href would be
the alternate link that's always included also.
Creates new conversation for every non-reply status. Carries
over conversation for every reply. Keeps remote URIs verbatim,
generates local URIs on the fly like the rest of them.
* Conversation muting - prevents notifications that reference a conversation
(including replies, favourites, reblogs) from being created. API endpoints
/api/v1/statuses/:id/mute and /api/v1/statuses/:id/unmute
Currently no way to tell when a status/conversation is muted, so the web UI
only has a "disable notifications" button, doesn't work as a toggle
* Display "Dismiss notifications" on all statuses in notifications column, not just own
* Add "muted" as a boolean attribute on statuses JSON
For now always false on contained reblogs, since it's only relevant for
statuses returned from the notifications endpoint, which are not nested
Remove "Disable notifications" from detailed status view, since it's
only relevant in the notifications column
* Up max class length
* Remove pending test for conversation mute
* Add tests, clean up
* Rename to "mute conversation" and "unmute conversation"
* Raise validation error when trying to mute/unmute status without conversation
2017-05-15 11:04:13 +10:00
|
|
|
end
|
|
|
|
|
|
|
|
it 'does not notify when recipient is suspended' do
|
2019-05-15 03:05:02 +10:00
|
|
|
recipient.suspend!
|
2022-03-28 21:43:58 +11:00
|
|
|
expect { subject }.to_not change(Notification, :count)
|
Feature conversations muting (#3017)
* Add <ostatus:conversation /> tag to Atom input/output
Only uses ref attribute (not href) because href would be
the alternate link that's always included also.
Creates new conversation for every non-reply status. Carries
over conversation for every reply. Keeps remote URIs verbatim,
generates local URIs on the fly like the rest of them.
* Conversation muting - prevents notifications that reference a conversation
(including replies, favourites, reblogs) from being created. API endpoints
/api/v1/statuses/:id/mute and /api/v1/statuses/:id/unmute
Currently no way to tell when a status/conversation is muted, so the web UI
only has a "disable notifications" button, doesn't work as a toggle
* Display "Dismiss notifications" on all statuses in notifications column, not just own
* Add "muted" as a boolean attribute on statuses JSON
For now always false on contained reblogs, since it's only relevant for
statuses returned from the notifications endpoint, which are not nested
Remove "Disable notifications" from detailed status view, since it's
only relevant in the notifications column
* Up max class length
* Remove pending test for conversation mute
* Add tests, clean up
* Rename to "mute conversation" and "unmute conversation"
* Raise validation error when trying to mute/unmute status without conversation
2017-05-15 11:04:13 +10:00
|
|
|
end
|
|
|
|
|
2023-05-04 13:49:08 +10:00
|
|
|
context 'with direct messages' do
|
2017-11-15 07:12:57 +11:00
|
|
|
let(:activity) { Fabricate(:mention, account: recipient, status: Fabricate(:status, account: sender, visibility: :direct)) }
|
2020-09-19 01:26:45 +10:00
|
|
|
let(:type) { :mention }
|
2017-11-15 07:12:57 +11:00
|
|
|
|
|
|
|
before do
|
2023-03-30 23:44:00 +11:00
|
|
|
user.settings.update('interactions.must_be_following_dm': enabled)
|
|
|
|
user.save
|
2017-11-15 07:12:57 +11:00
|
|
|
end
|
|
|
|
|
2023-05-04 13:49:08 +10:00
|
|
|
context 'when recipient is supposed to be following sender' do
|
2017-11-15 07:12:57 +11:00
|
|
|
let(:enabled) { true }
|
|
|
|
|
|
|
|
it 'does not notify' do
|
2022-03-28 21:43:58 +11:00
|
|
|
expect { subject }.to_not change(Notification, :count)
|
2017-11-15 07:12:57 +11:00
|
|
|
end
|
|
|
|
|
2023-05-04 13:49:08 +10:00
|
|
|
context 'when the message chain is initiated by recipient, but is not direct message' do
|
2017-11-15 07:12:57 +11:00
|
|
|
let(:reply_to) { Fabricate(:status, account: recipient) }
|
|
|
|
let(:activity) { Fabricate(:mention, account: recipient, status: Fabricate(:status, account: sender, visibility: :direct, thread: reply_to)) }
|
|
|
|
|
2023-12-22 01:23:53 +11:00
|
|
|
before { Fabricate(:mention, account: sender, status: reply_to) }
|
|
|
|
|
2018-01-19 02:12:10 +11:00
|
|
|
it 'does not notify' do
|
2022-03-28 21:43:58 +11:00
|
|
|
expect { subject }.to_not change(Notification, :count)
|
2018-01-19 02:12:10 +11:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2023-05-04 13:49:08 +10:00
|
|
|
context 'when the message chain is initiated by recipient, but without a mention to the sender, even if the sender sends multiple messages in a row' do
|
2021-11-26 09:46:30 +11:00
|
|
|
let(:reply_to) { Fabricate(:status, account: recipient) }
|
|
|
|
let(:dummy_reply) { Fabricate(:status, account: sender, visibility: :direct, thread: reply_to) }
|
|
|
|
let(:activity) { Fabricate(:mention, account: recipient, status: Fabricate(:status, account: sender, visibility: :direct, thread: dummy_reply)) }
|
|
|
|
|
2023-12-22 01:23:53 +11:00
|
|
|
before { Fabricate(:mention, account: sender, status: reply_to) }
|
|
|
|
|
2021-11-26 09:46:30 +11:00
|
|
|
it 'does not notify' do
|
2022-03-28 21:43:58 +11:00
|
|
|
expect { subject }.to_not change(Notification, :count)
|
2021-11-26 09:46:30 +11:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2023-05-04 13:49:08 +10:00
|
|
|
context 'when the message chain is initiated by the recipient with a mention to the sender' do
|
2018-01-19 02:12:10 +11:00
|
|
|
let(:reply_to) { Fabricate(:status, account: recipient, visibility: :direct) }
|
|
|
|
let(:activity) { Fabricate(:mention, account: recipient, status: Fabricate(:status, account: sender, visibility: :direct, thread: reply_to)) }
|
|
|
|
|
2023-12-22 01:23:53 +11:00
|
|
|
before { Fabricate(:mention, account: sender, status: reply_to) }
|
|
|
|
|
2017-11-15 07:12:57 +11:00
|
|
|
it 'does notify' do
|
2022-03-28 21:43:58 +11:00
|
|
|
expect { subject }.to change(Notification, :count)
|
2017-11-15 07:12:57 +11:00
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2023-05-04 13:49:08 +10:00
|
|
|
context 'when recipient is NOT supposed to be following sender' do
|
2017-11-15 07:12:57 +11:00
|
|
|
let(:enabled) { false }
|
|
|
|
|
|
|
|
it 'does notify' do
|
2022-03-28 21:43:58 +11:00
|
|
|
expect { subject }.to change(Notification, :count)
|
2017-11-15 07:12:57 +11:00
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
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.
2017-11-29 01:00:35 +11:00
|
|
|
describe 'reblogs' do
|
|
|
|
let(:status) { Fabricate(:status, account: Fabricate(:account)) }
|
|
|
|
let(:activity) { Fabricate(:status, account: sender, reblog: status) }
|
2020-09-19 01:26:45 +10:00
|
|
|
let(:type) { :reblog }
|
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.
2017-11-29 01:00:35 +11:00
|
|
|
|
|
|
|
it 'shows reblogs by default' do
|
|
|
|
recipient.follow!(sender)
|
2022-03-28 21:43:58 +11:00
|
|
|
expect { subject }.to change(Notification, :count)
|
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.
2017-11-29 01:00:35 +11:00
|
|
|
end
|
|
|
|
|
|
|
|
it 'shows reblogs when explicitly enabled' do
|
|
|
|
recipient.follow!(sender, reblogs: true)
|
2022-03-28 21:43:58 +11:00
|
|
|
expect { subject }.to change(Notification, :count)
|
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.
2017-11-29 01:00:35 +11:00
|
|
|
end
|
|
|
|
|
2018-10-30 10:47:31 +11:00
|
|
|
it 'shows reblogs when disabled' do
|
2019-06-03 02:08:26 +10:00
|
|
|
recipient.follow!(sender, reblogs: false)
|
2022-03-28 21:43:58 +11:00
|
|
|
expect { subject }.to change(Notification, :count)
|
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.
2017-11-29 01:00:35 +11:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2023-06-06 23:51:42 +10:00
|
|
|
context 'with muted and blocked users' do
|
Feature conversations muting (#3017)
* Add <ostatus:conversation /> tag to Atom input/output
Only uses ref attribute (not href) because href would be
the alternate link that's always included also.
Creates new conversation for every non-reply status. Carries
over conversation for every reply. Keeps remote URIs verbatim,
generates local URIs on the fly like the rest of them.
* Conversation muting - prevents notifications that reference a conversation
(including replies, favourites, reblogs) from being created. API endpoints
/api/v1/statuses/:id/mute and /api/v1/statuses/:id/unmute
Currently no way to tell when a status/conversation is muted, so the web UI
only has a "disable notifications" button, doesn't work as a toggle
* Display "Dismiss notifications" on all statuses in notifications column, not just own
* Add "muted" as a boolean attribute on statuses JSON
For now always false on contained reblogs, since it's only relevant for
statuses returned from the notifications endpoint, which are not nested
Remove "Disable notifications" from detailed status view, since it's
only relevant in the notifications column
* Up max class length
* Remove pending test for conversation mute
* Add tests, clean up
* Rename to "mute conversation" and "unmute conversation"
* Raise validation error when trying to mute/unmute status without conversation
2017-05-15 11:04:13 +10:00
|
|
|
let(:asshole) { Fabricate(:account, username: 'asshole') }
|
|
|
|
let(:reply_to) { Fabricate(:status, account: asshole) }
|
|
|
|
let(:activity) { Fabricate(:mention, account: recipient, status: Fabricate(:status, account: sender, thread: reply_to)) }
|
2020-09-19 01:26:45 +10:00
|
|
|
let(:type) { :mention }
|
Feature conversations muting (#3017)
* Add <ostatus:conversation /> tag to Atom input/output
Only uses ref attribute (not href) because href would be
the alternate link that's always included also.
Creates new conversation for every non-reply status. Carries
over conversation for every reply. Keeps remote URIs verbatim,
generates local URIs on the fly like the rest of them.
* Conversation muting - prevents notifications that reference a conversation
(including replies, favourites, reblogs) from being created. API endpoints
/api/v1/statuses/:id/mute and /api/v1/statuses/:id/unmute
Currently no way to tell when a status/conversation is muted, so the web UI
only has a "disable notifications" button, doesn't work as a toggle
* Display "Dismiss notifications" on all statuses in notifications column, not just own
* Add "muted" as a boolean attribute on statuses JSON
For now always false on contained reblogs, since it's only relevant for
statuses returned from the notifications endpoint, which are not nested
Remove "Disable notifications" from detailed status view, since it's
only relevant in the notifications column
* Up max class length
* Remove pending test for conversation mute
* Add tests, clean up
* Rename to "mute conversation" and "unmute conversation"
* Raise validation error when trying to mute/unmute status without conversation
2017-05-15 11:04:13 +10:00
|
|
|
|
|
|
|
it 'does not notify when conversation is muted' do
|
|
|
|
recipient.mute_conversation!(activity.status.conversation)
|
2022-03-28 21:43:58 +11:00
|
|
|
expect { subject }.to_not change(Notification, :count)
|
Feature conversations muting (#3017)
* Add <ostatus:conversation /> tag to Atom input/output
Only uses ref attribute (not href) because href would be
the alternate link that's always included also.
Creates new conversation for every non-reply status. Carries
over conversation for every reply. Keeps remote URIs verbatim,
generates local URIs on the fly like the rest of them.
* Conversation muting - prevents notifications that reference a conversation
(including replies, favourites, reblogs) from being created. API endpoints
/api/v1/statuses/:id/mute and /api/v1/statuses/:id/unmute
Currently no way to tell when a status/conversation is muted, so the web UI
only has a "disable notifications" button, doesn't work as a toggle
* Display "Dismiss notifications" on all statuses in notifications column, not just own
* Add "muted" as a boolean attribute on statuses JSON
For now always false on contained reblogs, since it's only relevant for
statuses returned from the notifications endpoint, which are not nested
Remove "Disable notifications" from detailed status view, since it's
only relevant in the notifications column
* Up max class length
* Remove pending test for conversation mute
* Add tests, clean up
* Rename to "mute conversation" and "unmute conversation"
* Raise validation error when trying to mute/unmute status without conversation
2017-05-15 11:04:13 +10:00
|
|
|
end
|
|
|
|
|
|
|
|
it 'does not notify when it is a reply to a blocked user' do
|
|
|
|
recipient.block!(asshole)
|
2022-03-28 21:43:58 +11:00
|
|
|
expect { subject }.to_not change(Notification, :count)
|
Feature conversations muting (#3017)
* Add <ostatus:conversation /> tag to Atom input/output
Only uses ref attribute (not href) because href would be
the alternate link that's always included also.
Creates new conversation for every non-reply status. Carries
over conversation for every reply. Keeps remote URIs verbatim,
generates local URIs on the fly like the rest of them.
* Conversation muting - prevents notifications that reference a conversation
(including replies, favourites, reblogs) from being created. API endpoints
/api/v1/statuses/:id/mute and /api/v1/statuses/:id/unmute
Currently no way to tell when a status/conversation is muted, so the web UI
only has a "disable notifications" button, doesn't work as a toggle
* Display "Dismiss notifications" on all statuses in notifications column, not just own
* Add "muted" as a boolean attribute on statuses JSON
For now always false on contained reblogs, since it's only relevant for
statuses returned from the notifications endpoint, which are not nested
Remove "Disable notifications" from detailed status view, since it's
only relevant in the notifications column
* Up max class length
* Remove pending test for conversation mute
* Add tests, clean up
* Rename to "mute conversation" and "unmute conversation"
* Raise validation error when trying to mute/unmute status without conversation
2017-05-15 11:04:13 +10:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2023-06-06 23:51:42 +10:00
|
|
|
context 'with sender as recipient' do
|
Feature conversations muting (#3017)
* Add <ostatus:conversation /> tag to Atom input/output
Only uses ref attribute (not href) because href would be
the alternate link that's always included also.
Creates new conversation for every non-reply status. Carries
over conversation for every reply. Keeps remote URIs verbatim,
generates local URIs on the fly like the rest of them.
* Conversation muting - prevents notifications that reference a conversation
(including replies, favourites, reblogs) from being created. API endpoints
/api/v1/statuses/:id/mute and /api/v1/statuses/:id/unmute
Currently no way to tell when a status/conversation is muted, so the web UI
only has a "disable notifications" button, doesn't work as a toggle
* Display "Dismiss notifications" on all statuses in notifications column, not just own
* Add "muted" as a boolean attribute on statuses JSON
For now always false on contained reblogs, since it's only relevant for
statuses returned from the notifications endpoint, which are not nested
Remove "Disable notifications" from detailed status view, since it's
only relevant in the notifications column
* Up max class length
* Remove pending test for conversation mute
* Add tests, clean up
* Rename to "mute conversation" and "unmute conversation"
* Raise validation error when trying to mute/unmute status without conversation
2017-05-15 11:04:13 +10:00
|
|
|
let(:sender) { recipient }
|
|
|
|
|
|
|
|
it 'does not notify when recipient is the sender' do
|
2022-03-28 21:43:58 +11:00
|
|
|
expect { subject }.to_not change(Notification, :count)
|
Feature conversations muting (#3017)
* Add <ostatus:conversation /> tag to Atom input/output
Only uses ref attribute (not href) because href would be
the alternate link that's always included also.
Creates new conversation for every non-reply status. Carries
over conversation for every reply. Keeps remote URIs verbatim,
generates local URIs on the fly like the rest of them.
* Conversation muting - prevents notifications that reference a conversation
(including replies, favourites, reblogs) from being created. API endpoints
/api/v1/statuses/:id/mute and /api/v1/statuses/:id/unmute
Currently no way to tell when a status/conversation is muted, so the web UI
only has a "disable notifications" button, doesn't work as a toggle
* Display "Dismiss notifications" on all statuses in notifications column, not just own
* Add "muted" as a boolean attribute on statuses JSON
For now always false on contained reblogs, since it's only relevant for
statuses returned from the notifications endpoint, which are not nested
Remove "Disable notifications" from detailed status view, since it's
only relevant in the notifications column
* Up max class length
* Remove pending test for conversation mute
* Add tests, clean up
* Rename to "mute conversation" and "unmute conversation"
* Raise validation error when trying to mute/unmute status without conversation
2017-05-15 11:04:13 +10:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2017-05-07 07:06:52 +10:00
|
|
|
describe 'email' do
|
|
|
|
before do
|
|
|
|
ActionMailer::Base.deliveries.clear
|
|
|
|
|
2023-03-30 23:44:00 +11:00
|
|
|
user.settings.update('notification_emails.follow': enabled)
|
|
|
|
user.save
|
2017-05-07 07:06:52 +10:00
|
|
|
end
|
|
|
|
|
|
|
|
context 'when email notification is enabled' do
|
|
|
|
let(:enabled) { true }
|
|
|
|
|
|
|
|
it 'sends email' do
|
2022-03-28 21:43:58 +11:00
|
|
|
expect { subject }.to change(ActionMailer::Base.deliveries, :count).by(1)
|
2017-05-07 07:06:52 +10:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
context 'when email notification is disabled' do
|
|
|
|
let(:enabled) { false }
|
|
|
|
|
|
|
|
it "doesn't send email" do
|
2022-03-28 21:43:58 +11:00
|
|
|
expect { subject }.to_not change(ActionMailer::Base.deliveries, :count).from(0)
|
2017-05-07 07:06:52 +10:00
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|