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
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
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
Adds EchoEventPresentationModel::canRender() for notification types to
indicate that something can't be rendered if for example, a page is
deleted.
In that case, the notification is marked as read in a deferred update.
All callers were also updated to check if the notification was formatted
properly.
Bug: T116888
Change-Id: Idb975feaec893ef86c41cc487102e3539c07e328
Also:
* Clear the newtalk flag when they mark all their edit-user-talk
read.
* Remove the section caching system. It was designed to avoid
performance problems with Flow messages, but now that standard talk pages
are in 'messages', messages should be relatively common (alerts
were already not cached by this).
* Minor cleanups to reflect that messages are not only Flow (and
a typo fix in the Gruntfile).
Bug: T108760
Change-Id: I82d7b1d08331693830d6a1749612b55e96b95cf9
