Fix regression from 9af38c046c, which made 'from' a required
non-empty parameter where previously an empty value was allowed.
The rollback links always include a 'from' parameter, but it is
set to an empty string by Revision::getUserText if the current
revision has its username hidden.
Test plan:
* Go to action=history, tick latest revision and "Change visibility".
* Tick "Editor's username" and apply the change.
* Hit "rollback" on the history page.
* Before: "missing parameter" error.
After: Success.
Bug: T141985
Change-Id: I20d23e2aeec858f82231910c030c14ffa3af656f
Ideally this never happens, but it can, so fail gracefully instead
of just throwing a 'call to a member function on non-object' message
Change-Id: Iac8be9c7994aa3e74ed3c0eecff211524037165e
This partially reverts commit 9af38c046c.
* The new JS modules continue to exist. While not used by default,
the mediawiki.api.rollback may be used elsewhere by now.
The mediawiki.page.rollback module may still be used on cached
pages and should continue to work.
* The new API behaviour remains.
* To avoid breaking mid-air rollbacks again, the token remains
the same (plain "rollback" salt). We're not re-introducing the
web-specific salt again.
Bug: T136375
Change-Id: Iba17ce55ff9506e838bfc6e70ca280e5a20b77b6
Similar to WatchAction (converted in commit 77cdf1919).
* Make FormAction::getFormFields not abstract.
In most cases this will just be an empty array.
* Convert RollbackAction from FormlessAction to FormAction and implement the
required error handling scenarios (mostly moved out of from the old method, or
duplicated from the WikiPage method where necessary).
* In most cases the in-between form is never used since a JavaScript handler
takes over the link and uses the API over AJAX instead. In the no-js fallback
(as well as for any existing tokenless rollback links) copy the GET parameters
into the form for re-submission as POST (plus token, added by HTMLForm).
* Remove the distinction between WebUI and API tokens. This stronger token salt made it
unnecessarily complex and was only there because it used GET until now. This streamlining of
tokens matches what we already do for 'watch', 'edit', 'patrol' and other actions.
* Fix form submission bugs when 'from' query parameter is missing.
- Ensure the required 'from' query parameter is present before showing a form.
No need for the user to submit a form we know will fail.
- Plain GET request to action=rollback (with no parameters) is now a 400 Bad Request
instead of a form that would fail when submitted.
- Submitting the form without 'form' field now correctly says why it failed.
Previously it emitted a session error, which was a lie.
Bug: T88044
Change-Id: Ia457802fec2e90573c8e7d552bc1f3cee258f10b
This also removes assumptions that when a page
in one Namespace should be watched / removed
that the page in the talk / subject ns for the
page should have the same action applied
This should maintain all backward compatability
for the WatchedItem class
This also includes tests written by:
- WMDE-leszek
- Addshore
Bug: T127956
Change-Id: Iad9abafe4417bb479151a3bfbee6e1c78a3afe3c
* Potentially long running POST requests often use multiple transactions,
talk to multiple services, or defer updates. Try to make sure they have
a chance to complete all of the work. WMF already sets ignore_user_abort()
across the board in config, but this applies it to key spots for all
installs, in addition to bumping the time limit.
* Eventually this can lower the need for high overall time limits.
Bug: T102890
Change-Id: I893ddd773064dcd63b5b24c84c6391974f4b5aee
This change adds a preference in the 'watchlist' section to
automatically watchlist a page after rollbacking.
The setting is only visible, if the user has the 'rollback'-right.
I have removed the watch reverts function per advice by Vogone.
Bug: 4488
Change-Id: I3aa831c9c04d627684641af0ca5a332795c87062
Rollback will now show the actual errors that caused it to fail,
instead of a misleading message about permissions.
Also, errores returned by WikiPage::doEditContent are now propagated
and shown.
Change-Id: I5a3f8cb7a0b881d07d52f63504dd3757192205a9
* PermissionsError now calls OutputPage::showPermissionsErrorPage() to display the error (this is needed to make the item above work correctly)
* Removed the override of the HTML title in OutputPage::showPermissionsErrorPage() so that it shows "Permission errors - Sitename" instead of simply "Permission errors" for consistency with the other things
* Pass the error array returned by Title::getUserPermissionsErrors() to PermissionsError where available
* Converted direct calls to OutputPage::showPermissionsErrorPage() to throw an PermissionsError error instead
* Added 'action-rollback' message that will be displayed when accessing action=rollback without sufficient rights
* Changed getRestriction() in subclasses of Action to return null when they previously returned 'read' so that user rights can be check with Title::getUserPermissionsErrors()
* Reordered checks to do first user rights, then block (if needed) and finally read only (also if needed) so that users don't think the error is temporary when they both don't have right and the database is locked
* Removed OutputPage::setPageTitleMsg() and OutputPage::setHTMLTitleMsg() and make OutputPage::setPageTitle() and OutputPage::setHTMLTitle() accept a Message object
* Updated core calls (including some that I missed last time because of non-matching case)
* Added Message::setContext() and use it in RequestContext so that I don't need to duplicate the call in OutputPage
* Yes, I'm calling $this->msg() on places and then setting the context one more time in OutputPage::setPageTitle() or OutputPage::setHTMLTitle(), but at least I won't be confused about which objects $
