when the subject line is left with the default
generated value, we take the begining of the
email content to add a preview in the
notification.
Bug: T121831
Change-Id: Ib7c646f6709c7100ef51186f84fe14807d6a211a
This code is completely useless:
* for format=flyout, the new EchoFlyoutFormatter.php will be run
* and even that one has already been deprecated as it was replaced
by format=model (flyout html is now built in client)
Change-Id: Iea23abb66397ecc4efb575fe33fdbedc5b4e0f70
The existing "html" formatter was used for the special page & is now
superseeded by the new-style "special" formatter. Previous "html"
notifications are no longer used & could even be broken.
Instead of keeping the old "html" formatter around, we should let it
use the new formatter (and eventually just kill that redundant format
in the API)
Change-Id: Ibbd40aafa9eee718b196ad62f6edc99629b263b4
Split mentions into 4 cases:
- Mentioned on article talk page
- Mentioned on agent's talk page
- Mentioned on another user's talk page
- Mentioned on any other page
Adjust secondary link
icon: article or talk
text: without namespace for article and article talk
Bug: T56433
Change-Id: Ibf965dad4f9cc468fdd4321b2450d6eaec0ac1d7
Only display when it's different than the pre-populated
edit summary (Undo revision 123 by User).
Bug: T121808
Change-Id: I5a00ff174fd31fdbf776a06b7b9375f63b921677
There was no point in letting it extend EchoFlyoutFormatter instead
of the base EchoEventFormatter. The only things in EchoFlyoutFormatter
are formatModel & getIconURL, both of which aren't being called.
Change-Id: I89511530a41976974f4d51d55379a617dfe503ec
All extensions seem to have been updated to use the current formats,
so we can get rid of this tech debt.
Depends-On: I7503db28b0d81fb818b525ea9362e49b9b56342a
Change-Id: Idbcbbf95eab1172015bceea4e8124ba4c639efa8
Also updated description value in agent link: '' is used everywhere
else to mean "no description" (because that's exactly what '' is)
Change-Id: Ib77c0f1843593abf67e9d726a80bb4fbe1ec7d84
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
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
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
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
`getMessageWithAgent` is used by `getHeaderMessage` is can
be reused by other presentation models who need the
agent in their body message.
Bug: T118059
Change-Id: I0cbccaeb8b6e60d03bc75bc85c74591619b4399a
Wikis can customize the 'notification-welcome-link' to a page title
(like "Project:Welcome" for example) and the "Welcome!" notification new
users receive will have a primary link to that page.
Bug: T117509
Change-Id: I29f6d69db480fa7d39573941e762c4dad8737ed0
Because 'welcome' doesn't.
Returning `false` indicates that there is no link, and the
FlyoutFormatter was updated accordingly.
Change-Id: Ifd329b396f3361fc7c08c607a6407181ffdb8bf6
The conversion of EchoEvent into a EchoEventPresentationModel is now
done by EchoFlyoutFormatter, instead of having each subclass do it. It
also does the canRender() check so subclasses don't need to worry about
it.
The subclasses no longer have access to the underlying EchoEvent object,
so the timestamp is exposed in EchoEventPresentationModel.
Change-Id: I7f0a650373eebac7aa2231b1795b51a6d031ad67
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
The workflow to format a notification is
* Get EchoEvent, User, and Language
* Get EchoEventFormatter implementation for notification type
** EchoEventFormatter returns structured data about each part of the
notification (header, body, primary link, secondary link(s))
* Each output type will have a formatter class (e.g.
EchoSpecialNotificationsFormatter, EchoPlainTextEmailFormatter) which
takes a EchoEventPresentationModel and generates whatever it wants
(HTML, plain-text email, etc).
Included is an example conversion of the user-rights and mention
formatters. The previous infrastructure will remain in place for
backwards compatability until other extensions can be updated.
Bug: T107823
Change-Id: I4397872a7ec062148dfcb066ddd8ab83f40486ac
