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
This was supposed to merge master into the two_tabs branch, but it was accidently done against master instead
This reverts commit 06ee936e92.
Change-Id: I98da735b7d5c103399a2478286d1420243df6ba4
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
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
1. We are not using 'extra' in API calls.
2. In some cases, we are storing private information in 'extra' data, this would expose those information
Change-Id: I3d8e03c3e01b1cc8832ac98d85a3a74e41865913
patch set 1:
* Consolidate notification retrieval in API and Special page
* Add load more function to special page with records as old as 7 days ago
* Add support for browsers with javascript disabled
patch set 2:
* Remove trailing whitespaces
patch set 3:
* Fix some i18n issue
* Fix variable names and some exta whitespace
* Load core css files on special page rendering
Change-Id: Ic69e430b5eb196e5223a2bb6b1d447ef257d559b
