fedi/mastodon
1
0
Fork 1
mirror of https://github.com/mastodon/mastodon.git synced 2024-12-19 07:57:00 +00:00
Code Issues Packages Projects Releases Wiki Activity
mastodon/spec/models/glitch/keyword_mute_spec.rb

172 lines
6 KiB
Ruby
Raw Normal View History

Add KeywordMute model. Gist of the proposed keyword mute implementation: Keyword mutes are represented server-side as one keyword per record. For each account, there exists a keyword regex that is generated as one big alternation of all keywords. This regex is cached (in Redis, I guess) so we can quickly get it when filtering in FeedManager.
2017-10-09 22:28:28 +00:00
require 'rails_helper'
Move KeywordMute into Glitch namespace. There are two motivations for this: 1. It looks like we're going to add other features that require server-side storage (e.g. user notes). 2. Namespacing glitchsoc modifications is a good idea anyway: even if we do not end up doing (1), if upstream introduces a keyword-mute feature that also uses a "KeywordMute" model, we can avoid some merge conflicts this way and work on the more interesting task of choosing which implementation to use.
2017-10-21 19:47:17 +00:00
RSpec.describe Glitch::KeywordMute, type: :model do
Rework KeywordMute interface to use a matcher object; spec out matcher. #164. A matcher object that builds a match from KeywordMute data and runs it over text is, in my view, one of the easier ways to write examples for this sort of thing.
2017-10-15 01:36:53 +00:00
let(:alice) { Fabricate(:account, username: 'alice').tap(&:save!) }
let(:bob) { Fabricate(:account, username: 'bob').tap(&:save!) }
Spec out KeywordMute interface. #164.
2017-10-14 07:28:20 +00:00
Thread scopes through #matches?. #454. Also add an apply_to_mentions attribute on Glitch::KeywordMute, which is used to calculate scope. Next up: additions to the test suite to demonstrate how scoping works.
2018-06-04 00:41:54 +00:00
Unscoped = Glitch::KeywordMute::Scopes::Unscoped
Match keyword mute filter on hashtags. #208. It is reasonable to expect someone to enter #foo to mute hashtag #foo. However, tags are recorded on statuses without the preceding #. To adjust for this, we build a separate tag matcher and use Tag::HASHTAG_RE to extract a hashtag from the hashtag syntax.
2017-11-15 23:26:29 +00:00
describe '.text_matcher_for' do
let(:matcher) { Glitch::KeywordMute.text_matcher_for(alice.id) }
Spec out KeywordMute interface. #164.
2017-10-14 07:28:20 +00:00
Don't add \b to whole-word keywords that don't start with word characters. Ditto for ending with \b. Consider muting the phrase "(hot take)". I stipulate it is reasonable to enter this with the default "match whole word" behavior. Under the old behavior, this would be encoded as \b\(hot\ take\)\b However, if \b is before the first character in the string and the first character in the string is not a word character, then the match will fail. Ditto for after. In our example, "(" is not a word character, so this will not match statuses containing "(hot take)", and that's a very surprising behavior. To address this, we only add leading and trailing \b to keywords that start or end with word characters.
2017-10-22 05:24:32 +00:00
describe 'with no mutes' do
Rework KeywordMute interface to use a matcher object; spec out matcher. #164. A matcher object that builds a match from KeywordMute data and runs it over text is, in my view, one of the easier ways to write examples for this sort of thing.
2017-10-15 01:36:53 +00:00
before do
Move KeywordMute into Glitch namespace. There are two motivations for this: 1. It looks like we're going to add other features that require server-side storage (e.g. user notes). 2. Namespacing glitchsoc modifications is a good idea anyway: even if we do not end up doing (1), if upstream introduces a keyword-mute feature that also uses a "KeywordMute" model, we can avoid some merge conflicts this way and work on the more interesting task of choosing which implementation to use.
2017-10-21 19:47:17 +00:00
Glitch::KeywordMute.delete_all
Rework KeywordMute interface to use a matcher object; spec out matcher. #164. A matcher object that builds a match from KeywordMute data and runs it over text is, in my view, one of the easier ways to write examples for this sort of thing.
2017-10-15 01:36:53 +00:00
end
it 'does not match' do
Thread scopes through #matches?. #454. Also add an apply_to_mentions attribute on Glitch::KeywordMute, which is used to calculate scope. Next up: additions to the test suite to demonstrate how scoping works.
2018-06-04 00:41:54 +00:00
expect(matcher.matches?('This is a hot take', Unscoped)).to be_falsy
Rework KeywordMute interface to use a matcher object; spec out matcher. #164. A matcher object that builds a match from KeywordMute data and runs it over text is, in my view, one of the easier ways to write examples for this sort of thing.
2017-10-15 01:36:53 +00:00
end
Spec out KeywordMute interface. #164.
2017-10-14 07:28:20 +00:00
end
Don't add \b to whole-word keywords that don't start with word characters. Ditto for ending with \b. Consider muting the phrase "(hot take)". I stipulate it is reasonable to enter this with the default "match whole word" behavior. Under the old behavior, this would be encoded as \b\(hot\ take\)\b However, if \b is before the first character in the string and the first character in the string is not a word character, then the match will fail. Ditto for after. In our example, "(" is not a word character, so this will not match statuses containing "(hot take)", and that's a very surprising behavior. To address this, we only add leading and trailing \b to keywords that start or end with word characters.
2017-10-22 05:24:32 +00:00
describe 'with mutes' do
Rework KeywordMute interface to use a matcher object; spec out matcher. #164. A matcher object that builds a match from KeywordMute data and runs it over text is, in my view, one of the easier ways to write examples for this sort of thing.
2017-10-15 01:36:53 +00:00
it 'does not match keywords set by a different account' do
Move KeywordMute into Glitch namespace. There are two motivations for this: 1. It looks like we're going to add other features that require server-side storage (e.g. user notes). 2. Namespacing glitchsoc modifications is a good idea anyway: even if we do not end up doing (1), if upstream introduces a keyword-mute feature that also uses a "KeywordMute" model, we can avoid some merge conflicts this way and work on the more interesting task of choosing which implementation to use.
2017-10-21 19:47:17 +00:00
Glitch::KeywordMute.create!(account: bob, keyword: 'take')
Rework KeywordMute interface to use a matcher object; spec out matcher. #164. A matcher object that builds a match from KeywordMute data and runs it over text is, in my view, one of the easier ways to write examples for this sort of thing.
2017-10-15 01:36:53 +00:00
Thread scopes through #matches?. #454. Also add an apply_to_mentions attribute on Glitch::KeywordMute, which is used to calculate scope. Next up: additions to the test suite to demonstrate how scoping works.
2018-06-04 00:41:54 +00:00
expect(matcher.matches?('This is a hot take', Unscoped)).to be_falsy
Rework KeywordMute interface to use a matcher object; spec out matcher. #164. A matcher object that builds a match from KeywordMute data and runs it over text is, in my view, one of the easier ways to write examples for this sort of thing.
2017-10-15 01:36:53 +00:00
end
it 'does not match if no keywords match the status text' do
Move KeywordMute into Glitch namespace. There are two motivations for this: 1. It looks like we're going to add other features that require server-side storage (e.g. user notes). 2. Namespacing glitchsoc modifications is a good idea anyway: even if we do not end up doing (1), if upstream introduces a keyword-mute feature that also uses a "KeywordMute" model, we can avoid some merge conflicts this way and work on the more interesting task of choosing which implementation to use.
2017-10-21 19:47:17 +00:00
Glitch::KeywordMute.create!(account: alice, keyword: 'cold')
Rework KeywordMute interface to use a matcher object; spec out matcher. #164. A matcher object that builds a match from KeywordMute data and runs it over text is, in my view, one of the easier ways to write examples for this sort of thing.
2017-10-15 01:36:53 +00:00
Thread scopes through #matches?. #454. Also add an apply_to_mentions attribute on Glitch::KeywordMute, which is used to calculate scope. Next up: additions to the test suite to demonstrate how scoping works.
2018-06-04 00:41:54 +00:00
expect(matcher.matches?('This is a hot take', Unscoped)).to be_falsy
Rework KeywordMute interface to use a matcher object; spec out matcher. #164. A matcher object that builds a match from KeywordMute data and runs it over text is, in my view, one of the easier ways to write examples for this sort of thing.
2017-10-15 01:36:53 +00:00
end
Allow keywords to match either substrings or whole words. Word-boundary matching only works as intended in English and languages that use similar word-breaking characters; it doesn't work so well in (say) Japanese, Chinese, or Thai. It's unacceptable to have a feature that doesn't work as intended for some languages. (Moreso especially considering that it's likely that the largest contingent on the Mastodon bit of the fediverse speaks Japanese.) There are rules specified in Unicode TR29[1] for word-breaking across all languages supported by Unicode, but the rules deliberately do not cover all cases. In fact, TR29 states For example, reliable detection of word boundaries in languages such as Thai, Lao, Chinese, or Japanese requires the use of dictionary lookup, analogous to English hyphenation. So we aren't going to be able to make word detection work with regexes within Mastodon (or glitchsoc). However, for a first pass (even if it's kind of punting) we can allow the user to choose whether they want word or substring detection and warn about the limitations of this implementation in, say, docs. [1]: https://unicode.org/reports/tr29/ https://web.archive.org/web/20171001005125/https://unicode.org/reports/tr29/
2017-10-16 00:49:22 +00:00
it 'considers word boundaries when matching' do
Move KeywordMute into Glitch namespace. There are two motivations for this: 1. It looks like we're going to add other features that require server-side storage (e.g. user notes). 2. Namespacing glitchsoc modifications is a good idea anyway: even if we do not end up doing (1), if upstream introduces a keyword-mute feature that also uses a "KeywordMute" model, we can avoid some merge conflicts this way and work on the more interesting task of choosing which implementation to use.
2017-10-21 19:47:17 +00:00
Glitch::KeywordMute.create!(account: alice, keyword: 'bob', whole_word: true)
Allow keywords to match either substrings or whole words. Word-boundary matching only works as intended in English and languages that use similar word-breaking characters; it doesn't work so well in (say) Japanese, Chinese, or Thai. It's unacceptable to have a feature that doesn't work as intended for some languages. (Moreso especially considering that it's likely that the largest contingent on the Mastodon bit of the fediverse speaks Japanese.) There are rules specified in Unicode TR29[1] for word-breaking across all languages supported by Unicode, but the rules deliberately do not cover all cases. In fact, TR29 states For example, reliable detection of word boundaries in languages such as Thai, Lao, Chinese, or Japanese requires the use of dictionary lookup, analogous to English hyphenation. So we aren't going to be able to make word detection work with regexes within Mastodon (or glitchsoc). However, for a first pass (even if it's kind of punting) we can allow the user to choose whether they want word or substring detection and warn about the limitations of this implementation in, say, docs. [1]: https://unicode.org/reports/tr29/ https://web.archive.org/web/20171001005125/https://unicode.org/reports/tr29/
2017-10-16 00:49:22 +00:00
Thread scopes through #matches?. #454. Also add an apply_to_mentions attribute on Glitch::KeywordMute, which is used to calculate scope. Next up: additions to the test suite to demonstrate how scoping works.
2018-06-04 00:41:54 +00:00
expect(matcher.matches?('bobcats', Unscoped)).to be_falsy
Allow keywords to match either substrings or whole words. Word-boundary matching only works as intended in English and languages that use similar word-breaking characters; it doesn't work so well in (say) Japanese, Chinese, or Thai. It's unacceptable to have a feature that doesn't work as intended for some languages. (Moreso especially considering that it's likely that the largest contingent on the Mastodon bit of the fediverse speaks Japanese.) There are rules specified in Unicode TR29[1] for word-breaking across all languages supported by Unicode, but the rules deliberately do not cover all cases. In fact, TR29 states For example, reliable detection of word boundaries in languages such as Thai, Lao, Chinese, or Japanese requires the use of dictionary lookup, analogous to English hyphenation. So we aren't going to be able to make word detection work with regexes within Mastodon (or glitchsoc). However, for a first pass (even if it's kind of punting) we can allow the user to choose whether they want word or substring detection and warn about the limitations of this implementation in, say, docs. [1]: https://unicode.org/reports/tr29/ https://web.archive.org/web/20171001005125/https://unicode.org/reports/tr29/
2017-10-16 00:49:22 +00:00
end
it 'matches substrings if whole_word is false' do
Move KeywordMute into Glitch namespace. There are two motivations for this: 1. It looks like we're going to add other features that require server-side storage (e.g. user notes). 2. Namespacing glitchsoc modifications is a good idea anyway: even if we do not end up doing (1), if upstream introduces a keyword-mute feature that also uses a "KeywordMute" model, we can avoid some merge conflicts this way and work on the more interesting task of choosing which implementation to use.
2017-10-21 19:47:17 +00:00
Glitch::KeywordMute.create!(account: alice, keyword: 'take', whole_word: false)
Rework KeywordMute interface to use a matcher object; spec out matcher. #164. A matcher object that builds a match from KeywordMute data and runs it over text is, in my view, one of the easier ways to write examples for this sort of thing.
2017-10-15 01:36:53 +00:00
Thread scopes through #matches?. #454. Also add an apply_to_mentions attribute on Glitch::KeywordMute, which is used to calculate scope. Next up: additions to the test suite to demonstrate how scoping works.
2018-06-04 00:41:54 +00:00
expect(matcher.matches?('This is a shiitake mushroom', Unscoped)).to be_truthy
Rework KeywordMute interface to use a matcher object; spec out matcher. #164. A matcher object that builds a match from KeywordMute data and runs it over text is, in my view, one of the easier ways to write examples for this sort of thing.
2017-10-15 01:36:53 +00:00
end
it 'matches keywords at the beginning of the text' do
Move KeywordMute into Glitch namespace. There are two motivations for this: 1. It looks like we're going to add other features that require server-side storage (e.g. user notes). 2. Namespacing glitchsoc modifications is a good idea anyway: even if we do not end up doing (1), if upstream introduces a keyword-mute feature that also uses a "KeywordMute" model, we can avoid some merge conflicts this way and work on the more interesting task of choosing which implementation to use.
2017-10-21 19:47:17 +00:00
Glitch::KeywordMute.create!(account: alice, keyword: 'take')
Rework KeywordMute interface to use a matcher object; spec out matcher. #164. A matcher object that builds a match from KeywordMute data and runs it over text is, in my view, one of the easier ways to write examples for this sort of thing.
2017-10-15 01:36:53 +00:00
Thread scopes through #matches?. #454. Also add an apply_to_mentions attribute on Glitch::KeywordMute, which is used to calculate scope. Next up: additions to the test suite to demonstrate how scoping works.
2018-06-04 00:41:54 +00:00
expect(matcher.matches?('Take this', Unscoped)).to be_truthy
Rework KeywordMute interface to use a matcher object; spec out matcher. #164. A matcher object that builds a match from KeywordMute data and runs it over text is, in my view, one of the easier ways to write examples for this sort of thing.
2017-10-15 01:36:53 +00:00
end
Fix example description. This example actually checks matches at the end of a string.
2017-10-24 23:33:02 +00:00
it 'matches keywords at the end of the text' do
Move KeywordMute into Glitch namespace. There are two motivations for this: 1. It looks like we're going to add other features that require server-side storage (e.g. user notes). 2. Namespacing glitchsoc modifications is a good idea anyway: even if we do not end up doing (1), if upstream introduces a keyword-mute feature that also uses a "KeywordMute" model, we can avoid some merge conflicts this way and work on the more interesting task of choosing which implementation to use.
2017-10-21 19:47:17 +00:00
Glitch::KeywordMute.create!(account: alice, keyword: 'take')
Rework KeywordMute interface to use a matcher object; spec out matcher. #164. A matcher object that builds a match from KeywordMute data and runs it over text is, in my view, one of the easier ways to write examples for this sort of thing.
2017-10-15 01:36:53 +00:00
Thread scopes through #matches?. #454. Also add an apply_to_mentions attribute on Glitch::KeywordMute, which is used to calculate scope. Next up: additions to the test suite to demonstrate how scoping works.
2018-06-04 00:41:54 +00:00
expect(matcher.matches?('This is a hot take', Unscoped)).to be_truthy
Rework KeywordMute interface to use a matcher object; spec out matcher. #164. A matcher object that builds a match from KeywordMute data and runs it over text is, in my view, one of the easier ways to write examples for this sort of thing.
2017-10-15 01:36:53 +00:00
end
it 'matches if at least one keyword case-insensitively matches the text' do
Move KeywordMute into Glitch namespace. There are two motivations for this: 1. It looks like we're going to add other features that require server-side storage (e.g. user notes). 2. Namespacing glitchsoc modifications is a good idea anyway: even if we do not end up doing (1), if upstream introduces a keyword-mute feature that also uses a "KeywordMute" model, we can avoid some merge conflicts this way and work on the more interesting task of choosing which implementation to use.
2017-10-21 19:47:17 +00:00
Glitch::KeywordMute.create!(account: alice, keyword: 'hot')
Rework KeywordMute interface to use a matcher object; spec out matcher. #164. A matcher object that builds a match from KeywordMute data and runs it over text is, in my view, one of the easier ways to write examples for this sort of thing.
2017-10-15 01:36:53 +00:00
Thread scopes through #matches?. #454. Also add an apply_to_mentions attribute on Glitch::KeywordMute, which is used to calculate scope. Next up: additions to the test suite to demonstrate how scoping works.
2018-06-04 00:41:54 +00:00
expect(matcher.matches?('This is a HOT take', Unscoped)).to be_truthy
Fix case-insensitive match scenario; test some word ornamentation. #164.
2017-10-15 01:41:52 +00:00
end
Also treat non-whole-word mutes as case-insensitive. #450.
2018-05-01 01:08:22 +00:00
it 'matches if at least one non-whole-word keyword case-insensitively matches the text' do
Glitch::KeywordMute.create!(account: alice, keyword: 'hot', whole_word: false)
Thread scopes through #matches?. #454. Also add an apply_to_mentions attribute on Glitch::KeywordMute, which is used to calculate scope. Next up: additions to the test suite to demonstrate how scoping works.
2018-06-04 00:41:54 +00:00
expect(matcher.matches?('This is a HOTTY take', Unscoped)).to be_truthy
Also treat non-whole-word mutes as case-insensitive. #450.
2018-05-01 01:08:22 +00:00
end
Maintain case-insensitivity when merging multiple matchers (#213) When given two regexps, Regexp.union preserves the options set (or not set) on each regex; this meant that none of the multiline (m), case-insensitivity (i), or extended syntax (x) options were set. Our regexps are written expecting the m, i, and x options were set on all of them, so we need to make sure that we preserve that behavior.
2017-11-13 17:06:02 +00:00
it 'maintains case-insensitivity when combining keywords into a single matcher' do
Glitch::KeywordMute.create!(account: alice, keyword: 'hot')
Glitch::KeywordMute.create!(account: alice, keyword: 'cold')
Thread scopes through #matches?. #454. Also add an apply_to_mentions attribute on Glitch::KeywordMute, which is used to calculate scope. Next up: additions to the test suite to demonstrate how scoping works.
2018-06-04 00:41:54 +00:00
expect(matcher.matches?('This is a HOT take', Unscoped)).to be_truthy
Maintain case-insensitivity when merging multiple matchers (#213) When given two regexps, Regexp.union preserves the options set (or not set) on each regex; this meant that none of the multiline (m), case-insensitivity (i), or extended syntax (x) options were set. Our regexps are written expecting the m, i, and x options were set on all of them, so we need to make sure that we preserve that behavior.
2017-11-13 17:06:02 +00:00
end
Fix case-insensitive match scenario; test some word ornamentation. #164.
2017-10-15 01:41:52 +00:00
it 'matches keywords surrounded by non-alphanumeric ornamentation' do
Move KeywordMute into Glitch namespace. There are two motivations for this: 1. It looks like we're going to add other features that require server-side storage (e.g. user notes). 2. Namespacing glitchsoc modifications is a good idea anyway: even if we do not end up doing (1), if upstream introduces a keyword-mute feature that also uses a "KeywordMute" model, we can avoid some merge conflicts this way and work on the more interesting task of choosing which implementation to use.
2017-10-21 19:47:17 +00:00
Glitch::KeywordMute.create!(account: alice, keyword: 'hot')
Fix case-insensitive match scenario; test some word ornamentation. #164.
2017-10-15 01:41:52 +00:00
Thread scopes through #matches?. #454. Also add an apply_to_mentions attribute on Glitch::KeywordMute, which is used to calculate scope. Next up: additions to the test suite to demonstrate how scoping works.
2018-06-04 00:41:54 +00:00
expect(matcher.matches?('(hot take)', Unscoped)).to be_truthy
Don't add \b to whole-word keywords that don't start with word characters. Ditto for ending with \b. Consider muting the phrase "(hot take)". I stipulate it is reasonable to enter this with the default "match whole word" behavior. Under the old behavior, this would be encoded as \b\(hot\ take\)\b However, if \b is before the first character in the string and the first character in the string is not a word character, then the match will fail. Ditto for after. In our example, "(" is not a word character, so this will not match statuses containing "(hot take)", and that's a very surprising behavior. To address this, we only add leading and trailing \b to keywords that start or end with word characters.
2017-10-22 05:24:32 +00:00
end
Escape metacharacters in non-whole-word keyword mutes. Fixes #533. Also addresses #463.
2018-06-05 07:49:28 +00:00
it 'escapes metacharacters in whole-word keywords' do
Don't add \b to whole-word keywords that don't start with word characters. Ditto for ending with \b. Consider muting the phrase "(hot take)". I stipulate it is reasonable to enter this with the default "match whole word" behavior. Under the old behavior, this would be encoded as \b\(hot\ take\)\b However, if \b is before the first character in the string and the first character in the string is not a word character, then the match will fail. Ditto for after. In our example, "(" is not a word character, so this will not match statuses containing "(hot take)", and that's a very surprising behavior. To address this, we only add leading and trailing \b to keywords that start or end with word characters.
2017-10-22 05:24:32 +00:00
Glitch::KeywordMute.create!(account: alice, keyword: '(hot take)')
Thread scopes through #matches?. #454. Also add an apply_to_mentions attribute on Glitch::KeywordMute, which is used to calculate scope. Next up: additions to the test suite to demonstrate how scoping works.
2018-06-04 00:41:54 +00:00
expect(matcher.matches?('(hot take)', Unscoped)).to be_truthy
Rework KeywordMute interface to use a matcher object; spec out matcher. #164. A matcher object that builds a match from KeywordMute data and runs it over text is, in my view, one of the easier ways to write examples for this sort of thing.
2017-10-15 01:36:53 +00:00
end
Escape metacharacters in non-whole-word keyword mutes. Fixes #533. Also addresses #463.
2018-06-05 07:49:28 +00:00
it 'escapes metacharacters in non-whole-word keywords' do
Glitch::KeywordMute.create!(account: alice, keyword: '(-', whole_word: false)
expect(matcher.matches?('bad (-)')).to be_truthy
end
Rework KeywordMute interface to use a matcher object; spec out matcher. #164. A matcher object that builds a match from KeywordMute data and runs it over text is, in my view, one of the easier ways to write examples for this sort of thing.
2017-10-15 01:36:53 +00:00
it 'uses case-folding rules appropriate for more than just English' do
Move KeywordMute into Glitch namespace. There are two motivations for this: 1. It looks like we're going to add other features that require server-side storage (e.g. user notes). 2. Namespacing glitchsoc modifications is a good idea anyway: even if we do not end up doing (1), if upstream introduces a keyword-mute feature that also uses a "KeywordMute" model, we can avoid some merge conflicts this way and work on the more interesting task of choosing which implementation to use.
2017-10-21 19:47:17 +00:00
Glitch::KeywordMute.create!(account: alice, keyword: 'großeltern')
Rework KeywordMute interface to use a matcher object; spec out matcher. #164. A matcher object that builds a match from KeywordMute data and runs it over text is, in my view, one of the easier ways to write examples for this sort of thing.
2017-10-15 01:36:53 +00:00
Thread scopes through #matches?. #454. Also add an apply_to_mentions attribute on Glitch::KeywordMute, which is used to calculate scope. Next up: additions to the test suite to demonstrate how scoping works.
2018-06-04 00:41:54 +00:00
expect(matcher.matches?('besuch der grosseltern', Unscoped)).to be_truthy
Rework KeywordMute interface to use a matcher object; spec out matcher. #164. A matcher object that builds a match from KeywordMute data and runs it over text is, in my view, one of the easier ways to write examples for this sort of thing.
2017-10-15 01:36:53 +00:00
end
it 'matches keywords that are composed of multiple words' do
Move KeywordMute into Glitch namespace. There are two motivations for this: 1. It looks like we're going to add other features that require server-side storage (e.g. user notes). 2. Namespacing glitchsoc modifications is a good idea anyway: even if we do not end up doing (1), if upstream introduces a keyword-mute feature that also uses a "KeywordMute" model, we can avoid some merge conflicts this way and work on the more interesting task of choosing which implementation to use.
2017-10-21 19:47:17 +00:00
Glitch::KeywordMute.create!(account: alice, keyword: 'a shiitake')
Spec out KeywordMute interface. #164.
2017-10-14 07:28:20 +00:00
Thread scopes through #matches?. #454. Also add an apply_to_mentions attribute on Glitch::KeywordMute, which is used to calculate scope. Next up: additions to the test suite to demonstrate how scoping works.
2018-06-04 00:41:54 +00:00
expect(matcher.matches?('This is a shiitake', Unscoped)).to be_truthy
expect(matcher.matches?('This is shiitake', Unscoped)).to_not be_truthy
Rework KeywordMute interface to use a matcher object; spec out matcher. #164. A matcher object that builds a match from KeywordMute data and runs it over text is, in my view, one of the easier ways to write examples for this sort of thing.
2017-10-15 01:36:53 +00:00
end
Spec out KeywordMute interface. #164.
2017-10-14 07:28:20 +00:00
end
end
Add some examples for Glitch::KeywordMute::TagMatcher. #208.
2017-11-16 05:31:49 +00:00
describe '.tag_matcher_for' do
let(:matcher) { Glitch::KeywordMute.tag_matcher_for(alice.id) }
let(:status) { Fabricate(:status) }
describe 'with no mutes' do
before do
Glitch::KeywordMute.delete_all
end
it 'does not match' do
status.tags << Fabricate(:tag, name: 'xyzzy')
Thread scopes through #matches?. #454. Also add an apply_to_mentions attribute on Glitch::KeywordMute, which is used to calculate scope. Next up: additions to the test suite to demonstrate how scoping works.
2018-06-04 00:41:54 +00:00
expect(matcher.matches?(status.tags, Unscoped)).to be false
Add some examples for Glitch::KeywordMute::TagMatcher. #208.
2017-11-16 05:31:49 +00:00
end
end
describe 'with mutes' do
it 'does not match keywords set by a different account' do
status.tags << Fabricate(:tag, name: 'xyzzy')
Glitch::KeywordMute.create!(account: bob, keyword: 'take')
Thread scopes through #matches?. #454. Also add an apply_to_mentions attribute on Glitch::KeywordMute, which is used to calculate scope. Next up: additions to the test suite to demonstrate how scoping works.
2018-06-04 00:41:54 +00:00
expect(matcher.matches?(status.tags, Unscoped)).to be false
Add some examples for Glitch::KeywordMute::TagMatcher. #208.
2017-11-16 05:31:49 +00:00
end
it 'matches #xyzzy when given the mute "#xyzzy"' do
status.tags << Fabricate(:tag, name: 'xyzzy')
Glitch::KeywordMute.create!(account: alice, keyword: '#xyzzy')
Thread scopes through #matches?. #454. Also add an apply_to_mentions attribute on Glitch::KeywordMute, which is used to calculate scope. Next up: additions to the test suite to demonstrate how scoping works.
2018-06-04 00:41:54 +00:00
expect(matcher.matches?(status.tags, Unscoped)).to be true
Add some examples for Glitch::KeywordMute::TagMatcher. #208.
2017-11-16 05:31:49 +00:00
end
it 'matches #thingiverse when given the non-whole-word mute "#thing"' do
status.tags << Fabricate(:tag, name: 'thingiverse')
Glitch::KeywordMute.create!(account: alice, keyword: '#thing', whole_word: false)
Thread scopes through #matches?. #454. Also add an apply_to_mentions attribute on Glitch::KeywordMute, which is used to calculate scope. Next up: additions to the test suite to demonstrate how scoping works.
2018-06-04 00:41:54 +00:00
expect(matcher.matches?(status.tags, Unscoped)).to be true
Add some examples for Glitch::KeywordMute::TagMatcher. #208.
2017-11-16 05:31:49 +00:00
end
it 'matches #hashtag when given the mute "##hashtag""' do
status.tags << Fabricate(:tag, name: 'hashtag')
Glitch::KeywordMute.create!(account: alice, keyword: '##hashtag')
Thread scopes through #matches?. #454. Also add an apply_to_mentions attribute on Glitch::KeywordMute, which is used to calculate scope. Next up: additions to the test suite to demonstrate how scoping works.
2018-06-04 00:41:54 +00:00
expect(matcher.matches?(status.tags, Unscoped)).to be true
Add some examples for Glitch::KeywordMute::TagMatcher. #208.
2017-11-16 05:31:49 +00:00
end
it 'matches #oatmeal when given the non-whole-word mute "oat"' do
status.tags << Fabricate(:tag, name: 'oatmeal')
Glitch::KeywordMute.create!(account: alice, keyword: 'oat', whole_word: false)
Thread scopes through #matches?. #454. Also add an apply_to_mentions attribute on Glitch::KeywordMute, which is used to calculate scope. Next up: additions to the test suite to demonstrate how scoping works.
2018-06-04 00:41:54 +00:00
expect(matcher.matches?(status.tags, Unscoped)).to be true
Add some examples for Glitch::KeywordMute::TagMatcher. #208.
2017-11-16 05:31:49 +00:00
end
it 'does not match #oatmeal when given the mute "#oat"' do
status.tags << Fabricate(:tag, name: 'oatmeal')
Glitch::KeywordMute.create!(account: alice, keyword: 'oat')
Thread scopes through #matches?. #454. Also add an apply_to_mentions attribute on Glitch::KeywordMute, which is used to calculate scope. Next up: additions to the test suite to demonstrate how scoping works.
2018-06-04 00:41:54 +00:00
expect(matcher.matches?(status.tags, Unscoped)).to be false
Add some examples for Glitch::KeywordMute::TagMatcher. #208.
2017-11-16 05:31:49 +00:00
end
end
end
Add KeywordMute model. Gist of the proposed keyword mute implementation: Keyword mutes are represented server-side as one keyword per record. For each account, there exists a keyword regex that is generated as one big alternation of all keywords. This regex is cached (in Redis, I guess) so we can quickly get it when filtering in FeedManager.
2017-10-09 22:28:28 +00:00
end
Reference in a new issue Copy permalink