- User Since
- May 28 2015, 6:16 AM (408 w, 6 d)
- IRC Nick
- LDAP User
- MediaWiki User
- Arseny1992 [ Global Accounts ]
Dec 16 2018
Where does that is supposed to log to? Logstash? On-wiki log that is accessible to functionaries (if we want to do T210919 and T209749)? If so, then the messages shall be localizable and not be hardcoded in code.
Dec 11 2018
Nov 27 2018
Up next might be compromising a steward and global lock everyone else out before losing permissions, but if you can't log in, have fun identifying yourself to operations to restore access, and deal with the attacker. Securing permissions with e.g. OATHAuth is a problem if the authenticator key gets compromised too, though that's less likely, therefore its favored that sysops be required to use OATH, IMHO
Sep 17 2017
Nov 30 2016
Assigning per patch uploader
Closing per SAL entry above
Nov 22 2016
Nov 16 2016
- If a compromised sysop blocks all other sysops/crats, there have to be ways for the other sysops to unblockself and stop the compromised account
- Stewards don't usually deal with users of private/fishbowl wikis via userrights-interwiki . Some of the wikis (T131385) can't be managed this way. Emergency way in such a case, is having staff to promote self if on-wiki sysops aren't around
- If a sysop blocks self for any reason, there is no point to allow to unblock self. Possible way to achieve this is to look in the last log message to see if its a self action
Nov 15 2016
Nov 14 2016
@Pamputt please confirm if that's what you meant to do and if yes, confirm if it's working as expected
Nov 13 2016
Nov 12 2016
Yes, fallback, and is to be translated.
Nov 10 2016
Nov 8 2016
@TheDJ because the initial point of T132972 was to revert this site-wide special default behavior. If we're going to revert this back to T13776 's way, then it'll be as if T132972 didn't happen.
Closing because since the special site-wide behavior was reverted in the subtask, there's no longer a special site-wide configuration other than default mode=categories that this task refers to.
Nov 7 2016
Reassigning since otherwise the task will be stalled on for years if not dealt with. Months passed but there is no logo:
So to summarize, @IKhitron wants to user-override the categorytree expanders (mode=all) while browsing a category page (on the page, and not the special page, although it has the same default behavior) without setting it (mode=all) as site default for all users on the wiki while the default is mode=categories , without having to URLhack the page every time. Normal browsing case across categories.
Nov 5 2016
Default is to show only categories. Per ^ a preferences option is wanted for user own override from site default option so that the user won't have to select view mode on Special:CategoryTree every time you open that special page.
@Kipod Special:CategoryTree has a setting to show only subcategories, only pages that are not files, or all pages, if you didn't notice.
There's a difference between viewing subcategories and pages outright on the category page itself (the default is indeed to expand only subcategories) and viewing the subcategories via the category view link that goes to Special:CategoryTree/desiredcategory that shows also included pages when the All pages viewing mode is selected on the same page.
Nov 4 2016
@Dereckson we do allow granting by sysops on most wikis, and the relvant newiki config is here
@Cumbril much better. Point the above claim on the local community, and decide which rightset autopatrolled are going to have, if different from default (autopatrol to autopatrol own revisions). Hewiki for example let autopatrollers see Special:UnwatchedPages.
first proposed creating Autopatrollers group and right – to have some right that can be used as a flag. But then I thought, why use autopatrol right if the Mediawiki software allows creating any arbitrary right.
What are the downsides of creating a new user right (other than being useless for true security)?
Nov 3 2016
@Aklapper : I chose Create Subtask straight from the parent task. Subscribers, assignees, projects were pre-filled and carried over.
Nov 2 2016
Reopenng due to T149840
I referred to the variable, not you as logos-creator :D
$wgLogo doesn't eat SVG logos directly, but PNG versions of them. So create png logos for $wgLogoHD that should be clear and highres enough (cc T145017) and update commons page accordingly ;)
Nov 1 2016
Smell like another instance of what we're been already seeing with trwiki, trwikiquote (T144638), and ruwiki (T144599) asking for new permissions groups to delegate rights based on classes of editors. Remember that sensitive rights such as editinterface, gadgets-edit, gadgets-definition-edit, editusercss, edituserjs are not to be grantable by sysops . According to w:et:ListGroupRights , so-called "tools" are actually gadgets.