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
Add a 'block' Pinia store to house all block-related data use in the
SpecialBlock.vue application. Minimal refactoring is done to make use of
the store, rather than passing around props.
UserLookup is reworked to only update the store's targetUser property on
a 'change' event, since the Codex Lookup component wants a "selection"
while we want to allow arbitrary input. This means anything that listens
to changes to the targetUser isn't fired off too quickly (i.e. API
requests, or flashing error states).
Other changes:
* Remove 'disabled' attribute from ExpiryField as the disabled state is
applied automatically.
* Change SpecialBlock.test.js to test against a date that's not a mere
decade away.
Bug: T376741
Depends-On: Ia88d987bf7e5afa1a17d63b4ebc96448ccec2f6c
Change-Id: Id6cff21eeeeb86876e59f70994ad10658ab6d9be
Added "Show the table of contents" ARIA label for the button when the TOC is hidden.
Added "Hide the table of contents" ARIA label for the button when the TOC is displayed.
Bug: T336098
Change-Id: I922dc12287c241d6937acad0d9ec12eccc439014
Set a distinct style on the "no reason given" message
Set `aria-label` to clarifying message for screen readers
Bug: T376746
Change-Id: I7d0f73ff7031f9d08f488a580681ccc8b7c3d93c
Remove the "target" column
Add a column "type" with fields "Blocked"/"Unblocked"
Add Jest test for TargetBlockLog
Bug: T368111
Change-Id: I3e9145df62046baaa3fe762a6f57c932a976508c
We leverage the native browser validations for most fields (i.e.
`required` attribute on TextInputs). After form submission,
the user is brought to the erroneous field and given browser-provided
validation messages, displayed using Codex.
Browser validation may later be upstreamed to Codex (T373872), after
which we won't need ValidatingTextInput, or the custom handling in
UserLookup.
ExpiryField was written prior to CdxRadio supporting a custom-input
slot. Rework the CdxRadios in ExpiryField to use the new slot, and
apply `status` and `messages` to the nested CdxField instead of the
entire ExpiryField, so that validation states are applied only to the
invalid elements.
For now, there is only one other custom validation that cannot be
provided by the browser: requiring a selection for "Preset duration".
Validation logic is contained within ExpiryField, but since this field
doesn't effect `checkValidity()`, we need to check the expiry value in
SpecialBlock.vue on form submission. This is necessary since we don't to
show error states when the component is first mounted.
Also make tests a bit more DRY by adding a new `getSpecialBlock()`
method to the setup file.
Bug: T369471
Change-Id: Iff340e8747329678b80ca00c768fabec2c194320
Change the edit recovery prompt to ask before recovering the
saved data, instead of recovering and then asking whether to
revert the recovery.
Also change the button's to the shorter text, and so remove the
need to have them on separate lines.
Bug: T364664
Change-Id: I05e53f302a80a9ad8223d4d2cacf2ca5fca6cc65
This adds a new message box for successful messages, and reworks the old
one to handle all error messages.
Error messages are inline for now (like the old Special:Block). Note
these are only the server-side messages, that chiefly serve as a
fallback for clientside error states which will be tackled in a future
patch.
A loading state is added for the block API request by simply disabling
the form fields. Once completed, the user is scrolled to the top to view
the appropriate messaging. This uses "smooth" scrolling so that it's a
bit less "in your face", but this is subject to design review. For now,
it's just important the user is brought to the approriate error message.
Other changes:
* Add a bit of left margin to the inline error message, consistent with
the no-JS version of this page. Without this, things "jump" a bit as
the Vue applicaton loads. More refinements for this to come later.
* Fix styles for .mw-block-partial-options to be exactly the same as
Codex labels.
* Remove unnecessary IIFE from init.js, and add a class to the form
so we can style it closer to the designs.
Bug: T369471
Bug: T358934
Change-Id: I47344e9581439289642c9424a5f229929805cdbe
* mw-ui-vform-field is no longer used in practice - the only consumer
in core was the account creation form but that's now Codex. The
message box markup is no longer supported so we can just remove
this code.
* mediawiki.hlist is only used in Minerva and Collection extension
and neither puts a message box in the message, so this old markup
can be removed.
* Fix display of messages in the live preview feature
Bug: T375287
Change-Id: I623c2798a7ecbb32a20d2a4235ee9143b2da8b33
Most of the purposed changes to replace mw.Uri to URL has went smoothly
so maybe we can consider this now so at least no new uses would be added
to it.
Bug: T374314
Change-Id: I532e893b817fe760f0f45883187d4f29edf47b69
Since legacy skins do not load the full version of Codex, many
Codex message box appeared unstyled on pages which call
functions using Html::messageBox
Legacy skins do not load Codex by default, so these should be
explicitly added by the interface using them. Since there are
lots of these, for now we'll do this in the skin to avoid
breakage.
For skins supplying Codex via other style modules,
this will be negligible because of gzip, they will also be
able to remove the style if necessary.
Bug: T373602
Bug: T375246
Change-Id: If3c2d26de3faa9f85025ea8643d97242cad27574
SpecialBlock calls HTMLForm::setSubmitDestructive(). This patch applies
that to the new Vue version of Special:Block.
Additionally, since we're not going to enable multiblocks in the initial
launch, the submit button message is changed to as it was before. "Save
block" is questionable even for multiblocks. It will likely be a while
before we iron out the UI for multiblocks, so we might as well remove
now-unused 'block-save' message.
The "[username] is already blocked" message is now also surfaced, i.e.
browsing to [[Special:Block/someblockuser]]. Like the old Special:Block,
changes to the block target field won't re-query to see if the user is
already blocked (though that would be a fine improvement). However
*unlike* the old Special:Block, such changes do make the message
disappear.
Bug: T373572
Change-Id: Iceaedbb1e3496c52b49a2b96d65445da45261b9f
This doesn't touch UriProcessor of the module that has become a wrapper
around mw.Uri but just simpler uses of mw.Uri which could be replaced
before that.
Bug: T374314
Change-Id: Ic60fdd56f38bd438ba7f005cc1b220b279a26cf9
Add Html::listDropdownOptionsCodex() that takes a bulleted list like
[[MediaWiki:Ipbreason-dropdown]] and adapts the data struture for use
with a Codex Select component.
Currently optgroups are not supported (T367241) so we show the optgroup
labels as disabled options instead.
URL query string parameters do not yet prefill any fields. This will be
tackled as part of T368583.
Bug: T362912
Change-Id: Ib89dcf35ca2a1cd74404c42f5411d7c095b98952
This uses a new three-part form to allow the features of manually typing
an expiry (i.e. "31 hours") but allowing to do so for non-English users,
who previously didn't have this capability unless it was set in
MediaWiki:Ipboptions. The ability to use MediaWiki:Ipb-default-expiry to
set a default expiry is still supported, assuming it is either a valid
option in MediaWiki:Ipboptions or in the new "Custom duration" field
(i.e. "31 hours"). See https://w.wiki/B65S for more, though this
functionality doesn't appear to be used anywhere on the WMF cluster.
"Expiration" is renamed in the code to "Expiry" to match the naming of
other MW components (ExpiryDef), but the user-facing message is still
"Expiration".
No validation is done yet, but will be added in a future patch.
Similarly, pre-supplying values via URL params is saved for T368583.
Bug: T359684
Change-Id: Iffb6fa3f539d29ed25802a19f4c13c627208259c
Deprecated since Iaf7bd2986b7f4185923969899d61878e5ee5905b
and no longer it seems used in Wikimedia codebase or gadgets in
Wikidata or Wikimedia Commons, there was one userscript
in English Wikipedia (not a gadget and was in User: namespace),
which I notified them they can just use Vue module.
Change-Id: I0a45d97866519765be5c3bdff9c0a20b003f78ae
This removes the use of deprecated mediawiki.icon module from
mediawiki.action.edit.collapsibleFooter, the only use of
the module in MediaWiki core.
It also adds a small animation for the toggle icon.
Bug: T351681
Change-Id: Ie22ef2a91a57116a6a2deff7a8d938db294ee40c
Many changes tags added by extensions include links in the 'tag-<tag>'
label messages, which point to help pages for the tags and the software
features that add them. This makes translating the labels unpleasant.
Introduce localisation messages like 'tag-<tag>-helppage' (following
the pattern of 'tag-<tag>-description'), which should contain a URL
or a page title of a help page for the given tag. When such link
message is defined, the tag description in changes lists, history
pages etc. is wrapped in a link that points to the given URL or page.
Unlike the label messages, the link messages are always used in wiki
content language, for easy on-wiki customization. For compatibility
with old translations and existing on-wiki overrides, if 'tag-<tag>'
already contains any links, 'tag-<tag>-helppage' is ignored.
Add buttons that allow editing the new links on Special:Tags. Correct
existing buttons that allow editing the labels to use user language.
Add help links using the new messages to the changes list filtering
interface (which can't display links in tag descriptions themselves).
Introduce a link message for 'mw-contentmodelchange' tag as an example.
Bug: T372175
Change-Id: I1e2242a8591597a110a5a430f4c251f0f601cfbe
