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
Objects can be different instances (and for User, they can contain
very different data) in which case they wouldn't be recognized even
if they were the same user.
Let's find by ID instead.
Bug: T124803
Change-Id: Ia166fd4190f264354cea83d98047c62c7e0714ea
This makes the actions more consistent, and also allows for separating
the two behaviors: The one where we need a link to a destination
(User page, diff, etc) and one where we have an action the code needs
to take care of ("Mark as read" or, in the future, volume control, etc)
Also, this allows for adding descriptions to the secondary links in
the dotdotdot menu.
It also fixes the bug where the links did not work.
Bug: T125160
Change-Id: I0ebf3fc62425f86e2e7f1e96b67f8dc34db83efb
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
We now have 'special' in $formatters, there's no need to keep
the mapping to the legacy formatter around.
Change-Id: I66f330e8c84a50858658361caef521a3e5717d58
Right now, if certain users should be excluded, that would have
to be part of the user-locators already. This is annoying because
it's hard to write "generic" user locators when you want to exclude
just a couple of people in certain cases.
In Flow, for example, we have user-locators for users watching a
board or topic. We don't want to send the notification to people
that have also been mentioned in that post (they'll get a separate
notification). We could build that exception into those
user-locators, but then we couldn't re-use them in other places...
This basically means we couldn't use EchoUserLocator::locateUsersWatchingTitle,
we would have to roll our own that also excludes mentioned users.
Instead, this lets you add 'user-filters' (that functionality
actually exists already, but is not currently exposed), which
lists users to not send the notification to, even though they could
be in a user-locator.
Bug: T125428
Change-Id: Ifa0e2d3283f57624af4c5ec264f9f66223508e83
'notification-user-rights-add' and 'notification-user-rights-add'
were removed in I8386429a36182dbc44b45990506a42cbeef115ad
but they are still used by the email formatter.
They should be removed when the emails are formatted
using the presentation models.
Bug: T125584
Change-Id: I1453c9b0c05bf898c72d098dfb6d2d07135d3fac
