Wed, Mar 22
Another example on enwiki - going to a page with editnotices (e.g. https://en.wikipedia.org/w/index.php?title=Abortion&action=edit) using the source editor works fine - if switching to VE the notices are lost, manually looking for them in the triangle button says no notices. (Firefox, monobook)
Jan 30 2017
Jan 27 2017
Jan 9 2017
In Firefox 50.1.0 I don't see a key named network.cookie.maxPerHost - is the workaround suggesting to create this key, is so what datatype?
Jan 4 2017
I'd like to see an optional set of parameters for protection to solve this. 2 possible workflows:
Jan 1 2017
Dec 20 2016
Dec 19 2016
I'm not too picky on the "how" as long as the result is that information on if the password was correctly guessed is not revealed. Similarly, the authentication failed error message should not be different for bad token vs bad password vs bad both.
Suggested implementation would be to collect all authentication information simultaneously (userid, passphase, 2FA response). For accounts without 2FA enabled, simply ignore any (including null responses) to the challenge response.
Dec 16 2016
I'm not sure what dewiki is trying to do, but its a mess to readers right now who are seeing this:
Thank you for the note.
I suppose whatever parts the local communities want. If devs are pushing that only plain text and the variable will be supported for this interface then this (and the parent) should just be moved to won't fix.
@Anomie this is "by design" ?
@Legoktm it appears that both the use of #if statements, as well as wiki formatting like bold are no longer being processed.
Dec 10 2016
Related discussion with some examples:
For global renames: would be handy to have a "name history" - perhaps a seperate log request - e.g. given a current name, what were all prior names. This is available in the global rename log, but has to be recursively queried name by name.
@Legoktm thank you - verified it works for multi-action Global Renames as well.
@Legoktm no more of the opposite - entering only the "current" name should be able to find the rename log that made the current name come in to existence.
Adding "prior username" to the local move log would be fine and could be useful too
Possibly related to T40123
Possibly related to T152830
Possibly related to T152829
Dec 1 2016
Maybe the footer needs work too - that doesn't tell you if it came from say enwiki, eswiki, dewikibooks, etc
Perhaps something like firstname.lastname@example.org and include which project generated the mail? Examples:
email@example.com; firstname.lastname@example.org; etc./
Nov 24 2016
Our standard project settings don't give bots editinterface access - this has to be specifically added, project policies should be able to resolve your concerns - and if someone won't follow policy they don't get access.
@Krinkle BotPassword restrictions in general are working (for example I didn't enable rollback on my personal account and couldn't use utilities like Huggle that checked for it until I did).
Nov 16 2016
I believe it is time based - had you recently authenticated before attempting this?
Nov 15 2016
Community notified this is going live, baring any last min complaints here.
@Reedy I don't think this is really an OATH issue. This already is happening for certain sensitive actions such as password change and email change. This could be accomplished by simply requiring re-authentication in general for additional actions.
Nov 13 2016
@Reedy I'm successfully using BotPasswords with AWB already - what is this task about?
Nov 12 2016
@Bawolff - perhaps refactor this task to be about including a preference link ?
This does not appear to actually be broken. I just successfully un-enrolled an account that was no longer eligible to enroll. (testwiki:user:xaosflux_ep)
Note: If you create a BotPassword for yourself, you can use that to log on to AWB even if 2FA is normally enabled on your account.
Nov 9 2016
Shows that the enwiki community has not yet completed the migration of users for part 2 of this patch. Please push the deployment.
Nov 8 2016
No worries, I put out one final call for community objections on enwiki.
Nov 2 2016
That will likely be sufficient we should know in a couple of days.
As it is short on time - DELAY this patch - pending outstanding community activity noted at https://en.wikipedia.org/wiki/Wikipedia_talk:New_pages_patrol/Reviewers#Reported_issues_with_the_initial_NPR_grand-fathering_list
@Cenarium part two MAY need to be further delayed. While there are no issues with part-1, the community RfC for part 2 included getting a grandfathering process in for certain users - and it is being problematic.
Nov 1 2016
Wed night or Thursday should be fine.
The new group is present and appears to be working - thank you.
Oct 31 2016
Oct 29 2016
+Consensus-needed tag as it has been questioned
Oct 26 2016
That sounds best - this will move forward but having the overlap will avoid a break in service for potentially good reviews (it may be argued that breaking bad reviews is better but for a SHORT period it won't catch anything on fire).
Oct 25 2016
@Kudpung already got the localization ready to go:
@andymw, correct they do not on enwiki - checking with RfC closer - just as the RfC mentioned stewards this is not likely necessary - but if so it will need to be "added" to that group - not maintained.
Oct 12 2016
Note: fails not only during transclusions, but also when just linking:
Sep 28 2016
Note the enwiki comment above, appears to only occur if the student trying to register does not have a gender specified in preferences - and they are prompted to "optional" select a gender to complete enrollment - but any option leads to the failure state; if they set a gender in preference first this dialog page is not presented and the enrollment passes
Sep 16 2016
+ Community discussion: https://commons.wikimedia.org/wiki/Commons:Bureaucrats%27_noticeboard#Noratelimit_right
Sep 8 2016
+Consensus needed tag; this is under discussion on enwiki - and we should not assume that all other projects need to have most users altering content models for pages.
has been created to discuss if this is something that the English Wikipedia will want to restrict to less users
So making "undo" work for these will not be enabled until the permission is changed?
@Legoktm ping to you regarding my above comment - please let me know if I'm missing some part of the "big picture". Us enwiki people can discuss and request a project specific update if there is a consensus against this there.
I'm a bit concerned about this access for projects that don't have some special Flow related requirement (actually most projects - special flow things should have their own utility). editcontentmodel users are able to "break" pages such as encyclopedia articles from being accessed by readers. Such a break can not be reverted by logged out users, and would require another user to have knowledge of the contentmodel change utility to restore such an article.
Sep 6 2016
Sep 5 2016
@Esc3300 short story: this is a a users v. sysadmins issue here - and the sysadmins decided they don't want this - I'm a bit surprised these tickets haven't been closed out yet as WONTFIX.
Aug 28 2016
@Legoktm any update on your patch - This band aid is pretty sorry though - making what was one action for the end user to now be multiple actions to perform the same change.
Aug 23 2016
@MZMcBride I re-titled the request
Aug 22 2016
@Unready regarding, "the ease with which people could cause a database write simply by adding a GET query", yes it is easy - that is what we LIKE about it. We can provide easy one clicks for even the newest editors to get current versions.
Please undo - this is another example of breaking changes being introduced without having a good evaluation of user needs first. It should have been fairly trivial to determine that &action=purge was actually being used via server logs, prior to making this breaking change