Mailspring/spec/mail-rules-processor-spec.coffee

161 lines
5.2 KiB
CoffeeScript
Raw Normal View History

feat(mail-rules): Per-account mail rules filter incoming, existing mail Summary: Originally, this was going to be a totally independent package, but I wasn't able to isolate the functionality and get it tied in to the delta-stream consumption. Here's how it currently works: - The preferences package has a new tab which allows you to edit mail filters. Filters are saved in a new core store, and a new stock component (ScenarioEditor) renders the editor. The editor takes a set of templates that define a value space, and outputs a valid set of values. - A new MailFilterProcessor takes messages and creates tasks to apply the actions from the MailFiltersStore. - The worker-sync package now uses the MailFilterProcessor to apply filters /before/ it calls didPassivelyReceiveNewModels, so filtrs are applied before any notifications are created. - A new task, ReprocessMailFiltersTask allows you to run filters on all of your existing mail. It leverages the existing TaskQueue architecture to: a) resume where it left off if you quit midway, b) be queryable (for status) from all windows and c) cancelable. The TaskQueue is a bit strange because it runs performLocal and performRemote very differently, and I had to use `performRemote`. (todo refactor soon.) This diff also changes the EditableList a bit to behave like a controlled component and render focused / unfocused states. Test Plan: Run tests, only for actual filter processing atm. Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2379
2015-12-23 15:19:32 +08:00
_ = require 'underscore'
{Message,
Contact,
Thread,
feat(mail-rules): Per-account mail rules filter incoming, existing mail Summary: Originally, this was going to be a totally independent package, but I wasn't able to isolate the functionality and get it tied in to the delta-stream consumption. Here's how it currently works: - The preferences package has a new tab which allows you to edit mail filters. Filters are saved in a new core store, and a new stock component (ScenarioEditor) renders the editor. The editor takes a set of templates that define a value space, and outputs a valid set of values. - A new MailFilterProcessor takes messages and creates tasks to apply the actions from the MailFiltersStore. - The worker-sync package now uses the MailFilterProcessor to apply filters /before/ it calls didPassivelyReceiveNewModels, so filtrs are applied before any notifications are created. - A new task, ReprocessMailFiltersTask allows you to run filters on all of your existing mail. It leverages the existing TaskQueue architecture to: a) resume where it left off if you quit midway, b) be queryable (for status) from all windows and c) cancelable. The TaskQueue is a bit strange because it runs performLocal and performRemote very differently, and I had to use `performRemote`. (todo refactor soon.) This diff also changes the EditableList a bit to behave like a controlled component and render focused / unfocused states. Test Plan: Run tests, only for actual filter processing atm. Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2379
2015-12-23 15:19:32 +08:00
File,
DatabaseStore,
feat(mail-rules): Per-account mail rules filter incoming, existing mail Summary: Originally, this was going to be a totally independent package, but I wasn't able to isolate the functionality and get it tied in to the delta-stream consumption. Here's how it currently works: - The preferences package has a new tab which allows you to edit mail filters. Filters are saved in a new core store, and a new stock component (ScenarioEditor) renders the editor. The editor takes a set of templates that define a value space, and outputs a valid set of values. - A new MailFilterProcessor takes messages and creates tasks to apply the actions from the MailFiltersStore. - The worker-sync package now uses the MailFilterProcessor to apply filters /before/ it calls didPassivelyReceiveNewModels, so filtrs are applied before any notifications are created. - A new task, ReprocessMailFiltersTask allows you to run filters on all of your existing mail. It leverages the existing TaskQueue architecture to: a) resume where it left off if you quit midway, b) be queryable (for status) from all windows and c) cancelable. The TaskQueue is a bit strange because it runs performLocal and performRemote very differently, and I had to use `performRemote`. (todo refactor soon.) This diff also changes the EditableList a bit to behave like a controlled component and render focused / unfocused states. Test Plan: Run tests, only for actual filter processing atm. Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2379
2015-12-23 15:19:32 +08:00
TaskQueueStatusStore,
Actions} = require 'nylas-exports'
MailRulesProcessor = require '../src/mail-rules-processor'
Tests = [{
rule: {
id: "local-ac7f1671-ba03",
name: "conditionMode Any, contains, equals",
conditions: [
{
templateKey: "from"
comparatorKey: "contains"
value: "@nylas.com"
},
{
templateKey: "from"
comparatorKey: "equals"
value: "oldschool@nilas.com"
}
],
conditionMode: "any",
actions: [
{
templateKey: "markAsRead"
}
],
accountId: "b5djvgcuhj6i3x8nm53d0vnjm"
},
good: [
new Message(from: [new Contact(email:'ben@nylas.com')])
new Message(from: [new Contact(email:'ben@nylas.com.jp')])
new Message(from: [new Contact(email:'oldschool@nilas.com')])
]
bad: [
new Message(from: [new Contact(email:'ben@other.com')])
new Message(from: [new Contact(email:'ben@nilas.com')])
new Message(from: [new Contact(email:'twooldschool@nilas.com')])
]
},{
rule: {
id: "local-ac7f1671-ba03",
name: "conditionMode all, ends with, begins with",
conditions: [
{
templateKey: "cc"
comparatorKey: "endsWith"
value: ".com"
},
{
templateKey: "subject"
comparatorKey: "beginsWith"
value: "[TEST] "
}
],
conditionMode: "any",
actions: [
{
templateKey: "applyLabel"
value: "51a0hb8d6l78mmhy19ffx4txs"
}
],
accountId: "b5djvgcuhj6i3x8nm53d0vnjm"
},
good: [
new Message(cc: [new Contact(email:'ben@nylas.org')], subject: '[TEST] ABCD')
new Message(cc: [new Contact(email:'ben@nylas.org')], subject: '[test] ABCD')
new Message(cc: [new Contact(email:'ben@nylas.com')], subject: 'Whatever')
new Message(cc: [new Contact(email:'a@test.com')], subject: 'Whatever')
new Message(cc: [new Contact(email:'a@hasacom.com')], subject: '[test] Whatever')
new Message(cc: [new Contact(email:'a@hasacom.org'), new Contact(email:'b@nylas.com')], subject: 'Whatever')
]
bad: [
new Message(cc: [new Contact(email:'a@hasacom.org')], subject: 'Whatever')
new Message(cc: [new Contact(email:'a@hasacom.org')], subject: '[test]Whatever')
new Message(cc: [new Contact(email:'a.com@hasacom.org')], subject: 'Whatever [test] ')
]
},{
rule: {
id: "local-ac7f1671-ba03",
name: "Any attachment name endsWith, anyRecipient equals",
conditions: [
{
templateKey: "anyAttachmentName"
comparatorKey: "endsWith"
value: ".pdf"
},
{
templateKey: "anyRecipient"
comparatorKey: "equals"
value: "files@nylas.com"
}
],
conditionMode: "any",
actions: [
{
templateKey: "changeFolder"
value: "51a0hb8d6l78mmhy19ffx4txs"
}
],
accountId: "b5djvgcuhj6i3x8nm53d0vnjm"
},
good: [
new Message(files: [new File(filename: 'bengotow.pdf')], to: [new Contact(email:'ben@nylas.org')])
new Message(to: [new Contact(email:'files@nylas.com')])
new Message(to: [new Contact(email:'ben@nylas.com')], cc: [new Contact(email:'ben@test.com'), new Contact(email:'files@nylas.com')])
],
bad: [
new Message(to: [new Contact(email:'ben@nylas.org')])
new Message(files: [new File(filename: 'bengotow.pdfz')], to: [new Contact(email:'ben@nylas.org')])
new Message(files: [new File(filename: 'bengotowpdf')], to: [new Contact(email:'ben@nylas.org')])
new Message(to: [new Contact(email:'afiles@nylas.com')])
new Message(to: [new Contact(email:'files@nylas.coma')])
]
}]
fix(spec): add support for async specs and disable misbehaving ones More spec fixes replace process.nextTick with setTimeout(fn, 0) for specs Also added an unspy in the afterEach Temporarily disable specs fix(spec): start fixing specs Summary: This is the WIP fix to our spec runner. Several tests have been completely commented out that will require substantially more work to fix. These have been added to our sprint backlog. Other tests have been fixed to update to new APIs or to deal with genuine bugs that were introduced without our knowing! The most common non-trivial change relates to observing the `NylasAPI` and `NylasAPIRequest`. We used to observe the arguments to `makeRequest`. Unfortunately `NylasAPIRequest.run` is argumentless. Instead you can do: `NylasAPIRequest.prototype.run.mostRecentCall.object.options` to get the `options` passed into the object. the `.object` property grabs the context of the spy when it was last called. Fixing these tests uncovered several concerning issues with our test runner. I spent a while tracking down why our participant-text-field-spec was failling every so often. I chose that spec because it was the first spec to likely fail, thereby requiring looking at the least number of preceding files. I tried binary searching, turning on and off, several files beforehand only to realize that the failure rate was not determined by a particular preceding test, but rather the existing and quantity of preceding tests, AND the number of console.log statements I had. There is some processor-dependent race condition going on that needs further investigation. I also discovered an issue with the file-download-spec. We were getting errors about it accessing a file, which was very suspicious given the code stubs out all fs access. This was caused due to a spec that called an async function outside ot a `waitsForPromise` block or a `waitsFor` block. The test completed, the spies were cleaned up, but the downstream async chain was still running. By the time the async chain finished the runner was already working on the next spec and the spies had been restored (causing the real fs access to run). Juan had an idea to kill the specs once one fails to prevent cascading failures. I'll implement this in the next diff update Test Plan: npm test Reviewers: juan, halla, jackie Differential Revision: https://phab.nylas.com/D3501 Disable other specs Disable more broken specs All specs turned off till passing state Use async-safe versions of spec functions Add async test spec Remove unused package code Remove canary spec
2016-12-13 04:12:20 +08:00
xdescribe "MailRulesProcessor", ->
feat(mail-rules): Per-account mail rules filter incoming, existing mail Summary: Originally, this was going to be a totally independent package, but I wasn't able to isolate the functionality and get it tied in to the delta-stream consumption. Here's how it currently works: - The preferences package has a new tab which allows you to edit mail filters. Filters are saved in a new core store, and a new stock component (ScenarioEditor) renders the editor. The editor takes a set of templates that define a value space, and outputs a valid set of values. - A new MailFilterProcessor takes messages and creates tasks to apply the actions from the MailFiltersStore. - The worker-sync package now uses the MailFilterProcessor to apply filters /before/ it calls didPassivelyReceiveNewModels, so filtrs are applied before any notifications are created. - A new task, ReprocessMailFiltersTask allows you to run filters on all of your existing mail. It leverages the existing TaskQueue architecture to: a) resume where it left off if you quit midway, b) be queryable (for status) from all windows and c) cancelable. The TaskQueue is a bit strange because it runs performLocal and performRemote very differently, and I had to use `performRemote`. (todo refactor soon.) This diff also changes the EditableList a bit to behave like a controlled component and render focused / unfocused states. Test Plan: Run tests, only for actual filter processing atm. Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2379
2015-12-23 15:19:32 +08:00
describe "_checkRuleForMessage", ->
it "should correctly filter sample messages", ->
Tests.forEach ({rule, good, bad}) =>
for message, idx in good
message.accountId = rule.accountId
if MailRulesProcessor._checkRuleForMessage(rule, message) isnt true
expect("#{idx} (#{rule.name})").toBe(true)
for message, idx in bad
message.accountId = rule.accountId
if MailRulesProcessor._checkRuleForMessage(rule, message) isnt false
expect("#{idx} (#{rule.name})").toBe(false)
it "should check the account id", ->
{rule, good, bad} = Tests[0]
message = good[0]
message.accountId = 'not the same!'
expect(MailRulesProcessor._checkRuleForMessage(rule, message)).toBe(false)
describe "_applyRuleToMessage", ->
it "should queue tasks for messages", ->
spyOn(TaskQueueStatusStore, 'waitForPerformLocal')
spyOn(Actions, 'queueTask')
spyOn(DatabaseStore, 'findBy').andReturn(Promise.resolve({}))
feat(mail-rules): Per-account mail rules filter incoming, existing mail Summary: Originally, this was going to be a totally independent package, but I wasn't able to isolate the functionality and get it tied in to the delta-stream consumption. Here's how it currently works: - The preferences package has a new tab which allows you to edit mail filters. Filters are saved in a new core store, and a new stock component (ScenarioEditor) renders the editor. The editor takes a set of templates that define a value space, and outputs a valid set of values. - A new MailFilterProcessor takes messages and creates tasks to apply the actions from the MailFiltersStore. - The worker-sync package now uses the MailFilterProcessor to apply filters /before/ it calls didPassivelyReceiveNewModels, so filtrs are applied before any notifications are created. - A new task, ReprocessMailFiltersTask allows you to run filters on all of your existing mail. It leverages the existing TaskQueue architecture to: a) resume where it left off if you quit midway, b) be queryable (for status) from all windows and c) cancelable. The TaskQueue is a bit strange because it runs performLocal and performRemote very differently, and I had to use `performRemote`. (todo refactor soon.) This diff also changes the EditableList a bit to behave like a controlled component and render focused / unfocused states. Test Plan: Run tests, only for actual filter processing atm. Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2379
2015-12-23 15:19:32 +08:00
Tests.forEach ({rule}) =>
TaskQueueStatusStore.waitForPerformLocal.reset()
Actions.queueTask.reset()
message = new Message({accountId: rule.accountId})
thread = new Thread({accountId: rule.accountId})
response = MailRulesProcessor._applyRuleToMessage(rule, message, thread)
feat(mail-rules): Per-account mail rules filter incoming, existing mail Summary: Originally, this was going to be a totally independent package, but I wasn't able to isolate the functionality and get it tied in to the delta-stream consumption. Here's how it currently works: - The preferences package has a new tab which allows you to edit mail filters. Filters are saved in a new core store, and a new stock component (ScenarioEditor) renders the editor. The editor takes a set of templates that define a value space, and outputs a valid set of values. - A new MailFilterProcessor takes messages and creates tasks to apply the actions from the MailFiltersStore. - The worker-sync package now uses the MailFilterProcessor to apply filters /before/ it calls didPassivelyReceiveNewModels, so filtrs are applied before any notifications are created. - A new task, ReprocessMailFiltersTask allows you to run filters on all of your existing mail. It leverages the existing TaskQueue architecture to: a) resume where it left off if you quit midway, b) be queryable (for status) from all windows and c) cancelable. The TaskQueue is a bit strange because it runs performLocal and performRemote very differently, and I had to use `performRemote`. (todo refactor soon.) This diff also changes the EditableList a bit to behave like a controlled component and render focused / unfocused states. Test Plan: Run tests, only for actual filter processing atm. Reviewers: juan, evan Reviewed By: evan Differential Revision: https://phab.nylas.com/D2379
2015-12-23 15:19:32 +08:00
expect(response instanceof Promise).toBe(true)
waitsForPromise =>
response.then =>
expect(TaskQueueStatusStore.waitForPerformLocal).toHaveBeenCalled()
expect(Actions.queueTask).toHaveBeenCalled()