Only prohibit users from using Thanks if they are blocked from the
associated page. This allows partially blocked users to use thanks
most of the time.
It also allows blocked users to thank on their own talk page, if
they are allowed to edit it, even if they are sitewide blocked.
Bug: T221371
Change-Id: Ic99ec38ea200e806963951b2dd67e56ecde63752
Every time the setup function runs, it chooses a random page name with
random content. If it chooses a page name + content combination that was
used to set up a different test in the same run, the edit it makes will
be a null edit, the revid will be null, and the test will crash.
There are 100 possible page names and 100 possible page texts, so 10k
possibilities total, and the setup function appears to be called 10 times,
so the probability of a collision would have been
(10 choose 2)/10000 = 0.0045 = 0.45%, or one in every 222 times.
Bug: T151878
Change-Id: I800ee8512c2ad171ba793bea343f456653f9a16d
Originally introduced in b84eedc74e, it was reverted for security concerns.
New changes:
* Instead of bundling the log summary with notification, load it on display
* If the log event has been suppressed after the thanks for it has been sent,
silently delete the event to prevent the confusion of linking to something
zapped.
* Keep the 'already sent' cache key compatible with old format
* Validate the log id in the API
* Change ApiCoreThank::getRevisionFromParams() to ApiCoreThank::getRevisionFromId()
Bug: T186855
Bug: T188791
Depends-On: Ic5e9db0def857d9dcecbd06bf081c8c83712c1ea
Change-Id: I03aea7d9f4dfa0fe49639c53968deabf89999d2d
Add a 'log' API parameter (for the log ID to thank), and add
a whitelist config variable for specifying which log types are
thankable.
Bug: T186855
Change-Id: I58ae90c9729c0066f952e90fca2cf99b029d0d9b
See Iae0e2ce3. Since Thanks master requires core master, this just
depends on the master patch instead of trying to maintain BC.
Depends-On: Iae0e2ce3bd42dd4776a9779664086119ac188412
Change-Id: Ib6e66f7e94c41b7a27fe867f079626ac0ade4f1b
