Summary: Adds a new button in auth for native Office 365 support
Test Plan: manual
Reviewers: jackie, halla, mark, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3532
Summary:
The composer wasn't popping out correctly because the session's draft
was still null. This diff switches to using sessionForClientId(),
even if the session already exists in _draftSessions, because
sessionForClientId() won't create a new session if it doesn't need
to, and will always return a promise that resolves once the session
gets its draft. This promise will resolve immediately if the session
already has a draft.
Test Plan: tested locally
Reviewers: evan, juan
Reviewed By: juan
Subscribers: juan, spang
Differential Revision: https://phab.nylas.com/D3531
Summary:
Since we changed the way we mark up plaintext emails to wrap them in <pre>
tags, the quote stripper has been failing to restore bodies in the cases
where a plaintext email starts with an inline quote (and thus the whole
contents of the <pre> tag is detected as a quote string).
This diff also fixes the HTML sanitizer to not strip off our custom
"nylas-plaintext" class, which isn't currently used for anything but
allows us to definitively know which tags we added on for marking up
plaintext. Might be useful at some point!
Test Plan: unit test included, manual inspection of message display
Reviewers: evan
Differential Revision: https://phab.nylas.com/D3519
Summary:
I upgraded bluebird because I thought there was some missing dependency
issue when I booted K2. It actually turned out that the issue was missing
`striptags` require in the K2 local-sync package json and had nothing to
do with Bluebird.
But since were here and about to QA I figured I might as well bump it
anyway. Especially since I'll need it later to better diagnose async
tests.
I carefully went through the 3.0 changelog and believe I fixed the
outstanding issues
Test Plan: manual
Reviewers: juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3523
Summary:
With the fix to the delta-processor, this is all that's needed to
get mail rules working! Some places were trying to use 'accountId'
to access an account object's id, but it needs to be 'id' instead.
Test Plan: tested locally
Reviewers: jackie
Reviewed By: jackie
Differential Revision: https://phab.nylas.com/D3525
Summary:
We were returning an array of arrays, when really we wanted an object
of arrays keyed by model type. This also involved removing an implementation
of mapObject that was overwriting underscore's implementation of it.
Test Plan: local, having others try it.
Reviewers: juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3509
Summary:
This commit fixes processing deltas for `ProviderSyncbackRequests` and
resolution of the `SyncbackTaskAPIRequest`
Specifically:
- Fix and update field definitions for `ProviderSyncbackRequest`
- Correctly parse the error attached to any `ProviderSyncbackRequest`
- Correctly process deltas for `ProviderSyncbackRequests` inside the
delta-processor
- Fix any tasks that used `SyncbackTaskAPIRequest`, and update send to use those
Depends on D3510
Test Plan: Todo/Manual
Reviewers: jackie, halla, evan
Reviewed By: halla, evan
Differential Revision: https://phab.nylas.com/D3511
Summary:
Addresses T7275
Previously, we kept track of the sync status of each API model, and the progress
we'd made syncing all available models (e.g. all threads, messages, events, etc)
Given K2's set up, we are now keeping track of sync status per folder, i.e. what
percent of the folder's messages we've synced. This status is now reported from K2
to N1 via folder object deltas, and this commit rewrites the
NylasSyncStatusStore (in ES6) to reflect that.
The new Store keeps the sync state per account, which is the merged state of
per folder sync state, and delta connections state.
We also got rid of `CategoryStore.whenCategoriesReady` in favor of
`whenCategoryListSynced`, which is derived from the fact hat as long as we've
started syncing one folder, we've already synced the entire list of of folders/labels.
There are a couple of TODOs to be addressed in upcoming diffs:
- T7329 Restore the sidebar component to show sync progress, which was previously removed
- T7330 Figure out how to report sync progress per label, specifically, we are interested in knowing how much of the inbox we've synced, which is a label in Gmail. (This might be a non-issue if we sync the inbox very fast, first)
Depends on D3514
Test Plan: Manual
Reviewers: mark, evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D3515
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
Our HTML sanitizer that we run bodies through before rendering
strips off this class, so it's not currently working with the
class set. Since this CSS is specific to the email frame, should
be OK to have no class at all.
Summary:
Pass in more details on sending errors, so that they can be viewed
more easily by clicking "Show Details", rather than having to check
the worker window console.
Test Plan: tested locally
Reviewers: evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D3505
Summary:
feat(bootstrap): automatically init submodule if able
fix(bootstrap): symlink arc instead of copy
Test Plan: test
Reviewers: juan
Differential Revision: https://phab.nylas.com/D3494
This commit adds a new request type: SyncbackTaskAPIRequest.
This API request is meant to be used for requests that create a
SyncbackRequest inside K2.
When the initial http request succeeds, this means that the task was created,
but we cant tell if the task actually succeeded or failed until some time in
the future when its processed inside K2's sync loop.
A SyncbackTaskAPIRequest will only resolve until the underlying K2 syncback
request has actually succeeded, or reject when it fails, by listening to
deltas for ProviderSyncbackRequests
THis commit also updates N1's tasks that create syncback requests to use
this new type of request
Since local-sync can access the same targetPaths as N1, there's
no need to create actual File instances anymore. Pass just the
upload data in the API request, and remove SyncbackDraftFilesTask
since it is no longer necessary.
Summary:
We now use <pre> tags to preserve whitespace in plaintext emails,
but it's annoying when there are long lines that force a scroll
bar. Wrap them instead.
Test Plan:
looked at some emails. Not sure this isn't going to break something
weird---is <pre> used in anything else?
Reviewers: bengotow
Differential Revision: https://phab.nylas.com/D3484
When running syncback requests, if a task is meant to change the UID of
a message (e.g. move it to a new folder), that task should be run after
other tasks that don't affect the UID. Otherwise, when trying to run the
other tasks, they would reference a UID that is no longer valid.
This commit will make sure that we run any tasks that will change message uids last,
/and/ make sure that we don't run more than 1 task that will affect the uids of
the same messages in a row (i.e. without running a sync loop in between)
This commit will correctly keep track of folder and label ids when
creating them from N1.
Previously, when we sent the request to create a folder or label to our api,
we would immediately get back a serverId because it was created optimistically
in the back end— given that K2 is strictly non-optimistic, we won’t have a serverId
until some undetermined time in the future, and we need to somehow reference
the object that /was/ optimistically created in N1 to update the ui when
we do get the server id.
Since we can deterministically generate ids for folders and labels,
we "guess" what its going to be, and include it in the props of the syncback request
returned to N1. This is the simplest solution to get thing working
correctly right now, but we’ll need to revisit this in the future for
other types of objects (drafts, contacts, events), and revisit how we
will manage optimistic updates in N1 when we merge the 2 codebases
with K2 (given that K2 was designed to be non-optimisitc).
