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
Fixes#1393
The objects returned by `new Notification()` have a `.close()` method.
So we can just keep a list of notifications that have been sent, and
close them when that message has been read.
Conflicts:
internal_packages/unread-notifications/lib/main.es6
* Remove double negative from test label
It always takes me a second to read a double negative, and be sure I
understood correctly. It's also particularly troublesome for non-native
English speakers.
* Change pending unread notification stack to be a queue
Consider the case where a user launches N1, and has 3 unreads since
their last launch. Additionally, after N1 has launched, they begin
receiving a new mail every 2 seconds.
Current behavior would be a notification for 1 of the 3 unread emails,
then every 2 seconds a notification for the most recently received mail.
They would only finally receive notifications for the other 2 original
messages once they stopped getting new mail.
Summary: Replaces `new Notification`-based HTML5 notifications with system native notifications on Mac OS X. This allows us to implement the "Reply" button in the notifications. This will also serve as the hook for native Windows notifications, which are unsupported in Chromium.
Test Plan: Run tests
Reviewers: evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D2199
Summary:
This started as a fix to https://sentry.nylas.com/sentry/edgehill/group/2970/, which was caused by `threads[msg.threadId]?.categoryNamed('inbox') isnt null`, because `undefined isnt null`.
Then I realized that we batch "incoming" messages and threads arbitrarily, and the reason this happened is because the thread and message were split into different delta updates. Previously, notifications would just have been skipped.
Now we call `_onNewMessagesMissingThreads` when threads cannot be found for new messages, and then try to find the threads again in 10 seconds. If we can find them, we simulate a delta call and run them back through the processor. It would have been simpler to call `_onNewMailReceived` again directly, but I want to be 100% sure we never create infinite loops.
Test Plan: Run new tests
Reviewers: evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D2188
Summary:
This diff replaces the Namespace object with the Account object, and changes all references to namespace_id => account_id, etc. The endpoints are now `/threads` instead of `/n/<id>/threads`.
This diff also adds preliminary support for multiple accounts. When you log in, we now log you in to all the attached accounts on edgehill server. From the preferences panel, you can auth with / unlink additional accounts. Shockingly, this all seems to pretty much work.
When replying to a thread, you cannot switch from addresses. However, when creating a new message in a popout composer, you can change the from address and the SaveDraftTask will delete/re-root the draft on the new account.
Search bar doesn't need to do full refresh on clear if it never committed
Allow drafts to be switched to a different account when not in reply to an existing thread
Fix edge case where ChangeMailTask throws exception if no models are modified during performLocal
Show many dots for many accounts in long polling status bar
add/remove accounts from prefs
Spec fixes!
Test Plan: Run tests, none broken!
Reviewers: evan, dillon
Reviewed By: evan, dillon
Differential Revision: https://phab.nylas.com/D1928
Summary:
There are now two objects, Folders & Labels. These inherit from `Category`
(that's what Eben said they were using on the backend).
There are two separate tasks.
1. MoveToFolderTask
2. ApplyLabelsTask
It turns out that the semantics between the two are quite different.
The reverse operation for moving to a folder is a bit tricky.
As of 7-8-15, the Tasks are pretty much complete. I need to write tests
for them still and do some manual testing in the client.
Test Plan: Writing specs
Reviewers: bengotow
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D1724
Summary: If less than 5 new unread notifications, then show notification for each new message. Each message is separated by 1 second
Test Plan: Added test to make sure Notification is called multiple times
Reviewers: bengotow
Reviewed By: bengotow
Maniphest Tasks: T1295
Differential Revision: https://phab.nylas.com/D1744
Summary:
Features:
- ThreadListParticipants ignores drafts when computing participants, renders "Draft" label, pending design
- Put the WorkspaceStore in every window—means they all get toolbars and custom gumdrop icons on Mac OS X
Bug Fixes:
- Never display notifications for email the user just sent
- Fix obscure issue with DatabaseView trying to update metadata on items it froze. This resolves issue with names remaining bold after marking as read, drafts not appearing in message list immediately.
- When you pop out a draft, save it first and *wait* for the commit() promise to succeed.
- If you scroll very fast, you node.contentWindow can be null in eventedIframe
Other:
Make it OK to re-register the same component
Make it possible to unregister a hot window
Break the Sheet Toolbar out into it's own file to make things manageable
Replace `package.windowPropsReceived` with a store-style model where anyone can listen for changes to `windowProps`
When I put the WorkspaceStore in every window, I ran into a problem because the package was no longer rendering an instance of the Composer, it was declaring a root sheet with a composer in it. This meant that it was actually a React component that needed to listen to window props, not the package itself.
`atom` is already an event emitter, so I added a `onWindowPropsReceived` hook so that components can listen to window props as if they were listening to a store. I think this might be more flexible than only broadcasting the props change event to packages.
Test Plan: Run tests
Reviewers: evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D1592
Summary:
Fixes: T1334
remove final InboxApp references
move out all underscore-plus methods
Mass find and replace of underscore-plus
sed -i '' -- 's/underscore-plus/underscore/g' **/*.coffee
sed -i '' -- 's/underscore-plus/underscore/g' **/*.cjsx
Test Plan: edgehill --test
Reviewers: bengotow
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D1534
Summary:
#### WIP! ####
This is making it all work with the association endpoint, putting
together the Salesforce Sidebar interfaces, and getting the nested
creators/updaters working.
I still need to do a bunch of UI work and actually debug the whole
workflow still
---
rename SalesforceContactStore to SalesforceSearchStore
rename SalesforceContact to SalesforceSearchResult
salesforce sidebar changes
salesforce association picker
object form store fixes
figuring out newFormItem instigators
Make SalesforceObjectFormStore declarative off SalesforceObjectStore
Make action basd handlers for SalesforceObjectStore
sidebar store create and associate
salesforce sidebar and picker fixes
association works and displays on sidebar
salesforce object form fixes
object form fixes
fix salesforce updating
Test Plan: TODO
Reviewers: bengotow
Reviewed By: bengotow
Differential Revision: https://review.inboxapp.com/D1440
Summary: When we get unread messages, grab their threads and then make sure they're in the inbox before notifying.
Test Plan: See updated specs!
Reviewers: evan
Reviewed By: evan
Differential Revision: https://review.inboxapp.com/D1361
Summary:
Eventually, notification stuff should be moved out of InboxAPI into a separate package, and we should have some documented way of watching for "new" things. (Right now it'd be a bit hard to do on the database store...)
Additional fixes:
- AddRemoveTagsTask now optimistically updates the version. Before it would get the new version from the API response. This was bad because it could still cause local changes to be overwritten if you were changing tags really fast.
- AddRemoveTagsTask now takes a threadId, not a thread for consistency with all the rest of our Tasks
Test Plan: Run tests
Reviewers: evan
Reviewed By: evan
Differential Revision: https://review.inboxapp.com/D1214
