Summary:
refactor(test): Fix file paths in message item body tests to be prepended with file://
Some inline images were not rendering as seen on (#621). The images were being correctly added to the
downloads folder, however, their path was being prepended with an unrelated base url. I hardcoded
file:// into the image paths so that they would always point to the local downloads folder.
Test Plan: Ran the specific tests for message item body and message item. Also checked in my email.
Reviewers: juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3105
Summary: Some emails were having their body height set to 0 if their height was dependent upon the iframe height -- e.g. body.height equals 100% or inherit. Added a check to see if height computed to 0px and if so, set the height to auto.
Test Plan: Tested with emails on my computer
Reviewers: juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3100
Summary:
This diff introduces several updates to mail merge to improve the procedure for sending a list of drafts.
Specifically, sending mass email will now:
- Clear mail merge metadata on the drafts that will actually be sent
- Upload attached files only /once/, and reuse those files on the drafts that will actually be sent
- Minimize database writes for new drafts being created
- Will queue a SendManyDraftsTask that will subsequently queue the necessary SendDraftTasks and keep track of them, and notify of any failed tasks
TODO:
- Add state to MailMerge plugin for failed sends and ability to attempt to re send them
Test Plan: - TODO
Reviewers: evan, bengotow, jackie
Reviewed By: bengotow, jackie
Subscribers: jackie
Differential Revision: https://phab.nylas.com/D2973
Office 365 likes to format email addresses as follows:
Last Name, First Name (Some Description) <email@address.org>
This causes Contact.firstName() (and hence sometimes displayName()) to return
"Last Name," which looks a bit odd in the message/thread views.
The intent of the commit is to correctly parse these names so that (using the
above example):
- firstName = "First Name"
- lastName = "Last Name (Some Description)"
- fullName = "First Name Last Name (Some Description)"
These behavioral changes only impact names containing a ','.
I don't know that this really provides exhaustive coverage of Office 365, and
keeping the description as part of the last name is not completely guilt free,
but it's not any worse than the previous state of affairs which also has
the description in the same field but combined instead with (misplaced)
first name data.
Summary:
Keymaps & menus CSON => JSON, remove AtomKeymaps, CommandRegistry use of CSS selectors, use Mousetrap instead
Important Notes:
- The `application:` prefix is reserved for commands which are handled in the application process. Don't use it for other things. You will not receive the events in the window.
- Maintaining dynamic menus seems to come with quite an overhead, because Electron updates the entire menu every time. In the future, we'll need https://github.com/electron/electron/issues/528 to really make things nice. I will be tracking this upstream.
- The format for keyboard shortcuts has changed. `cmd-X` is now `command+shift+x`
Test Plan: Run tests
Reviewers: juan, evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D2917
Summary:
Adds a new unified "Spam" folder and a unified "Unread" view,
which shows all the messages in your inbox which are unread.
Test Plan: Run tests
Reviewers: evan, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D2901
Summary:
- Removes controlled focus in the composer!
- No React components ever perfom focus in lifecycle methods. Never again.
- A new `Utils.schedule({action, after, timeout})` helper makes it easy to say "setState or load draft, etc. and then focus"
- The DraftStore issues a focusDraft action after creating a draft, which causes the MessageList to focus and scroll to the desired composer, which itself decides which field to focus.
- The MessageList never focuses anything automatically.
- Refactors ComposerView apart — ComposerHeader handles all top fields, DraftSessionContainer handles draft session initialization and exposes props to ComposerView
- ComposerHeader now uses a KeyCommandRegion (with focusIn and focusOut) to do the expanding and collapsing of the participants fields. May rename that container very soon.
- Removes all CommandRegistry handling of tab and shift-tab. Unless you preventDefault, the browser does it's thing.
- Removes all tabIndexes greater than 1. This is an anti-pattern—assigning everything a tabIndex of 0 tells the browser to move between them based on their order in the DOM, and is almost always what you want.
- Adds "TabGroupRegion" which allows you to create a tab/shift-tabbing group, (so tabbing does not leave the active composer). Can't believe this isn't a browser feature.
Todos:
- Occasionally, clicking out of the composer contenteditable requires two clicks. This is because atomicEdit is restoring selection within the contenteditable and breaking blur.
- Because the ComposerView does not render until it has a draft, we're back to it being white in popout composers for a brief moment. We will fix this another way - all the "return unless draft" statements were untenable.
- Clicking a row in the thread list no longer shifts focus to the message list and focuses the last draft. This will be restored soon.
Test Plan: Broken
Reviewers: juan, evan
Reviewed By: juan, evan
Differential Revision: https://phab.nylas.com/D2814
Summary:
This diff implements a behavior change described in https://github.com/nylas/N1/issues/1722.
Reply buttons should prefer to focus an existing draft in reply to the same message, if one is pristine, altering it as necessary to switch between reply / reply-all. If no pristine reply is already there, it creates one.
Reply keyboard shortcuts should do the same, but more strictly - the shortcuts should switch between reply / reply-all for an existing draft regardless of whether it's pristine.
This diff also cleans up the DraftStore and moves all the draft creation itself to a new DraftFactory object. This makes it much easier to see what's going on in the DraftStore, and I also refactored away the "newMessageWithContext" method, which was breaking the logic for Reply vs Forward between a bunch of different helper methods and was hard to follow.
Test Plan: They're all wrecked. Will fix after concept is greenlighted
Reviewers: evan, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D2776
Summary:
- New behavior is that the in split mode, you will perform actions on
the selection via the MessageListToolbar (the toolbar positioned above
the message list)
- Refactored and moved around a bunch of code to achieve this:
- Mostly renaming stuff and moving stuff around and removing some
duplication
- Update naming of toolbar role to a single role, and update relevant code
- Converted and refactored a bunch of code into ES6, specifically to reuse the code for the ThreadActionsToolbar at the 2 locations
- Deprecated MultiselectActionBar in favor of MultiselectToolbar
- Deprecated old roles
- Punted the animation for the stackable cards in the selection display for now.
- #370
Test Plan: - Manual and unit tests
Reviewers: evan, drew, bengotow
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D2756
Summary:
Autolinker is a great open source project but it attempts to parse HTML with regexp, is quite slow, and hangs on specific emails https://github.com/nylas/N1/issues/1540
This is super bad, and also super unnecessary. I think this should do the trick.
Note: I changed the urlRegex in our Utils to be much more liberal. It now matches anything that looks like a URL, not just things with the http:// and https:// prefixes. It's used in the LinkEditor and onboarding screen (detecting auth errors with urls) and I think it should be ok?
Test Plan: Need to write some tests
Reviewers: evan, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D2725
Summary:
- In Gmail all threads /must/ belong to either All Mail, Trash and Spam, and
they are mutually exclusive, so we need to make sure that any add/remove
label operation still guarantees that constraint
- Update ChangeLabelsTask to modify the set of labels to add and remove
based on this rule
- Update tasksFor archiving, moving to trash and moving to spam so they
don't affect any other labels in the thread, as gmail does.
- Removing from view /will/ remove any current labels, but will also
move between all mail and trash as needed
- Remove Inbox, Trash and Spam from the CategoryPicker, as Gmail does
Test Plan: - Unit tests
Reviewers: drew, evan, bengotow
Reviewed By: drew, evan, bengotow
Differential Revision: https://phab.nylas.com/D2715
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:
- Separate gmail's remove-from-view and delete behaviors and write logic
for each of those
- Remove MailboxPerspective::{canArchiveThreads, canTrashThreads,
removeThreads} and some unecessary code in TaskFactory
- Instead, add MailboxPerspective::tasksForRemovingFromPerspective (I
know its a bit of a mouthful)
- I initially tried to put all of the logic for each execution path
inside the TaskFactory by checking perspective types, but it made
more sense to use the polymorphism already in place for the different
perspective types.
- There is a default delete/remove-from-view behavior which is
configurable via simple ruleset objects. The gmail behavior is
configured in this way.
- Update swipe css classes based on destination of threads
- Fixes#1460:
- Update logic to display archive/trash buttons and context menu options correctly
when selected threads can be archived/trashed (not based on
perspective)
- Same for swiping
- Add a bunch of specs
- Convert some code to ES6
- TODO write some docs for new functions
Test Plan: Unit tests
Reviewers: drew, evan, bengotow
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D2682
