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.

115 lines
3.7 KiB

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
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
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
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
  1. require 'rails_helper'
  2. RSpec.describe FollowService, type: :service do
  3. let(:sender) { Fabricate(:account, username: 'alice') }
  4. subject { FollowService.new }
  5. context 'local account' do
  6. describe 'locked account' do
  7. let(:bob) { Fabricate(:user, email: 'bob@example.com', account: Fabricate(:account, locked: true, username: 'bob')).account }
  8. before do
  9. subject.call(sender, bob.acct)
  10. end
  11. it 'creates a follow request with reblogs' do
  12. expect(FollowRequest.find_by(account: sender, target_account: bob, show_reblogs: true)).to_not be_nil
  13. end
  14. end
  15. describe 'locked account, no reblogs' do
  16. let(:bob) { Fabricate(:user, email: 'bob@example.com', account: Fabricate(:account, locked: true, username: 'bob')).account }
  17. before do
  18. subject.call(sender, bob.acct, reblogs: false)
  19. end
  20. it 'creates a follow request without reblogs' do
  21. expect(FollowRequest.find_by(account: sender, target_account: bob, show_reblogs: false)).to_not be_nil
  22. end
  23. end
  24. describe 'unlocked account' do
  25. let(:bob) { Fabricate(:user, email: 'bob@example.com', account: Fabricate(:account, username: 'bob')).account }
  26. before do
  27. subject.call(sender, bob.acct)
  28. end
  29. it 'creates a following relation with reblogs' do
  30. expect(sender.following?(bob)).to be true
  31. expect(sender.muting_reblogs?(bob)).to be false
  32. end
  33. end
  34. describe 'unlocked account, no reblogs' do
  35. let(:bob) { Fabricate(:user, email: 'bob@example.com', account: Fabricate(:account, username: 'bob')).account }
  36. before do
  37. subject.call(sender, bob.acct, reblogs: false)
  38. end
  39. it 'creates a following relation without reblogs' do
  40. expect(sender.following?(bob)).to be true
  41. expect(sender.muting_reblogs?(bob)).to be true
  42. end
  43. end
  44. describe 'already followed account' do
  45. let(:bob) { Fabricate(:user, email: 'bob@example.com', account: Fabricate(:account, username: 'bob')).account }
  46. before do
  47. sender.follow!(bob)
  48. subject.call(sender, bob.acct)
  49. end
  50. it 'keeps a following relation' do
  51. expect(sender.following?(bob)).to be true
  52. end
  53. end
  54. describe 'already followed account, turning reblogs off' do
  55. let(:bob) { Fabricate(:user, email: 'bob@example.com', account: Fabricate(:account, username: 'bob')).account }
  56. before do
  57. sender.follow!(bob, reblogs: true)
  58. subject.call(sender, bob.acct, reblogs: false)
  59. end
  60. it 'disables reblogs' do
  61. expect(sender.muting_reblogs?(bob)).to be true
  62. end
  63. end
  64. describe 'already followed account, turning reblogs on' do
  65. let(:bob) { Fabricate(:user, email: 'bob@example.com', account: Fabricate(:account, username: 'bob')).account }
  66. before do
  67. sender.follow!(bob, reblogs: false)
  68. subject.call(sender, bob.acct, reblogs: true)
  69. end
  70. it 'disables reblogs' do
  71. expect(sender.muting_reblogs?(bob)).to be false
  72. end
  73. end
  74. end
  75. context 'remote ActivityPub account' do
  76. let(:bob) { Fabricate(:user, account: Fabricate(:account, username: 'bob', domain: 'example.com', protocol: :activitypub, inbox_url: 'http://example.com/inbox')).account }
  77. before do
  78. stub_request(:post, "http://example.com/inbox").to_return(:status => 200, :body => "", :headers => {})
  79. subject.call(sender, bob.acct)
  80. end
  81. it 'creates follow request' do
  82. expect(FollowRequest.find_by(account: sender, target_account: bob)).to_not be_nil
  83. end
  84. it 'sends a follow activity to the inbox' do
  85. expect(a_request(:post, 'http://example.com/inbox')).to have_been_made.once
  86. end
  87. end
  88. end