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
MediaWiki core change I04b1a384 added support for i18n of API module
help. This takes advantage of that while still maintaining backwards
compatibility with earlier versions of MediaWiki.
Once support for MediaWiki before 1.25 is dropped, the methods marked
deprecated in this patch may be removed.
Change-Id: I67395aff48185f3e09da31b51a08aa2541fe6a17
Previously this was loading 25 unread notifications. If less than 25 were
found it would add in 3 read notifications so it wasn't empty.
This patch changes things around to always return 25 notifications if the
user has at least that many. Instead of backfilling a static count of 3
we backfill 25 - $count with previously read notifications.
Change-Id: I723316486216d7b9dacfcc9765c1a8212e973518
When the notification is retrieved without unread first,
it should have a continue offset for next batch of loading
Change-Id: I101990faaf9ed3e3786805aff3906b846d62f612
When two array have the same keys, we want to merge them into one array
rather than one overwriting another one
This was preventing count and rawcount from appearing inside the messages
and alerts object returned by the API.
Change-Id: I989b9b0994a33925faf52c6d99d8c46920e62cd6
* Shared function can be put in the abstract class and this also enforces some interface methods
* Initialize a default dbFactory when it's not passed to the mapper
Change-Id: I1033dafaa90a1f683fbe9ad69bed04f4844e357b
Core change I2793a3f2 changes API handling in a way that needs updates
to extensions for proper operation:
* needsToken() now returns a string
* Most custom token types are being replaced with a 'csrf' token (the
former 'edit' token); any others need a new hook.
* All tokens must use a static salt. Compat with web UI using non-static
tokens is supported and also serves to handle the now-deprecated token
fetching.
* Documentation in getParamDescription() should return a string (not
array) for 'token', as the signal to core that it should be replaced
with a standardized message.
When compatibility with earlier versions of MediaWiki is no longer
maintained, the entry for 'token' from getAllowedParams() and
getParamDescription() may be removed, as may getTokenSalt(). This patch
leaves them in place.
Note this is intended to be compatible with earlier versions of
MediaWiki, and so should be safe to merge before the core change.
Change-Id: I7cbdc5a7119cdfeadc1fe55469065a44c228a006
The distributionType is still passed to the function, it will
be arry of event types in next patch
Change-Id: Ieae7cfc383c2a024256f7e6b2f91d3b5c323f79b
* 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
General code cleanup as reported by the PHPStorm static code
analysis. I hope it's not a problem that I made a lot of very
different (but all very tiny) changes in a single patch. If you
want to merge this but you think it's better to split it into
several patches first, please tell me.
Change-Id: I2e2c4bb47f8d20e038d28e236e2ff813b30504af
* In some languages like persian, the number 0 is represented as '.', we can't compare
'.' with either 0 or '0' to detect the no-notification status of the badge
* The markread API doesn't respect uselang param, it would return 0 instead of . in a url with uselang=fa
Note: we need to provide raw and formatted count in the API since client side javascript
doesn't provide fancy function like $wgLang->formatNum()
bug: 54575
Change-Id: I0a49828253ec346ed27c5b9a976f8bdff4e1fa90
* The timestamp used for loading more should always use UTC timestamp since
that's the format saved in the database
Change-Id: I249725a6972b95dddd9074ffe08343b1a805c111
This change will allow people to switch between 'May 10' and
'10 May' as requested in bug 47211. It also now corrects for the
user's timezone settings.
Bug: 47211
Change-Id: I7c5eae52857fac2d82ff1cb0b10864a1e1b30b6a
Comparing only the month and date is not enough, a date header for
the same month/date last year would be parsed as today
Change-Id: Ief4e047bdd91ac39fa62cc2c0a5134e35abd7c4f
1. Only trigger mark as read if the unread notification count is > 0
1. Add a limit to the number of notification that can be marked as read
2. Only update those records with read_timestamp = null
Change-Id: I12456c504787f45f594ef9283e98d98692956935
We weren't setting the XML tag name used for notifications, so this was causing a fatal error.
Bug: 48009
Change-Id: I676f7e7fee1167d02ed35920719105d3ca260e74
Button is only shown if there are more unread notifications than
fit in the overlay.
To avoid performance issues, this version only works for cases where
the number of unread notifications is less than the maximum count
(99 currently). Otherwise the button to mark all as read isn't
displayed (it's also limited on the server-side for good measure).
Bug: 47092
Change-Id: Ifcb0a436e2b31062741c441cca239d35ddefa0e1
* add web bundling feature
* unify event_timestamp with notification_timestamp
* remove echo_subscription
* update article_link to page_link notification with new logic
* remove duplicated function from MWDbEchoEmailBatch since it's defined in parent class
Change-Id: I2fa91c44edb020209b468fe13f894d9db3732e69
Since every event is tied to a category, it's better for event object to have it as a member method
Change-Id: I911415284486bb11d13d91366340c5c330317c34
Includes new web preferences for Echo
Also adding ability to set dismissability per notification type
Still need to arrange subscription options into a friendly format
Still need to add dismiss functionality to flyout
Change-Id: I484a24b424e69be3640e63b76f82735edae6f13a
This is replacing the implementation I did for 'html-light'.
The reason html-light doesn't work is that we don't have any way
of reliably determining which parameter should be the one that is
linked to in the notification title (flyout notifications are only
supposed to have one link). With this system, the notification
definer can specify a separate message/params combination to use
specifically for the notification flyout. If they don't specify
these, it falls back to the normal title message/params.
Change-Id: I35394849cf99307eba4a76e079333d19514fdb5d
