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.
glitchier-soc/spec/services/follow_service_spec.rb

143 lines
4.5 KiB

require 'rails_helper'
RSpec.describe FollowService, type: :service do
let(:sender) { Fabricate(:account, username: 'alice') }
subject { FollowService.new }
context 'local account' do
describe 'locked account' do
let(:bob) { Fabricate(:user, email: 'bob@example.com', account: Fabricate(:account, locked: true, username: 'bob')).account }
before do
subject.call(sender, bob.acct)
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.
7 years ago
it 'creates a follow request with reblogs' do
expect(FollowRequest.find_by(account: sender, target_account: bob, show_reblogs: true)).to_not be_nil
end
end
describe 'locked account, no reblogs' do
let(:bob) { Fabricate(:user, email: 'bob@example.com', account: Fabricate(:account, locked: true, username: 'bob')).account }
before do
subject.call(sender, bob.acct, reblogs: false)
end
it 'creates a follow request without reblogs' do
expect(FollowRequest.find_by(account: sender, target_account: bob, show_reblogs: false)).to_not be_nil
end
end
describe 'unlocked account, from silenced account' do
let(:bob) { Fabricate(:user, email: 'bob@example.com', account: Fabricate(:account, username: 'bob')).account }
before do
sender.touch(:silenced_at)
subject.call(sender, bob.acct)
end
it 'creates a follow request with reblogs' do
expect(FollowRequest.find_by(account: sender, target_account: bob, show_reblogs: true)).to_not be_nil
end
end
describe 'unlocked account, from a muted account' do
let(:bob) { Fabricate(:user, email: 'bob@example.com', account: Fabricate(:account, username: 'bob')).account }
before do
bob.mute!(sender)
subject.call(sender, bob.acct)
end
it 'creates a following relation with reblogs' do
expect(sender.following?(bob)).to be true
expect(sender.muting_reblogs?(bob)).to be false
end
end
describe 'unlocked account' do
let(:bob) { Fabricate(:user, email: 'bob@example.com', account: Fabricate(:account, username: 'bob')).account }
before do
subject.call(sender, bob.acct)
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.
7 years ago
it 'creates a following relation with reblogs' do
expect(sender.following?(bob)).to be true
expect(sender.muting_reblogs?(bob)).to be false
end
end
describe 'unlocked account, no reblogs' do
let(:bob) { Fabricate(:user, email: 'bob@example.com', account: Fabricate(:account, username: 'bob')).account }
before do
subject.call(sender, bob.acct, reblogs: false)
end
it 'creates a following relation without reblogs' do
expect(sender.following?(bob)).to be true
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.
7 years ago
expect(sender.muting_reblogs?(bob)).to be true
end
end
describe 'already followed account' do
let(:bob) { Fabricate(:user, email: 'bob@example.com', account: Fabricate(:account, username: 'bob')).account }
before do
sender.follow!(bob)
subject.call(sender, bob.acct)
end
it 'keeps a following relation' do
expect(sender.following?(bob)).to be true
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.
7 years ago
describe 'already followed account, turning reblogs off' do
let(:bob) { Fabricate(:user, email: 'bob@example.com', account: Fabricate(:account, username: 'bob')).account }
before do
sender.follow!(bob, reblogs: true)
subject.call(sender, bob.acct, reblogs: false)
end
it 'disables reblogs' do
expect(sender.muting_reblogs?(bob)).to be true
end
end
describe 'already followed account, turning reblogs on' do
let(:bob) { Fabricate(:user, email: 'bob@example.com', account: Fabricate(:account, username: 'bob')).account }
before do
sender.follow!(bob, reblogs: false)
subject.call(sender, bob.acct, reblogs: true)
end
it 'disables reblogs' do
expect(sender.muting_reblogs?(bob)).to be false
end
end
end
context 'remote ActivityPub account' do
let(:bob) { Fabricate(:user, account: Fabricate(:account, username: 'bob', domain: 'example.com', protocol: :activitypub, inbox_url: 'http://example.com/inbox')).account }
before do
stub_request(:post, "http://example.com/inbox").to_return(:status => 200, :body => "", :headers => {})
subject.call(sender, bob.acct)
end
it 'creates follow request' do
expect(FollowRequest.find_by(account: sender, target_account: bob)).to_not be_nil
end
it 'sends a follow activity to the inbox' do
expect(a_request(:post, 'http://example.com/inbox')).to have_been_made.once
end
end
end