User Details
- User Since
- Feb 11 2015, 5:47 AM (458 w, 6 d)
- Availability
- Available
- LDAP User
- Bugreporter
- MediaWiki User
- GZWDer [ Global Accounts ]
Today
Another potential use case is admins who are blocked with bot option can unblock self, which will solves T232908: Admins blocked by User:Abuse filter cannot unblockself.
Thu, Nov 23
Note since the Kazakh government introduced a new Latin script (latest revised in 2021), there are now multiple Latin orthographies for Kazakh.
Wed, Nov 22
Sat, Nov 18
Fri, Nov 17
Tue, Nov 14
Sun, Nov 12
Note It is proposed to change (most of) current proxy blocks to this kind of setting, which needs a global RFC in Meta; though no RFC is needed to make this feature available.
Thu, Nov 9
This can be turned back as an extension if needed by third party users.
Tue, Nov 7
Sat, Nov 4
Thu, Nov 2
Tue, Oct 31
Those are stable concepts in the platform
Once IP Masking is enabled any anonymous users will become registered on their first edit. only "named" user is a stable concept.
Mon, Oct 30
Per T139246: Migrate local group names to WikimediaMessages and T230103: Systematize wgRestrictionLevels it is not recommended to invent a new protection level not used in other wiki. The protection level and user group should be named extendedconfirmed.
Oct 29 2023
Oct 26 2023
Note once IP Masking is deployed there will be three classes of users to differ: named users, temporary users and anonymous users that yet to have edits on the project.
Oct 25 2023
Oct 24 2023
Oct 18 2023
First we need to have this feature, then we discuss how this can be used.
Wouldn't that mean that the large numbers of users (not logged-in, or not confirmed) receive a block message when they try to edit? To me this would count as collateral effect.
Currently checkusers may issue hard range blocks which block everyone without IPBE. If only non-confirmed accounts are blocked, the impact is reduced. In my previous comment, I also propose that most open proxies, which are currently hard blocked, may be changed to this kind of block; this require an amendment of Meta NOP policy and thus a global RFC.
Oct 15 2023
Oct 14 2023
Oct 12 2023
If you copy a cURL commend from browser console it will include all cookies for the request.
Oct 11 2023
Note Windows and Linux wraps parameter in different ways and thus browser usually provides two options for these two formats.
Oct 10 2023
What's the use case? Currently Translate extension stores different translation pages in different page language (page language is a core feature), and is it enough to get the language there?
What I proposed in T54971#3569663 takes another approach:
- Add column ips_virtual_site to wb_items_per_site, and then drop ips_site_id
- Create table wb_virtual_site, with columns:
Currently Wikibase suppose an injective relationship between item and local page, and there are mechanism and usecase for conversion in both directions. Once we can have multiple sitelinks to same site
- The page -> item is still a single map, though we need some code change to ensure this once we allow one item to be connected to multiple pages of the same site.
- But item -> page will not. In this way, if we does not provide a "primary" language for a site, parser functions and formatValue will break, since there are no defined meaning for the page connected to an item in a site.
Oct 8 2023
BTW (not directly related to this task), the hidden and suppressed status of global accounts is stored in gu_hidden_level column (added in T297094) and is a per user flag; while local suppressed status (ipb_deleted) is per block. For the latter, see also T346716: Split user suppression/hiding (ipb_deleted) out of the ipblocks table.
For usage in non-CentralAuth sites we may build a feature in MediaWiki core, but this (local) feature should be disabled if CentralAuth is installed (it may no sense to disable login of local SUL accounts).
Oct 7 2023
Global locks also prevent users from logging in. Until we solved T222281: Add a way to prevent user from log in and disable a users session when blocking and also have a similar option in GlobalBlocking, global blocks and locks should co-exist; compromised accounts should still be locked (and globally banned users may, though not must, be locked instead of blocked). Edit: to enforce global bans, what is more important is blocks/locks of banned users should not be able to be locally disabled, even if we can disable global blocks locally.
Oct 4 2023
Oct 2 2023
Sep 30 2023
Sep 26 2023
There are another one: Pages using DynamicPageList (intersection-category).
Sep 25 2023
Sep 24 2023
Sep 23 2023
Sep 22 2023
Using an existing right as protection level is not recommended; please introduce a new right. See T230103: Systematize wgRestrictionLevels
Sep 19 2023
I instead propose to replace pt_user, pt_reason_id and pt_timestamp with a new column referring to the logging table.
everything wanting a user list must join on ipblocks and filter by ipb_deleted.
In the new schema it is still the case: If we hide the actor of a revision a actor_deleted row is needed, though the user itself is not hidden, so we can not know the account hidden status without ipblocks. A new column in actor_deleted like ad_user_is_hidden may help. Note the ipblocks table in some wiki may be very large due to admin bot blocking proxies.
Sep 16 2023
Addition note (only my opinion): in principle, global locks is not better than global blocks, since locks is effectively a kind of block that local community can not control or opt-out, thus breaking community's self-governance. Japanese Wikipedia opted-out global abuse filter since it is out of their control and can not be disabled locally, but no wiki can opt out (any) global locks.
Sep 15 2023
Sep 14 2023
For fixing CLDR data, also ping @Nemo_bis.
CLDR seems to be defacto used as a repository for names for language codes that happen to be used by people. Not at all as an authoritative source for language codes. Are we ok with using it anyway?
What is that CLDR mentioned in the CLDR extension itself?
Note: The UserMerge extension would require different handling of blocks depending on whether we have multiblock. To reduce the long-term maintanence burden we may consider always allowing multiblock once the feature is stable.
T346293: ipblocks schema redesign for multiblocks propose to add a is_deleted field to actor (and one user may have multiple rows for different hidden status), and something similar may also happen in comment (though there is currently not a task for this).
In the WMCS database replicas, the actor_p view attempts to respect the denormalized field values by joining on every change-related table (archive, image, oldimage, etc.)
T346293: ipblocks schema redesign for multiblocks propose to migrate the suppression state to actor table. If similar also happens in comment field, rev_deleted will only concern the text.
The UI for hiding usernames is part of Special:Block. Blocking a user with the "hide user" option causes the user's name to be hidden everywhere. Unblocking such a user causes the user's name to be shown everywhere. In changes (revisions etc.), this is implemented by denormalizing the user-hidden flag into the *_deleted bitfield. In user lists, there is no such denormalization, so everything wanting a user list must join on ipblocks and filter by ipb_deleted.
Sep 12 2023
Gather feedback on Growth's proposed IP Masking approach to handling Flow boards: Logged out traffic can't post to Flow discussion boards until they have either logged into an account or created a Temporary account (by editing any non-Flow board). We will provide an informative message for logged out traffic that attempts to edit Flow boards
Sep 11 2023
Note: Currently AbuseFilter stores potentially non-existent user names as performer for account creation (including automatic creation) action, which is not supported by the actor mechanism. See T188180: Read from and write to `actor` table in AbuseFilter
Sep 10 2023
Sep 8 2023
Sep 7 2023
Probably I will write a longer comment about this later.
Also, the proposed "ultimate" list of language codes may be language-data library; See T190129: Consolidate language metadata into a 'language-data' library and use in MediaWiki for core integration and T281067: merge CLDR extension to core for proposal to fold CLDR to it.
See also T231755: Local language name should be translatable in translatewiki for localizing language names.
"semi-deletion" essentially means that the deleted page can be restored by anyone
(quoted to village pump)
A very old idea, T5843: Implement semi-deletion, may also be taken into account when we start to do this (it is not required, but a future schema change may make some reservation to make it easier to happen). Probably I will write a longer comment about this later.
English Wikipedia recently proposed this again.
Sep 6 2023
some people are really keen on having ability to share query results of WCQS/WDQS without auth even if it's stale. Like basically HTML of the result copied and stored somewhere.
See also: T104762: Setup sparqly service at https://sparqly.wmflabs.org/ (like Quarry but for SPARQL)