Tue, Sep 19
Sun, Sep 17
:D I'll change them to read-only again.
https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/WikidataEntitySuggester is not listed above (in the Gerrit project list) :P Re-activated it. I also re-activated all others.
Ah damn :D Sorry, just saw my change merged, and I thought I uploaded one to change NewPages, too (as I saw my example image) :P Thanks for pointing to this @Ladsgroup :D
To be honest: My vision is, that there's an on-wiki way to configure MediaWiki ("configure" -> change configuration options), like a special page providing that functionality (where extension and core settings can be viewed and changed by recognized groups (read: groups with a special permission).
@MarcoAurelio I changed the repos back to "Active", so you can add changes to them now (I'm not doing it, as I don't have time now, and I don't see a reason doing it :]). Please give me a hint, when you're finished, so I can mark them as read-only again :)
See also: https://gerrit.wikimedia.org/r/#/c/18201/ (removed from WMF wikis)
All Gerrit repos set to read-only. Can't do the Diffusion repos :)
Sun, Sep 10
Tue, Sep 5
Can not do the Diffusion repository :)
I must agree with @matmarex: The code hasn't change since 3801a3cd288f01694e9953bd5fdc070e561078f7, as far as I can see, so this is unlikely to have worked before (in a recent version of MediaWiki). However, I think this is a valid request, and it's reasonable to minimize the needed amount of work/clicks for the user to get what he/she wants. And if we show the "You need to log in to view this page" is visible as a warning on the login page, there shouldn't be a big problem.
Sat, Sep 2
I assume, that you ask, that Wikimedia wikis should use reCaptcha, right? I remove the ConfirmEdit tag, as ConfirmEdit already supports the reCaptcha service, and it just has to be included in the configuration (instead of using another CAPTCHA module), so there's nothing to do in the ConfirmEdit extension :)
Fri, Sep 1
Wed, Aug 30
Mon, Aug 28
The revert of the change 50d7546057c1089228a2a6d7d4a49d78d72887e3 was caused bywhich should be fixed with https://gerrit.wikimedia.org/r/371947 I re-created the change with 29a5fc72e3ab7d3da28bc4cc91d4bb051b9a690a and made it dependant upon the change in ConfirmEdit.
Thu, Aug 24
Puhh, not sure anymore, why I added it, so no.
@Legoktm: I'm pretty sure, that I already was able to add and remove members from groups where I'm a member of, and it was not something special like pywikibot or something. From the description of the single user group plugin (I haven't found a single group plugin) it doesn't sound that this plugin provides what is asked in this task.
Aug 20 2017
One member of the Administrators group in gerrit can/have to do this. I added the Repository-Admins tag and added two action items to the task, which need to be done to resolve this task. However, we can just wait now, sorry :)
Aug 19 2017
This was already fixed in T144705: Password reset link is shown when no reset options are available and is available in MediaWiki 1.28. As MW 1.27 is a LTS release (I assume you're using 1.27), I cherry-picked the change to the REL1_27 branch, however, it's up to Release-Engineering-Team if this is something which will be in the release of the LTS version or not :)
I remove the MediaWiki-Authentication-and-authorization tag, as this is already possible with the AuthManager framework. You simply need to subscribe to the login audit hooks (https://www.mediawiki.org/wiki/Manual:Hooks/AuthManagerLoginAuthenticateAudit or https://www.mediawiki.org/wiki/Manual:Hooks/LoginAuthenticateAudit for pre 1.27.0) and do whatever you want to do there (e.g. log the failed/succeeded login attempt into something or somewhere). This, however, should be an extension and not part of MediaWiki core I think. If you want to implement that, you can probably take a look at the LoginNotify extension: https://github.com/wikimedia/mediawiki-extensions-LoginNotify
I agree with what @Tgr said and want to also note: What happens, if OATHAuth is not the only Secondary provider, which requires, for some users, more input data? In the worst case, you get multiple input boxes on the login form, which are only meant for a specific, different, subset of the users using the wiki, depending on if a specific security feature is enabled for an account or not.
Aug 15 2017
Aug 14 2017
@cicalese (:P) Damn, sorry, I thought that this is possible to change the group membership, but it seems, it'snot (anymore). I filed T173337: Can not change group membership in gerrit as a group member anymore for that. Until then, we need to wait for a gerrit admin :) Sorry for the confusion!
It seems only members of fundraising and Gerrit admins (?) can set the gerrit repos to read-only (I can only change repos under mediawiki/* to read only).
Who is "Cindy" and why do you want to request the ownership? If you want to collaborate, you do not need to be an owner of the repo, and if the owner wants you to be able to submit changes (~+2 in this repo), he/she can give the permission through the gerrit UI :)
Aug 13 2017
Aug 9 2017
Aug 6 2017
Sorry, I first had the impression, that the prefix URL parameter is handled in MediaWiki core, which then would be something, which is not implemented in VE. However, it is handled by InputBox itself, but only for the edit action, not for the veaction edit. I'll upload a fix for that.
That's an issue of VisualEditor, as it does not handle these kind of editor options, not an issue of InputBox :)
Aug 4 2017
Removal from mediawiki/extensions: https://gerrit.wikimedia.org/r/#/c/370147/
Removal from integration/config: https://gerrit.wikimedia.org/r/#/c/370148/
No configuration found for this extension in translatewiki.net
Jul 31 2017
I'm not completely sure, how Attributes in extensionr egistration work, however, how would a wiki sysadmin disable a trigger, if it is automatically assigned by an extension with an attribute?
Jul 30 2017
Ok, thanks for the explanation! That makes a bit more sense now :) But if I provide the ID to the API request, the site parameter isn't used, and shouldn't be mandatory in this case, right?
Jul 28 2017
It's not deployed, yet, on Wikipedias or other Wikimedia projects, so it does not work there for now. However, it will be deployed with the version 1.30.0-wmf.12 (like mentioned by @ReleaseTaggerBot), which will most likely land on Wikipedias at Thursday, 03 August 2017. You can already test it on betalabs:
Jul 27 2017
Jul 25 2017
Ah, haven't seen that as I was writing my comment :]
Hi @Recetion123: Yeah, I've to say, that I forget the comments from @Krinkle (sorry for that, again! :(). I've abandoned my first idea (not completely, but no changes are required in the extensions anymore), and updated the change to MediaWiki core (just for information for you here, so that you're not confused by the abandoned messages here :]).
Aha, interesting, I haven't thought about that so far :)
Jul 24 2017
Some more +1 would be good, however, the other contributions seems to speak for themselfs: +1! :)
I'm pretty sure that we (usually) do not delete any git repository, right @Luke081515?
Jul 17 2017
Jul 13 2017
Why should Special:Random return random pages just from a specific category (e.g. in a specific languag)? That could mean, that in some cases, Special:Random is not random anymore, because pages are selected by specific user-properties :/
Ok, from what I can see:
The "Special Page" tab correctly links to the Special page (including the name of the page being investigated). Or do I misunderstand you here? What is your expected behaviour?
The limit is enforced. That means, that the comment of the revision can not exceed 255 bytes (that is also the limit for the field in the database, iirc). However, there's some auto-generated stuff when you move a page, too (something like "Username moved page Title to NewTitle:" which also counts within the 255 bytes limit). My guess is, that the 200 characters limit is choosed to have some free space for the auto-generated message. However, this means, that, at least that's what I read from the code, if I haven't missed something, that you can still run into the problem, that the reason message is cut off, if the generated text combined with the user-defined reason is longer than 255 bytes.