Due to Ia03038e86c6a607c8b75eefedbf0285ca1a2f8c8 in MW core, the thanks
links now also appear on Contributions and Recentchanges/Watchlist. Load
the thanks JS module there too, so that users can send thanks without
leaving the page.
(Unfortunately, we can't add this module in the hook that adds the
thanks links, because we don't have access to an OutputPage object
there.)
Bug: T51541
Change-Id: I00ecd3b2c72332b6dc5290e649e6811cea0133af
Soft-deprecated since 1.38. Bumping MW version
requirement to 1.38, as that's when the deprecation
happened. Compatibility policy says compatibility
is only guaranteed for snapshots
(with the respective MW version).
Bug: T312579
Change-Id: I384bc2a847dbe01798c4df1b713b0ca8e84aa187
It is causing deadlocks because after hook being called and done, core
itself calls saveSettings(). See:
a2e5997a4c/includes/auth/AuthManager.php (1515)
Bug: T306636
Change-Id: I5ded25f56a58bf89b894a8fdd6d8200fb378eb75
Moved the factory deeper into the code right before the one usage it
still needed a full user object.
Narrow done method arguments from User to UserIdentity
and use the identity directly
Change-Id: I2231db43f525a74e93dba8ea5865b256efd2dfce
Thanks was causing history views to do 4 DB queries per row, due to the
RevisionStore::getPreviousRevision() call. The reason for doing it is
that it doesn't make sense to thank someone for a diff which includes
multiple authors. This does not apply to history pages -- even for
filtered history views, you can thank someone for a specific revision on
the basis of its edit summary.
So, distinguish between history tools and diff tools. Do the expensive
thing only for diff tools.
Bug: T284274
Change-Id: Ib631100b82958065a327dd18c927af4a78b8be15
Die earlier from ApiFlowThank::execute if them user is blocked from
Thanks, now that it is possible to have a partial block against Thanks
without being blocked from pages.
Follow-up to Id86d97a38c041fea4abcdbdd404428622df76669
Bug: T242785
Change-Id: Ia3683c3cab333b1193b2b77c6c18b5c343b5a5c7
Die earlier from ApiCoreThank::execute if them user is blocked from
Thanks, now that it is possible to have a partial block against Thanks
without being blocked from pages.
Follow-up to I290a7c39c6fcb22a8ab4a9ecbad76a239cb18ea0
Bug: T242785
Change-Id: Id86d97a38c041fea4abcdbdd404428622df76669
- Add hook to enable blocking thanks
- Check if user is blocked from 'thanks' action
and disable giving thanks from API and UI if so
Bug: T242785
Change-Id: I290a7c39c6fcb22a8ab4a9ecbad76a239cb18ea0
User::setOption() is deprecated and should be replaced with UserOptionsManager::setOption()
Bug: T277818
Change-Id: Iacc258705c4517c958a2568e47ba4f43963acc2e
This commit adds the technical possibility to restrict ThanksLogTypeWhitelist
to only log subtypes like 'rights/rights' in addition to log types like
'rights'.
Bug: T191599
Change-Id: I31fb591dda2e5ecbfb5ac07352d3356134533540
Compatibility was added so that MobileFrontend could switch from
Revision to RevisionRecord, but now that the switch has occurred no
need to keep checking to see if a Revision is being passed
See [1] for the MobileFrontend change that required compatibility
[1] e42c52527b
Bug: T246284
Change-Id: Ie320454a0e90d7f98004a3b776010aff784bbf4d
Extension requires 1.35+, so the hooks are available
Bug: T255494
Bug: T255495
Change-Id: I334928ebd081d53a7d95466e6c4b75715b941ec4
Depends-On: Ib2ab2e26a95affdd1dfa6b945f752157580ea2d3
Declare a variable which is not set in all branches for static code
analyzer, but at runtime it is
Change-Id: I851bdbf9dc092d5213d74a03427b783f61e8946a
Can't remove entirely, since the hooks don't have replacements yet,
but can prepare for the switch while waiting and remove use of
Revision objects to the extent possible
Bug: T251073
Bug: T251593
Change-Id: I5f9e41d58c8d1693b23c84bbfe085d3b33ad0c75
CI already ensures that MobileFrontend is loaded alongside Thanks, so
the defensive check in the code isn't needed; ext.thanks.mobilediff is
defined statically, it's just injected into the page dynamically in the
onBeforeSpecialMobileDiffDisplay hook handler.
Bug: T232875
Change-Id: I5612a9be65f4d4adf4912645856540dbb04d2b34
User::isBlocked() by default reads from the replicas;
PermissionManager::isBlockedFrom() reads from master by default. The
'thank' link is not critical so it should be read from the replicas.
Bug: T231617
Change-Id: I262ed63df82e97862a8dfc8da49fc09465ac8507
Call EchoEvent::getRevision to use cache.
Don't hide notification about thanks for log
when just the comment was hidden.
Also simplify code using ternary ?:
Change-Id: I279291727ecd404db18dd68699744284e17a27ef
This prevents users from accessing information about the actor
by abusing uselang=qqx and the thank button.
Bug: T224240
Change-Id: I3f42d56874776cfa0c9d364217f43253efc14782
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
Added two new tests: thanked cookie and gets user gender. First uses jQuery cookies and second uses Sinon fake server
Bug: T160267
Change-Id: I8f5dad9c90e930d557e86acb4b175ec549849e7a
Several links that link to mediawiki.org still use
"http" protocol which isn't a safe protocol. This commit
changes http links that link to mediawiki.org to use
"https" protocol instead.
Bug: T189687
Change-Id: Ibb5f019e21f5d6ca0b4c40138dab22ae43e9004b
We were manually checking for the 'bot' group, but MW core has a method
for this that's more comprehensive.
Bug: T205224
Change-Id: Idce475ce10a21c5593d366470eede7d8dd1f6dfe
Modify the revision continuity check to be
resilient for pages with discontinuous histories
while still catching diff that span multiple
revisions.
Bug: T186470
Change-Id: If9614f6e3e278367530e9a4f5054ac370d1c0699
Add a new "revcreation" extra param to the stored echo event, that is set to "true" if it's a page creation.
Create notification-header-creation-thank message.
Bug: T201507
Change-Id: I80b206b1d24d53c9a60725bc25318e31f083aef0
Suppress the issue with a hint to the task (T201565) allows
to enable the voting jobs and avoids new issues in the future.
Change-Id: I88d09923d1e1a59e285513e56985989fabbb4505
See I2291c69d9df17c1a9e4ab1b7d4cbc73bc51d3ebb for the anticipated
hard-deprecation of this method in core.
Bug: T197492
Change-Id: I5d4ec96afe82910ffd18377b5f5f94405f73e9eb
Thanks for logs are created with 'logid' extra param. Param 'id' was
never used and was added accidentally.
Bug: T192041
Change-Id: I1f7e0d53c674509200fc8c704f99fd3d8197636b
Avoid redirecting via Special:Redirect/logid/xxx with the new
logid parameter to Special:Log.
Bug: T191608
Depends-On: I5f2e52531cd2ba617a25570e40aa8c5168e284d9
Change-Id: Iffb1b0d9cc44fde69aa53f32d4a066cd3a10c5f4
This extension is useless without Echo, and the API modules already
disable themselves if it's not installed. Just absolutely require Echo
to be installed.
Change-Id: I653eea78668bfe0875bc5a33e2d45607106d4ee5
The $oldRev could be null, but when set the null in argument list,
it is an optional parameter and the following argument $user must be
optional too. That is not needed here.
Change-Id: Ia7c1c44b29b191dc602513e07b90d3e2415d3a5d
Only log entries that were associated with revisions were
being thanked. This adds other log entries (if they're of
a whitelisted type still).
Bug: T187485
Change-Id: I9c644590b52bce9b04c7c655dd197c1b78a83777
Many log entries are associated to (exactly one) revision,
and for these (only, and only where the log type is
whitelisted) we add a thank-link that behaves exactly
as the thank-link on diff and history pages.
Bug: T189752
Change-Id: I5f4e84c65d4fe2d95b20cdb3c3f9522ad3e5f422
Core change I8d825eb0 begins the process of changing core database
tables from using xx_user and xx_user_text fields to using xx_actor.
This updates the extension to continue to function during and after the
transition.
Bug: T167246
Change-Id: Ib84a5a7a9f80fa321f7482d4c27c5f58add47230
A new "Special:Thanks/Log/123" subpage format is added for
sending thanks for the given log entry. The 'Log' part of the
subpage is case-insensitive.
The form field labels are removed because the fields are hidden
and need no labels.
Bug: T186920
Change-Id: Ic2279d9a6dc170d1eeee519392d3a930a37bc2ec
Many log entries are associated to (exactly one) revision,
and for these (only, and only where the log type is
whitelisted) we add a thank-link that behaves exactly
as the thank-link on diff and history pages.
Bug: T186763
Change-Id: I2af380d5cb06f19ef9eb5b232d95ad87379b5d9b
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
