Why:
* Special:PasswordReset allows users to send an email containing
a temporary password to the email address attached to an account.
* Temporary accounts do not have passwords and cannot have an email
address set (as they cannot access Special:Preferences).
* Therefore, Special:PasswordReset does not provide holders of
temporary accounts a way to get access back into the temporary
account if they loose access.
* However, the form currently accepts temporary account usernames
and we should update the functionality to reject such usernames.
What:
* Update SpecialPasswordReset to reject temporary account usernames.
* Expand tests for SpecialPasswordReset to check this fix has worked.
Bug: T380085
Change-Id: I004453d4d16cd2a0448ac3922e4d13c24a158c8d
(cherry picked from commit e27be818690820c0df227cb06206da499eb94d38)
The special page is not public accessible and
is not allowed to transclused in wikitext.
In 077e3057ff the special page extends ContributionsSpecialPage that
extends IncludableSpecialPage and makes this includable.
Bug: T378727
Follow-Up: Ica817be5c5e078b88c9b3157b54d0dbf997e8893
Change-Id: I34a557e28d288d56679b1c99f8607597207ed14a
(cherry picked from commit 523de9ec3be373feb2a8b5e65eb3a1d554e73d44)
Password policy settings 'value' can be a number, boolean or a null
But only number needs to be passed to the corresponding policy
messages (to be output). Boolean and null represent the message
assertion and are not output in the eventual message string (the
messages do not have parameter).
Values with false and null are already skipped, so this change only
affects values with boolean true.
Bug: T378133
Change-Id: Ib9e6f7ed14f9982f9d2350ccd7b212f0fbf10477
(cherry picked from commit 41a9230775c569833911cb3cdb41c651013df04c)
Do null-coalescing at call site since the function already
expects these arguments to be strings
Bug: T377916
Change-Id: I1bf57646b5a4ef03d49d178e0e75d4e61cf90c00
(cherry picked from commit 6f5777fe5ab48e4b3bf25ebd2dcc9ebf0e2d1fa6)
Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: I73fb416573f5af600e529d224b5beb5d2e3d27d3
Add SpecialWhatLinksHereQueryHook hook that allow extensions
to modify the query builder to add more conditions based on
the filters added in the SpecialPageBeforeFormDisplay hook.
Bug: T216368
Change-Id: I221d4e0ad671feab6937719d4a2f894ad6154bb1
Replace FormOptions with array based form data instead of FormOptions
and specify defaults when defining HTML form fields. We prefer using
form data since values for HTML fields added via
SpecialPageBeforeFormDisplay hook are available in this array but not
in FormOptions.
When extensions add fields to this page via
SpecialPageBeforeFormDisplay or ActionModifyFormFields hook, they can
access the value of the added field via the form data using new hook to
perform custom filtering.
Bug: T216368
Change-Id: I313b595ccbcf0650fceffc5bfd31bc245aca0237
- Replaced class properties with typed properties.
- Updated `$template` to `string`.
- Updated `$text` to `string`.
- Removed redundant type comments.
Change-Id: I53ff765949b8df978b189bd63306ed380a75c912
- Replaced class properties with typed properties.
- Updated `$msg` to `string`.
- Updated `$lines` to `array`.
- Updated `$html` to `string`.
- Updated `$selected` to `?string` (nullable).
- Removed redundant type comments.
Change-Id: Iebfeda2a29d41cde0a0d7559757075973228bfa1
Fix two problems that made it difficult to convert between Message
and MessageValue, or to write code that could accept both of them,
as exemplified by the StatusValue class:
* Implement a common interface
* Use the same internal format for message parameters
While these changes should be compatible with most of existing code,
where the authors were courteous enough to simply call methods such
as Message::numParam() and not look inside the values they return,
it is potentially a breaking change for anything that depended on
the formatted params being arrays or accessed their keys.
Example patches: https://gerrit.wikimedia.org/r/q/topic:message-param
Notable changes:
* Message and MessageValue now both implement MessageSpecifier
(only Message implemented it before).
* Message::numParam() and other static methods for encoding params
now return MessageParam objects, instead of special arrays.
Use these MessageParam objects internally in Message.
* Narrow down the return type of MessageSpecifier::getParams() (it
was just `array`, allowing any type in the array). Narrow down the
types for Message::params() and MessageValue::params() to match.
* Deprecate MediaWiki\Message\Converter. As a replacement add
MessageValue::newFromSpecifier(), which is analogous to
Message::newFromSpecifier(), but without weird legacy edge cases.
* Make StatusValue::getMessages() return MessageValues. Remove code
that converted between Message and MessageValue, no longer needed.
* Update many type declarations and comments to use MessageSpecifier
instead of MessageValue, as well as a couple of tests that depended
on implementation details.
Bug: T358779
Change-Id: I625a48a6ecd3fad5c2ed76b23343a0fef91e1b83
- Added GNU GPL license header to ContributeCard, ContributeCardAction,
ContributeCardActionLink, ContributeFactory, and ContributeCardsHook
- Use typed properties in ContributeCard and ContributeCardAction
- Removed redundant docs for properties now using typed declarations
Change-Id: Ifb962f15fd08b2415e6877502b90db4ad1bdfcbe
Jest tests don't cover PHP bugs :-P
Before, passing in the URL param wpExpiry as '3 days' or 'infinity'
wouldn't parse. Now it does. Add tests for reinforcement. The assertions
against `$fields[ 'EditingRestriction' ]` aren't that important and have
been removed to make use of the data provider easier.
Bug: T368583
Follow-Up: Ibc648117e6d4981c84e9df9f933ba033d339e908
Change-Id: I8070c90a535cac8715dcdf588c62aab14861a2fc
These use the new CdxMultiselectLookup component.
Values for the two inputs can be pre-filled with the
'wpPageRestrictions' and 'wpNamespaceRestrictions' URL parameters.
Tests to be added in a future patch (along with other tests around
partial blocks).
Bug: T362718
Bug: T362912
Bug: T368583
Change-Id: I53739bcdd63870fbfb57bc96298fc8d467bdfc2b
Special:Block is supposed to show a 'Confirm block' checkbox under two
conditions: if the 'hide username' option is being used, or if the user
is blocking themselves.
This patch takes the SPA-like behaviour a step further and will disable
the submit button and show the confirmation checkbox if the user target
is changed to the current user, or if the 'Hide username' checkbox is
checked. The logic of hiding the confirm checkbox and re-enabling the
submit button should follow the same rules.
Add `withSubmission()` helper to SpecialBlock.test.js and add test cases
for the newly added code.
Bug: T376754
Change-Id: Ie990051ae62b11f3a27bbc4cfc5c714a0096e2f3
Implicitly marking parameter $... as nullable is deprecated in php8.4,
the explicit nullable type must be used instead
Created with autofix from Ide15839e98a6229c22584d1c1c88c690982e1d7a
Break one long line in SpecialPage.php
Bug: T376276
Change-Id: I807257b2ba1ab2744ab74d9572c9c3d3ac2a968e
* Remove private $method that was never read
* Swap private $result to local variable
* Doc and comment tweaks
Change-Id: Ief100be748aac3537d5c1db8720e543ffd3e1995
processForm, parseExpiryInput and canBlockEmail are deprecated since
1.36.
getSuggestedDurations is deprecated since 1.42.
Depends-On: I5931525f95ff6eb76a2b30aa7a852cc86075276f
Depends-On: I6a570e503fee6676e7c54beb6f37575058a57339
Depends-On: I6890763dbe30cc33b2715e93c59cee331d8967b1
Depends-On: I99f49dd3f20032848cc7a191a6b46c5816f3bff2
Change-Id: Ibbf51d9de168d97c0ed3c827f02a356c8a579987
Add wpEditingRestriction, wpReason, wpReason-other, wpHideName to
parameters that are allowed in the URL.
Bug: T368583
Change-Id: Ibf08eb8b4e44383407dbf4f9a30ef86a2b317276
A constant is not a variable. The type is hard-coded via the value
and can never change. While the extra @var probably doesn't hurt much,
it's redundant and error-prone and can't provide any additional
information.
Change-Id: Iee1f36a1905d9b9c6b26d0684b7848571f0c1733
We *do* need to call `$this->getOutput()->enableOOUI()` because the
Widget class still relies on it. This happens when there are errors
(`SpecialBlock::preErrors`), for example when attempting to block
yourself.
Bug: T358934
Follow-Up: Ia959d297ac9043804975f170eec66ddd4c1fe492
Change-Id: Ie7918726a074188e34a833a38a07f9639afdb571
Whenever possible content dir should be used for titles coming
from contents of a wiki rather than the user language UI.
And now that we are here let's set lang attribute also as the
links are in the content language while rest of the special
page uses user language, that can be useful for better font
rendering and so.
Bug: T375975
Change-Id: Icff7338ecd7b9686a596f5192b2d6666a32263da
Without this, providing no wpExpiry in the URL means you get the current
datetime :-P
Bug: T368583
Follow-Up: Ibc648117e6d4981c84e9df9f933ba033d339e908
Change-Id: I809af2f5ee82aad2e85bfee7499bfadee870312e
Instruct Special:Block to only load OOUI and the old JS module
when we're not using Codex.
Fix six year-old bug (from I20d11d7cc4) in mediawiki.htmlform's
selectandother.js where OOUI was incorrectly being assumed, causing
'Widget not found' errors at Special:Block when $wgUseCodexSpecialBlock
is true.
Bug: T358934
Change-Id: Ia959d297ac9043804975f170eec66ddd4c1fe492
With this change, the ?wpExpiry query param and the interface message
[[MediaWiki:Ipb-default-expiry]] accept only the following formats:
* /\d+ [a-z]+s?/ – such as "1 month", "2 weeks", etc.
* infinity values: 'infinite', 'indefinite', 'infinity', 'never'
* ISO 8601-like datestamp
In addition, [[MediaWiki:Ipboptions]] now requires an option be preset
with the value 'infinite'.
Rename `blockDefaultExpiry` to `blockExpiryDefault` for consistency.
Bug: T368583
Change-Id: Ibc648117e6d4981c84e9df9f933ba033d339e908
