Summary:
Previously, we have saved drafts back to the user's provider through the sync engine. There are a handful of very serious edge case issues we're working to solve that are creating a bad user experience. (#933, #1175, #1504, #1237)
For now, we're going to change the behavior of N1 to mitagate these issues.
- If you create a draft in N1, we will not sync it to other mail clients while you're working on it.
- If you enable send later, we'll start syncing the draft to the server as before.
- If you created the draft in another client, we'll sync the draft to the server as before.
Fix specs
Test Plan: Run specs
Reviewers: evan, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D2706
Summary:
WIP. I added a collection index to make displaying the threads of a
currently selected participant on the sidebar easy and fast.
The problem is that the `participants` of a thread, while a collection of
`Contact` objects, have no "ids" for those contact objects.
One idea was to create the join table but access contacts by email instead
of id. This required a minor change to the way the data is entered in the
join table.
This means the sidebar can now simply do:
`DatabaseStore.findAll(Thread).where(Thread.attributes.participants.contains('foo@bar.com'))`
While I didn't for this initial test, we could also/instead create the
`Message-Contact` join table. The trick about a Message-Contact table is
that I believe we'd have to create additional columns further specifying
which field we're interested in.
The following two queries:
`DatabaseStore.findAll(Message).where(Message.attributes.to.contains('foo@bar.com'))`
`DatabaseStore.findAll(Message).where(Message.attributes.from.contains('foo@bar.com'))`
would require additional columns in the `Message-Contact` join table
because currently the only columns are `id` and `value`.
In the case of the sidebar use case, I think the Thread participants is
what you want to see anyway.
Unfortunately an email-centric scheme can't distinguish between
`noreply@phab.com <Evan>` and `noreply@phab.com <Juan>`. I actually think
this may be a good thing since I think most people think in terms of email
address as the unique key anyway and for the use case of showing related
emails in the sidebar I'd rather overshow than undershow.
This solution seems to be working pretty well in initial testing, but I
want to see if you guys can think of anything this may subtly screw up
down the line, or if you can think of a simpler way to do this.
Test Plan: todo
Reviewers: juan, bengotow
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D2687
Summary:
- FixedPopover now correctly adjusts itself when overflowing outside
window, in all directions
- Updates styles
- Adds specs
- Remove Popover and popover.less, and refactor all code that used it in
favor of the new FixedPopover
Test Plan: Unit tests
Reviewers: drew, evan, bengotow
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D2697
Summary: Themes can now be uninstalled by clicking a button in the theme picker, instead of going to `~/.nylas/packages` to delete the directory.
Test Plan: Tested locally.
Reviewers: evan, bengotow
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D2700
Summary:
Changes the delta code to handle new deltas on the Account object,
which are triggered by changes in sync state indicating various backend
issues. Saves the sync state in a new field on the Account object, which
is persisited in `config.cson`.
Includes several UI changes to display more information when an account has
backend sync issues. Adds better messages and new actions the user can take
based on the type of sync issue.
Additionally, fixes bug in action bridge that was preventing multi-arg global
actions from working.
Test Plan:
Manual, by testing different sync state values and triggering deltas from the
backend
Reviewers: juan, evan, bengotow
Reviewed By: evan, bengotow
Subscribers: khamidou
Differential Revision: https://phab.nylas.com/D2696
Summary:
Add specs to test the components of open tracking and link
tracking. Notably does not test the overall functionality, which
still needs specs.
Test Plan: adds specs
Reviewers: juan, evan, bengotow
Reviewed By: evan, bengotow
Differential Revision: https://phab.nylas.com/D2667
Summary:
Fixes an issue with sending where certain conditions could result in a
duplicated message.
Fixes task dependency logic for draft syncback and send. Changes `createdAt`
on tasks to instead be `sequentialId`, assigned when the task is queued, to
track order of enqueueing. Renames `isDependentTask` => `isDependentOnTask`
and adds comments for clarity.
Test Plan:
Specs updated. Might be good to add some later to test this particular
edge case.
Reviewers: juan, evan, bengotow
Reviewed By: evan, bengotow
Differential Revision: https://phab.nylas.com/D2681
