Summary:
This diff adds an "OutboxStore" which reflects the TaskQueue and
adds a progress bar / cancel button to drafts which are currently sending.
- Sending state is different from things like Send later because drafts
which are sending shouldn't be editable. You should have to stop them
from sending before editing. I think we can implement "Send Later"
indicators, etc. with a simple InjectedComponentSet on the draft list
rows, but the OutboxStore is woven into the DraftList query subscription
so every draft has a `uploadTaskId`.
- The TaskQueue now saves periodically (every one second) when there are
"Processing" tasks. This is not really necessary, but makes it super
easy for tasks to expose "progress", because they're essentially
serialized and propagated to all windows every one second with the
current progress value. Kind of questionable, but super convenient.
- I also cleaned up ListTabular and MultiselectList a bit because they
applied the className prop to an inner element and not the top one.
- If a DestroyDraft task is created for a draft without a server id, it
ends with Task.Status.Continue and not Failed.
- The SendDraftTask doesn't delete uploads until the send actually goes
through, in case the app crashes and it forgets the file IDs it created.
Test Plan: Tests coming soon
Reviewers: juan, evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D2524
Summary:
This diff centralizes logic for creating common tasks for things like moving to trash, archive, etc. TaskFactory exposes a set of convenience methods and hides the whole "and also remove the current label" business from the user.
This diff also formally separates the concept of "moving to trash" and "archiving" so that "remove" isn't used in an unclear way.
I also refactored where selection is managed. Previously you'd fire some action like archiveSelection and it'd clear the selection, but if you selected some items and used another method to archive a few, they were still selected. The selection is now bound to the ModelView as intended, so if items are removed from the modelView, they are removed from it's attached selection. This means that it shouldn't /technically/ be possible to have selected items which are not in view.
I haven't refactored the tests yet. They are likely broken...
Fix next/prev logic
Test Plan: Run tests
Reviewers: evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D2157
Summary:
This started when I noticed that drafts weren't dissapearing from the
draft list after send. This was a pretty big bug because if you ever
clicked on one again and tried to re-send it would throw a 400 error
saying the draft id doesn't exist.
This uncovered a few fundamental issues with the DB.
First of all, the reason the draft list wasn't updating was because the DB
trigger that happened when we got in a new message, was being ignored
since the diff contained no drafts (it's now a message).
The bigger issue was that if you had a draft with only a clientId, gave it
a serverId, and tried to call "save", the REPLACE INTO method would not
update the old object, but rather create a second duplicate. This is
because the `id` field was being used as the PRIMARY KEY, and in this
case, that `id` field changed! The fix was to change the PRIMARY KEY to be
the `cilent_id` instead of the `id` and use that as the REPLACE INTO
index.
We still need the `id` field; however, because all of our reads depend on
that field usually being the serverId
Fixes T3507
Test Plan: See new and updated tests
Reviewers: dillon, bengotow
Reviewed By: bengotow
Maniphest Tasks: T3507
Differential Revision: https://phab.nylas.com/D1992
