* Added support for 24-hour time to the thread list view (Issue #682)
* Add 24-hour time support to the thread list scroll tooltip (Issue #682)
* Fix for 24-hour time in the thread list scroll tooltip (#682)
Correctly imports the DateUtils module
* Add support for 24-hour time to the draft threads list (Issue #682)
* Add 24-hour time to the message sidebar
* Fix for 24-hour time in the message view so the rollover tooltip is 24hour also (#682)
* Removed unused date functions from utils
fullTimeString and shortTimeString from src/flux/models/utils.coffee were not
compatible with 24-hour time. These functions were modified and moved to
DateUtils in src/date-utils.
* Fix for display of 24-hour time in the message view (Issue #682)
* Removed unused import of Utils in a couple of files
Prompted by Travis build errors.
* Updates to handling of date/time display
Incorporates changes suggested by @bengotow.
Re-enables support for the isDetailed property in message-timestamp (if this is set
to true, a medium length date/time string will be used for display).
Re-enables additional display varieties based on when the email was received. Note
that this is implemented slightly different to the orinal version - time is now given
as an absolute time rather than "... days ago" format.
TZ guessing moved to the global scope of date-utils for performance reasons.
* Minor de-linting
* Re-enable all tests by unfocusing the test suite
A previous commit (ad04775) added an fdescribe() to one of the tests in
draft-helpers-spec. This changes that to a regular describe() so that
all tests will be run when running ./N1 --test.
* Added tests for the new DateUtils functions
Added tests for getTimeFormat, mediumTimeString and fullTimeString.
Removed no longer relevant tests from message-timestamp-spec as _formattedDate
has been removed in favour of the functions in date-utils.
To test shortTimeString, we need to be able to set a fake current time which is
possible in jasmine 2.0+ but not in 1.3 which is currently in use.
As a possible bug, when running more than 10 tests the following warning is raised:
"(node:25025) Warning: Possible EventEmitter memory leak detected.
11 on-config-reloaded listeners added. Use emitter.setMaxListeners() to increase limit",
source: internal/process/warning.js (24)
* Minor de-linting
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
