Since the extension is using short array syntax, I'm going to guess
there's no need to complicate it by worrying about compatibility with
MediaWiki core < 1.26.
Bug: T135065
Change-Id: I81dd764940ebb400f3ecdf15934f6f501c05ea9c
* Add ThanksPresentationModel and FlowThanksPresentationModel
* Rename notification-thanks-flyout2 to notification-header-edit-thank,
shift parameters around and add GENDER support for thanked user
* Rename notification-flow-thanks-flyout to notification-header-flow-thank
and shift parameters around; this one did already have GENDER support
for the thanked user
Depends on Idb975feaec in Echo.
Bug: T116847
Change-Id: Iab0f2311e7ffb6a9ce21cd76e564511d03805530
Not sure exactly how the fatal was being triggered, but getTitle()
is documented to return either null or Title, so we should actually
guard for null values.
Bug: T104689
Change-Id: Ic45bbcc71291dc473cd65a48d1840a78d5b64ae1
This patch will only enable the API module 'flowthank' if Flow is installed,
instead of checking whether Flow is installed when the module is invoked.
Bug: T85521
Change-Id: I0183188dd17f035f3c89e40a9cb1a21421071aca
thanks-thank was using plain, but this did not get caught because
the en value did not have a no-op example GENDER. I've added
these to all of them, for both $1 and $2. This also tells translators
they're both available.
Bug: T96527
Change-Id: I5130bbd60fe3c1c8051729758c2f2f4bea2b2030
Retrieve gender data for the thanked user for i18n message parsing
with the correct {{GENDER...}} data.
Bug: T96527
Change-Id: I14c831be51482682f2b628a15c79341a4f372c16
* Flow no-longer allows arbitrary html insertion, so remove
* Update ext.thanks.flowthank.js to work with thank links generated
directly by flow.
Change-Id: I8ae14352f1b177446f3696ffadd6921a5125238e
Change the UI to ask for confirmation instead of allowing the user to
change the revision ID, disallow using Special:Thanks directly, and add
support for Flow Thanks.
Bug: 63509
Change-Id: I48ef5e51fd3ac76ff5caf6907bc53d09357634bd
Relying on UUID::__toString() now triggers a notice, causing
unrelated patches to fail. This patch addresses the issue.
Change-Id: Ia94826a0e600adf8afd5908af75772b596ab8d0a
To prevent thanking someone for the wrong revision, don't show the Thank
button unless the old revision is the parent of the revision being thanked
for. This needs I6ee956c5 in core to function, but it degrades gracefully
if it's not present.
Bug: 57721
Change-Id: I8f973a8a54db35838ce4c697c0310f67b2dba1a0
When viewing a thank message, make the link to the diff the primary link.
Visiting the user's user page is almost never the desired action when
viewing a thank notification. The link to the user page is no longer
present as a secondary link, but the notification-thanks-flyout2 and
notification-thanks messages both include a link from the user's name to
their user page.
Bug: 56225
Change-Id: If971385e6d1a47e394d06decf25db2c1b7cc2fb9
If the user has already been thanked, make the button greyed out
and display the text "Thanked" instead of "Thank".
Dependency: Ife9f456a7a9cf74b1b54fdc6128feb230fd6f671
Bug: 59828
Change-Id: Ifab78fe62910c9c3f2a927a6a4bbe28fb953b160
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
Also making thank button for mobile capitalized.
Also update for new clickTracking code.
Also promoting to stable.
Dependency: I56e2c5bc69f85e83ab3dfd9b9e617dbb98661870
Change-Id: Ifaf44fe8994a8085c30522292bba8b768da533db
If the new $wgThanksConfirmationRequired global variable is true,
require users to confirm that they want to send thanks.
Bug: 47658
Change-Id: I4663844a324a2797917b027ceb1c8c07b1e180d5
