* 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
EchoTitleLocalCache title cache resolution ends up querying the database
to resolve title id to Title object.
In some corner case, we might only have one page in the database (UTPage
as provided by MediaWikiTestCase), thus the id 2 would not resolve to a
Title breaking the test.
Use insertPage() to ensure we have a second page.
Bug: T78592
Change-Id: Ia9dbb256f566e489e1c81d89b6a6077831e07fc3
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
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
Notification timestamp is generated in MW format (YYYYMMDDHHMMSS)
inside the model and saved to the database in db specific format,
We need to convert it back to MW format when loading the data
from the database, it just happens that MW format is the same
as MySQL timestamp format
Change-Id: Ie881b66c8c24d57a8933c0153e9e7db5fe6aa017
* Moved most of the content from notify to getEventNotifyTypes
* Added phpunit test verifying per-event config overrides defaults
* Remove special-snowflake welcome handling with proper configuration
Change-Id: Ic1aae11d37f23f2b7b8abe3c1edaa414e29be021
