This is needed because global tables and cache keys will attempt to be used
even for users who don't have the preference enabled.
Bug: T135266
Change-Id: I6208a12d46c8cd0275a232663cd50ac2bd2fed1c
When updating notification counts, we already called User::invalidateCache(),
which bumps the local user's touched timestamp, which is taken into
account by OutputPage when computing the last-modified timestamp of the response.
However, this only works for one wiki, while the changed global count
needs to be displayed on every wiki. To accomplish this, track the
timestamp of the last update in NotifUser, and hook it into
OutputPageCheckLastModified.
Change-Id: I22c88a017f18a28179906049ee423c2d7e81c939
We were using the local user ID instead, which is not the
same on every wiki, which caused strange cache staleness
and pollution behavior.
Run sets through a wrapper function (gets were already wrapped)
so we can update the instance cache and deal with uncomputable
cache keys in one place. A global cache key may be uncomputable
if we fail to obtain the user's global user ID (users aren't
supposed to be unattached, but some are).
Also bump the cache version to get rid of polluted cache entries.
Bumping this version number was probably a good idea anyway,
with all the recent changes.
Bug: T134533
Change-Id: I1c4f0c2f2eded480c80f8ec7a49a04feb7c5ecfb
Previously, getNotificationCount() only looked at local notifications,
and foreign notifications were added in separately by getMessageCount()
and getAlertCount(). This didn't make any sense and resulted in
counter-intuitive things like I4d49b543.
Instead, add a $global flag to getNotificationCount(). If $global=false,
the local count is returned as before, but if $global=true, the
global count (=local+foreign) is returned. If $global is omitted,
the user's cross-wiki notification preference determines which is returned.
Update getLastUnreadNotificationCount() in the same way, since it had
the same issues.
Also add caching for global counts and timestamps, using a global
memc key.
Bug: T133623
Change-Id: If78bfc710acd91a075771b565cc99f4c302a104d
There is currently a hard cap of badge display count.
We'll want to be able to request a different count for other purposes:
cleaning up old notifications, for example. We want to keep around a
certain amount of motifications (which is higher than the display count)
so we must be able to query a different count.
Change-Id: Id460fd7f46e397d22da49283b30fd12a6bbb0c9f
This involves:
* Making this value no longer admin-configurable.
* Changing getNotificationCountForOutput to return only a single value
Since there is no + in the formatted value anymore, we can actually
use the same value for both.
This is a B/C break, but hopefully worth it to simplify the method
call.
For now, the excess parameter is just marked unused. It could be
removed at some point if the translations are updated.
This must be merged at the same time as:
* Flow - Ibfa56b1af9e8c56b4c5f900e0d487bc09688b2a2
* MobileFrontend - Ibf784b279d56773a227ff261b75f2b26125bbb63 (well, MF
can be merged first)
* translatewiki - I2a4b6938aed49e4101deb6b9351c43656a863490
Also, change 1 to One/one, per Siebrand on the task. This can easily
be dropped/undone if we don't want it.
Also, remove reference to no-longer-existent notification-page-linked-bundle
Bug: T127288
Change-Id: Iabeaae747f99980c0610d552f6b38f89d940b890
Add a 'mark as unread' to all unread notifications and allow them
to be marked unread. These notifications will no longer be automatically
marked as read when the pages they refer to are visited.
Bug: T73564
Change-Id: I677d3c0399e46fd7c35531df1cc0e61db2d4eb1b
Current situation: cross-wiki can be enabled on certain wikis &
disabled on others.
Code used to check if cross-wiki was enabled before fetching the
status of unread messages on foreign wikis. However, it would then
write that result to a shared memcached key.
The cross-wiki check should not happen before data is stored to
cache: what is stored should always be for all wikis. Only when
we fetch it, should we check if cross-wiki is enabled. And if it's
not, we can't use the cross-wiki data - we have to hack around it
ourselves...
Bug: T124372
Change-Id: I3d3d54fc3cbfbf73b51e97acfd8d355dd0cea36d
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
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
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
The key used was empty, and therefore did not work. Use the correct
key when caching 'hasMessages' for the user to see their message
badge when receiving the first message.
Change-Id: Ib5b07854f96efed974d53267d9ed573c6ca1cf04
Split the notifications into 'alert' and 'message' badget with two
different flyouts. Also clean up styling and module behavior.
** Depends on ooui change Id4bbe14ba0bf6c for footers in popups.
** Depends on ooui change Ie93e4d6ed5637c for fixing a bug in
inverted icons.
** MobileFrontend must also be updated to support the new modules
in this patch I168f485d6e54cb4067
In this change:
* Split notifcations into alert and messages and display those in
two different badges.
* Create two separate flyout/popups for each category with their
notifications.
* Create a view-model to control notification state and emit events
for both the popup and the badge to intercept and react to.
* Clean up module load and distribution:
* Create an ext.echo.ui module for javascript-ui support and ooui
widgets.
* Create an ext.echo.nojs module that unifies all base classes that
are needed for both nojs and js support, that the js version
builds upon.
* Create a separate ext.echo.logger module as a singleton that can
be called to perform all logging.
* Clean up style uses
* Move the special page LESS file into nojs module so all styles
load properly even in nojs mode.
* Transfer some of the styling from JS to LESS for consistency.
* Make the 'read more' button load already with the styles it
needs to look like a button, since its behavior is similar in
nojs and js vesions, but before its classes were applied only
by the js, making it inconsistent and also making its appearance
'jump' from a link to a button.
* Delete and clean up all old and unused files.
* Moved 'Help.png' icon from modules/overlay to modules/icons for
later use.
Bug: T108190
Change-Id: I55f440ed9f64c46817f620328a6bb522d44c9ca9
getNotificationCount & getLastUnreadNotificationTime have an
argument $cached that allows cache to be bypassed & read from
DB. That result is then stored to cache.
In practice, it seems to be used only for cache invalidation.
getLastUnreadNotificationTime didn't allow to specify the DB
to be read from, and EchoNotificationMapper::fetchUnreadByUser
only read from slave.
So when we wanted to invalidate the cache, we would end up
immediately repopulating it with data from a (potentially and
likely) lagging slave.
I've made it accept the DB type, similar to getNotificationCount.
Bug: T98421
Change-Id: Ie4b09eeb04b9827b454cb2d92ee8c674bdd59a19
I tried to stick as close to the existing code as possible.
Special:Notifications is slightly different from the overlay,
however. I made it add .mw-echo-unread class for consistency,
but that JS doesn't record seen time (it only loads older
entries), not does the CSS fadeout apply there (it marks
everything as read as soon as it's displayed, so different
behavior from overlay)
PS: I'm not sure about browser compat for the fadeout. But
even if some obscure browsers don't support this, meh. It's
not an "important" feature that can't be missed.
Bug: T94634
Change-Id: Ibb201823fb52ef8a3d5eaa39b0b724ede8d271d1
* Get rid of EchoBackend by separating responsibilities into smaller objects
* Move main fetchNotification logic from API to a more appropriate place
* Add more unit testing coverage
Change-Id: I42f4d7566543332588431c21c220c0d64d026b70
To test the HTML email:
1. install the latest version of php-mail and php-mail-mime package, they are required
by the core sendmail function to send HTML email
2. set $wgAllowHTMLEmail = true before loading Echo in LocalSetting.php
Change-Id: Ia4b98b14e135742b84f1b0e04589b0efdd24e954
