* Do not default section to footer. If the section
is not found, it is left empty and the notification
message is simpler.
* Change notification-edit-talk-page-email-batch-body2
Replace : at the end with . so it does not look
incomplete.
Bug: T99989
Change-Id: Ic982a81eada388d750760787245dea8f72368147
All uses of $wgEchoBackendName were hardcoded to 'Db' and removed.
This exposed a interesting bug in MWEchoEmailBundler which was
instantiating a subclass using the parent class's private constructor, a
"feature" of PHP which is supported in 5.2.6+ (http://3v4l.org/h4Mq3).
While it worked, PHPStorm complained about it so I made the constructor
protected, which makes more sense anyways.
Both EmailBatch and EmailBundler need further refactoring, but that will
be done in follow up patches.
Change-Id: I2032f5b2f4f3a62f830cc5344b25a92074bd0c61
Update the "processEchoEmailBatch" to allow sending all
notifications immediately even if configured to be
daily or weekly.
Change-Id: I6ebeea86708247700d1950e0f6471c7b3d1fecd2
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
Link the bottom of the talk page and use the edit summary as text
if the parser failed to find something. This is what core's enotif
does already.
Change-Id: Iadc7011ea2627e00f0c51472da7aad1355afeddb
The default value is never used, it is overridden in the constructor.
Having it here just misleads someone looking at the code to think it
might pull all columns by default.
Change-Id: I0e743c371d4bd2fab5b89740ba1e0f082512ec34
While user-locators are the "new hotness", most events still get their
list of users by calling a hook. That means this log message basically
just spams up the prod echo log for no benefit.
Change-Id: Iba5a8267c4ecc5a7446b287759d8b66adf0e2387
* Parser generates signature to compare against
* Signature can be overwritten per wiki, in NS_MEDIAWIKI
* Such overwritten default can be different depending on
page the signature is on[1]
* Our comparison signature generation was page-agnostic
(always from Title::newMainPage)
* Signatures didn't match up on own talk pages, where
default signature is different
Also added 2 new tests cases & improved tests by also
setting the page
1: https://en.wikipedia.org/w/index.php?title=MediaWiki%3ASignature&diff=176507985&oldid=176229132
Bug: T78424
Change-Id: Ice151d4d16236a5d1556ef62805b61310c7beb85
Previously, there were a couple of hacks in play.
It was also not picking up ~~~ (signature without timestamp)
And it relied an a nasty regular expression which, although
based on Parser, may some day get out of date.
And it relied heavily on a specific signature format, which
isn't guaranteed (it's an i18n msg)
This patch changes the approach: it will use a very simple
regex to match links, and will send those through Parser to
generate the signature anew. My reasoning is that that should
be exactly the same as what Echo just received (should've
also gone through parser)
Biggest discomfort of this approach is that it's much stricter.
It should still match whatever it generated from a ~~~ or ~~~~,
but no longer the e.g. not-real signatures we were doing in
our tests. Also had to update our tests, because signatures
change depending on anon. So I had to generate all the users.
And fix some of the signature formats used in the tests.
Bug: T75426
Bug: T87852
Bug: T75366
Bug: T78424
Change-Id: Ibeff36397129fdd5d376f3668a23a45f9a014525
In some languages the \w+ does not match the characters used
when translating UTC and the regular expression attempting to
match the timezone fails. Testing in prod wikis where this fails
such as ne.wikipedia.org shows it still works, it just generates
a more generic regular expression.
Since the overall process still works acceptably on the wikis outputting
warnings this patch just adds a guard to prevent the warning and does
not attempt to fix the underlying issue.
Bug: T76558
Change-Id: If8e1ddd2d642b042cc24c51d5ba5aa8b34bc9552
There were two different circumstances that could trigger echo's signature
detection to fail: multibyte characters in signature, and signatures near
$wgMaxSigChars limit that expanded past the limit due to wfEscapeWikiText().
This patch adjusts to use mb_substr to appropriatly handle the multibyte
characters, and adds a couple extra charactesr to $wgMaxSigChars to allow
for wfEscapeWikiText(). This isn't perfect, but a stricter implementation
would require much more work than i think we should spend here.
Bug: 73426
Change-Id: Ic51c2bc2a08600f188db13a9a0537f1321c9a655
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
Currently echo attempts to find a signature by looking for a series of
strings starting with what it thinks are the current aliases of NS_USER
and NS_USER_TALK. This has shown to be error prone, see the linked bug
for how a change to ru.wikipedia.org/wiki/Mediawiki:Signature broke
mention notifications.
Patch switches things arround to pull wikilinks out of the text and run
them through the Title class. The results of this parsing are checked
for NS_USER and NS_USER_TALK, giving a much stronger guarantee of finding
translated namespaces.
Bug: 71353
Change-Id: Ib0d0f4e068339d2fd28761087c05f5a1acb3c1fc
Has a performance impact, so this depends on deploying the job
that deletes older notifications.
Bug: 69919
Change-Id: Ia485c853d1b04c3c85e25e6a12f5060a046e9b11
The only issue is that the badge is not up to date till
you refresh the page, I think that's fine for now
Change-Id: I585b4cc185bf859ddb06829df75309ff3d56d8b8
