We already output unix timestamp both in user preference timezone as well as
utc, but we only had the user timezone version for TS_MW format.
While we could change the frontend to use the unix timestamp format, I don't see
any reason not to also include the MW format in utc. Frontend can now easily use
that.
Also fixed creation of the moment object. The timestamp was created as UTC, but
the way it got there was wrong: it expects the timezone offset (Z) to be
included in the timestamp, which is not the case (so it just ended up at +0:00,
which was fine, but confusing). I removed the 'Z' and forced it to be
interpreted as utc.
Bug: T121813
Change-Id: I09403615a1ffbde5dd69af9914afdbdd86cbfe4d
We removed the item first from the 'unread' counter and then told
the API to mark it as read. The API, however, wisely first checks
if there is anything *to* mark as read, but by that point, the
unread count is zero, so it gracefully refuses and returns an
empty resolved promise.
That is clearly not the way to go. Remove the read item from its
smart unread counter only **after** it was sent to the API to be
marked as read.
Note: We shouldn't wait for the API promise to resolve to remove
the item from the counter, but the API should run its preliminary
tests before the item is removed.
Bug: T122087
Change-Id: Ia5fc35c7435db8c4742238897da67681cee23c41
Use #888 instead of #666 to match secondary link text
(which is #000 with 50% opacity), both in the flyout and
on the special page.
Bonus: use LESS variables for these colors.
Change-Id: Ifc1182a001e9b25f6ff7c213b6fcde3dc2f0acd2
We're trying to get rid of links in notification
messages, and the link was redundant with the primary link
in both cases.
Change-Id: I69e888a355c263b5a8c5ca7a46430746895de44c
They're currently auto-converted to the new format, but ideally,
we wouldn't need that B/C code. And since this is the extension
others will likely look at for examples when implementing, we
should do it right here.
Also: there is no B/C correction for missing keys in secondary
links (description, icon).
Change-Id: If1a8b9911e81bb4c565f21a4b9e31fdc73426d93
Also removes tests for the class.
Bug: T119253
Change-Id: I4c0d7187c2b847297dd0867faecba26185cfba37
Depends-On: Iccafbbdb06711463fee0f30a11326c7771df30e2
* Add the ability to use bundled expandable
notification groups
* Display bundled cross-wiki notifications following
the design
Bug: T115419
Bug: T115423
Bug: T115422
Change-Id: I8c3eba6d627c3f06d51d74fc9774e3fc2d02915d
Adds support in the logger code that is unused for now.
Note that I9bf6f4bcd41d8da5 must be deployed before this can be used on
Wikimedia sites.
Bug: T120158
Change-Id: I1968f36e21139975d25231ac25c22a73dea6fd0d
Right now, it'll only respond a certain, fixed, amount,
not allowing you to paginate the list.
Note: haven't properly tested all possible cases yet!
Change-Id: I84761b13a1b9203cb8e3fcc80941d739cd28659f
The only difference at this point is that fetchByUser initializes
the EchoNotification object with $targetPages. It doesn't really
matter that it doesn't have the target pages, since fetchUnreadByUser
is currently only used in the flyout, where those target pages aren't
used. But regardless of what method was used to fetch the data, I
think the data should be the same.
And now, there's less code duplication...
Change-Id: I04c7b98794af5427a2217dd337108e7eea1e65c5
