We currently use client-side storage to keep track of what revisions and
posts have already been thanked for. This is problematic because client-
side storage is not permanent, making it easy to send duplicate thanks
if you have logged out and in, or switched computers.
This starts storing new thanks in the log_search table, which is
designed for efficient querying of metadata associated with a specific
log entry. With this, we can easily check to see if a user has already
sent thanks for a specific revision.
The UX is a bit weird right now, we only check log_search when actually
sending thanks again, in which case the user thinks they have sent
thanks again, but no duplicate thanks is actually sent.
Bug: T88820
Bug: T53303
Change-Id: Iaf8cbe0776081dc69e82883d8727ba1cfe20e3e1
Core change I2793a3f2 changes API handling in a way that needs updates
to extensions for proper operation:
* needsToken() now returns a string
* Most custom token types are being replaced with a 'csrf' token (the
former 'edit' token); any others need a new hook.
* All tokens must use a static salt. Compat with web UI using non-static
tokens is supported and also serves to handle the now-deprecated token
fetching.
* Documentation in getParamDescription() should return a string (not
array) for 'token', as the signal to core that it should be replaced
with a standardized message.
When compatibility with earlier versions of MediaWiki is no longer
maintained, the entry for 'token' from getAllowedParams() and
getParamDescription() may be removed, as may getTokenSalt(). This patch
leaves them in place.
Note this is intended to be compatible with earlier versions of
MediaWiki, and so should be safe to merge before the core change.
Change-Id: Ifb9a080f1ad7236127c61287d14ff4a465543e0f
If the user has JavaScript disabled, clicking
on "thank" will send the user to Special:Thanks
with the revision id already filled in. When
submitted, the form calls the API internally
and then shows the user an error or confirmation
message.
Special:Thanks is not a listed special page
since it's mainly intended as a fallback.
The API was modified to return the user name of the
editor who is being thanked if a new notification
was created.
Bug: 49161
Change-Id: I7ba4664b92bb0da425784350487ed0e7ca352b4e
If the user attempts to thank an anonymous
user, a bot (when $wgThanksSendToBots is not true),
or him/herself, return an error. This is consistent
with the restrictions imposed in insertThankLink().
Bug: 56954
Change-Id: I9e8ae030a8ff1cc312bf98671e593c7367ca0ea2
Thanked revision to be stored both server side in the session and client side
in a cookie. Thanked revisions found in either storage solution will replace
their 'thank' link with the string 'thanked'.
Bug: 46690
Change-Id: I976cd8fbf00856c67b77daeb0d0a952efb371661
