This should have been done from the beginning; the model manager
pulls models by their symbolic names. So far, we've used the source
for that, but that assumes that two modules always have different
sources, and that is absolutely not necessarily the case.
For example, internal local bundles will each be a model, but have
the same ('local') source. They should still be differentiated in
the manager by their names, but the source should state clearly that
it is local.
For this, the models now have "getName" method and the name is
created separately from their source. Items also preserve a
reference to their parent's symbolic name so they can provide
that for items that require the controller to manipulate a specific
model.
Change-Id: I8c39d5d28383d11fb330addce21e07d5c424da6f
This causes it to update the notification count cache as well.
Should we perhaps rename it to recacheNotificationCounts.php?
Bug: T132954
Change-Id: I540c4296f4fbadcf2267d77b53f71ee5c2eb8b52
This script was supposed to be run in production in 2013, but that
never happened. It was also never added to update.php.
* Use makeTitleSafe instead of newFromText, for correctness
* Fetch the columns that the update generator needs
* Replace wrapper for private method with closure
* Make the maintenance script logged
Bug: T136427
Bug: T50059
Change-Id: I6c2972120189f035483b5ca49610c008c4ba2c88
In the current bundling system, only the
bundle base is mark as read. It leaves all
the non-base bundled notifications without
a read_timestamp. They would all appear
as read in the new bundling system.
With this change, all notifications in
a bundled are update with a read_timestamp
when the bundle is read.
The implementation of this change is
somewhat temporary as the new bundling
system brings changes to the models
and controller.
Bug: T136368
Change-Id: I70b71d722d8d62cbdd1adc004293030ef900ac94
This maintenance script sets the correct read_timestamp
on notifications that have been read as part of a
bundle.
Bug: T136368
Change-Id: I735fb230a14f95e0a983e733ec160eb8811b3197
The zero results can either be because there are no notifications
at all for this user in the local wiki, or because there are no
results for the specific filter. Both messages are used for either
case.
Also, clean up the display of push/pop pending for the inbox widget
and hide the label in case the message count is 0 or 1 notifications
as it is unhelpful and irrelevant in these cases.
Bug: T136586
Bug: T136574
Bug: T129363
Change-Id: I1465f772bb9f5247df645d6612f951e5fd7d38cf
Add a pagination widget with events and separate the logic for
organization. Let the widget listen to events from the pagination
model so it always keeps itself updated.
Change-Id: Id1df112cbb0d90195217e88fbee97a59170b99c5
The items should resemble the popup items, but the styles clashed
with the popup's cross-wiki notification item, so the image size
was smaller and the border was incomplete.
Bug: T136572
Change-Id: I3c3f825d469ccee1e711da21f627eeb9491e9480
Change the pending element to be the notifications list rather than
the whole inbox widget in the Special:Notifications page.
Bug: T136581
Change-Id: I82b073c9cd628f30c13305510d6604e3ef636c2a
Show an API failure message if the request failed.
Also take this opportunity to show a message in case
there are no notifications at all.
Bug: T136467
Change-Id: If5761ec3d3df10a8774561bed06a4ade54458c4b
We don't show an error message in this case, just an
empty popup, so that should be fixed regardless.
Bug: T136467
Change-Id: I06ddd5306bd8d7edeb8c75bdae7abd7215285e3d
