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'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
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
Added code to redirect the user and display a short message informing
them of the need to login.
Bug: T118873
Change-Id: I2145bc1502dbd19d660302d9f19e0d4a2ad5ad50
Presentation models that display the number of bundled notifications
typically group these by a property like agent or page ID. For example,
every edit someone makes to a user talk page generates an event,
so there could be 5 edit-user-talk events by only 2 distinct users;
in that case we want to display "Foo and 1 other user left a message",
not "Foo and 4 other users".
With this change, a presentation model that wants such behavior
can pass a callback to getBundleCount() that retursn the user ID, which
will cause getBundleCount() to return the number of distinct
users rather than the total number of notifications.
Change-Id: I79c8dd14277eff0d2ec27f155b1d13dca1e571a8
I'm not really sure where to stick the primary link. I could wrap the
entire notification in a <a> tag, but all the text becomes ugly (I
suppose we could hack around it with CSS?). For now I just added it
before all the secondary links.
Change-Id: I4f6add9ecfb367660d1a6346825382ad415bdb77
The implementation of this sucks as the presentation model
should not be making database queries. But the API it provides
is what we want and will be supported even if the backend
implementation is changed.
Change-Id: Ifd0d11260990fd0e00e8f32eee273f9717d3e1fb
We should probably merge this ASAP now that a lot of presentation
models still have to be implemented. There's a bit of B/C code that
will take care of the previous format, but it would be nice to be
able to remove that soon.
Meanwhile I've also changed getPrimaryLink to follow the same format.
Bug: T115421
Change-Id: Ic18a050d2ee0239f287a6d55c572df6f8aebb59a
This implements a backend layer and database storage for tracking what
wikis a user has unread notifications on. It is not yet exposed via any
API.
Whenever the notification counts on the local wiki are reset, a deferred
update is queued to also update the central database table.
Change-Id: Id1498bdeb5811d6848dc66781ffca03e726eab90
Instead of relying on the frontend to render, this enables the frontend
to do it.
The API will now accept a new format: 'model', which is basically the
presentation model's data in json format.
Some of the render code is currently only in the backend (e.g. get icon
path from icon type) so other api formats will stay available. At some
point, however, we may be able to kill those.
Bug: T115418
Change-Id: Ibc3ad54c94d6ea9bf751f3927cf69e1d062f4780
It's basically impossible for DatabaseBase::select() to return false now
that ignoreErrors() is protected. So always return an array so callers
don't have to worry about false.
And remove a test that checked the result if DatabaseBase::select() did
return false.
Change-Id: I9ca8511585403d8c0ec262898ad4e61c2b038d51
