Located in Germany: CET (UTC+1)/CEST (UTC+2)
GPG: 84E7 0489 0F69 0544 0A59 86D8 C485 27CF 7D40 8CDE
I just noticed there already is a patch for this at https://review.openstack.org/#/c/517831/
The throttle override is now set to be active between 2017-11-14 midnight UTC and 2017-11-22 midnight UTC (to include the whole of 2017-11-21). The limit is increased to be 50 registrations/24h (instead of normal 6 reg./24h). Have fun at your event! :-)
No worries, that just happens sometimes. And sorry from my side too - for getting frustrated too easily (once again) and abandoning the patch earlier. I'm trying to grow a bit more patience about the code reviews in general, but that's haaaaard ;)
I've just run across this tool again and noticed it's still broken in that the wrong groups are listed. So actually this still should be merged.
This is now done - however, as described before, we do not know whether the throttle would have been applied if the exemption would not have existed.
Tested. The suppress option only appears if you select an 'infinite' expiry time (which is okay as temporary hideuser blocks make no sense).
Special:Block is now using OOUI again on group 0 & 1 (that is everything exept most -pedias). Could you have a look whether this works again now (preferably before this goes out to group 2 tomorrow)?
I haven't found any "irc-managers" or something like that tag, so Operations seemd to fit best. I thought about "dropping" as making it forward it to another (more popular) channel that will be used instead (maybe kicking people first? Don't know how forwarding works for people already in that channel).
Per comments given on the patch, it will need a +1 from DBA to proceed. I'm moving this on your workboard so you are aware this needs your input, without any expectations when it may be done :)
massmessage, nuke and spamblacklistlog are now available to contentadmin. The following rights remain as the difference between sysops and contentadmins and were not added as they are missing intentionally:
Let's stop meta-talking about the issue, and start working on it, ok?
Probably. This task would block that; we can't change MW core until WMF production is migrated and stable on PHP7 instead of HHVM
The issue here is that MediaWiki is keeping, with regards to temporary user rights, old and incorrect data as you correctly mention as well as others.
When digging a bit further into this, I found that it was somewhat (ableit for other reasons) discussed in T153817 and @MaxSem had https://gerrit.wikimedia.org/r/#/c/350961/ for it: When mw does the "get all groups for user X" operation, it already has to check if one of the results it got is about an expired group and filter that one out. Whenever an expired row was seen in that step, the patch would schedule a job (which just called UserGroupMembership::purgeExpired(); ) to clean up the table. I'd love to hear what the "different direction" mentioned when abandoning that patch was.
Hmm. I think I can safely say we wouldn't want a contentadmin using tboverride
Discussed again in T142663, the preferred solution is not not use flat arrays, but assoc ones instead.
I know why at least one of those is considered a security-sensitive right.
User rights explicitely removed from 'contentadmin' in CommonSettings.php:
Should this be declined due to T176370?
So what is the official channel for getting the WMF to address these issues/requests - or is Phab simply the place they move stuff to they just don't want to do?
Question regarding this: it has been marked as blocked on development. Does this mean it is not moving forward? I am asking because of the potential impact it might have on gathering statistics during ACTRIAL if it is implemented in the middle of the trial.
We could certainly think about running a cronjob for purging expired user groups.
If we had a gerrit group for new users we could do a search for ownerin:'GROUP' but other than that I can't see any way to identify new users in gerrit.
1 week seems pretty ambitious considering we currently have patches sitting for > 6 months, however, I agree that 1 week seems like a reasonable expectation for contributors. I can certainly imagine that, as a new contributor, I might start to feel discouraged after 1 weeks' time.
The problem is that we will never be able to ensure that rows are removed from the table the very second they expire. This means that when you run a query at 13:30, asking for user groups (of which one expired at 12:30) but the next purge is scheduled for 18:00, you'll see wrong results. Sure, purging more regularly (in terms of weeks or days instead of "when a new group is added") means the probability to run into this decreases and you'll see it less often. My point is that this won't be solving the bug, but only make it appear less often. The path forward to really fix it would be to update the consumers of that table.
I tested that on tyvwiki. I added myself to the administrator group and removed myself afterwards. Now the dbdata is up-to-date. However that expired entries ain't removed until any user is added to a new user group means that in some cases wrong or outdated data be displayed wrong indefinitely or for a very very long time. That is not okay IMHO.
This one was a bit longer temporary permission on angwiki:(change visibility) 20:02, 26 April 2017 Vituzzu (talk | contribs | block) changed group membership for Vituzzu@angwiki from (none) to CheckUser (temporary, until 20:17, 26 April 2017) (checking abuse)
https://tools.wmflabs.org/rightstool/cgi-bin/rightslogsearch?user=%40angwiki shows there hasn't been any user rights changes on angwiki since that one.
mediawiki checks whether the timestamp given in ug_expiry is >= the current time. All other tools getting user group information from the database should be doing the same. So these expired rows don't really do any harm, they don't need to be removed immediately.
Sorry, saw your message just after that.
For reference, we came from https://meta.wikimedia.org/w/index.php?title=Tech&oldid=17263651#Admin_activity_tool
GET /adminstats/ is wrong, which is my mistake. I needs to be /adminstats (without trailing slash). There's no 404 then.
I've just looked into this, there really is no hook to tell ConfirmEdit (CAPTCHA extension) it should stop requiring captchas for ips we have an exemption for. I created T176589 for adding a hook that gets us this functionality. So this task is blocked until we've implemented T176589.
Reset priority, which was inherited from the parent task.
Famous last words. Not as simple as I thought: It's easy to identify whether ThrottleOverride returned "bypass this throttle, there's an exemption for it". This is what the patch does.
Oh, in that case it'd probably be a very simple thing.
We don't have this with the current implementation, has this ever been a problem?
Is there some function that effectively maps boolean config variables to flat arrays internally in core? So one could have a config variable $wgVar = [ 'foo' => true, 'bar' => false, 'foobar' => true, 'baz' => 'false' ] and then call Something::getBooleanConfigAsFlatArray( 'wgVar' ) which would return [ 'foo', 'foobar' ]? I'm primarily interested in a way to simply iterate over a config variable (which works fine with flat arrays, but not with boolean ones, at least I'm not aware of a really short way) and wrote such a function for https://gerrit.wikimedia.org/r/#/c/380061/. Maybe it'd be worth to have such a helper function in core. That way one could use the boolean config variables and overwrite them in whatever way seems best, but still get config variables as flat arrays when it's necessary/easier at runtime.
Thank you for confirming that my statement "The proposed solution /when deployed/ will not not resolve the issue described" is true.
While this is reasonable, I don't really see it as an deployment blocker for ThrottleOverride (that is, a feature this extension needs to be secure/usable like logging, ability to remove throttles etc.).
Is there an easier way than having another special page for this? I'd like to avoid unnecessary special pages, but it seems something like Special:Unblock would be the easiest thing.
Honestly I feel that Wikimedia's code-review culture is a complete failure and needs significant overhaul.
I've submitted my first patch in February and I've felt that the system in place isn't perfect really quickly. That impression continuously increased and my motivation for further contributions, especially to mw core, continuously shrunk. As of today, I can only say that I completely agree with that statement and code review is the most frustrating part of wikimedia-land for me. And judging from the amounts of tasks, mailing lists threads, events, ... on this topic, there seem to be quite a few people who feel (or at least felt) that way.
Not doing mw core work any more, at least in the short-term future.
Is there some extension which might be used as a reference for storing data as json within a wiki page?
I'm personally only aware of extensions storing single strings per wiki page (like translations, a paragraph gets it's own page and each translation gets it's own page as well) but not of any storing structured data (e.g. json, yaml, whatever).
Having the backend store multiple entries into the database and thus applying multiple throttles at once isn't hard. A textbox with "one range per line" for the target field would do for just that, inserting one db entry for each target.
But those entries (after saving) cannot be related to each other in the current schema. Would we want to track exemptions that were created together (e.g. to change them all at once, delete them together etc.)? That needs changes to the current db schema as well as thoughts about the UI of ThrottleOverrideList.
T174895 is related.
As mentioned before, this is resolved by https://gerrit.wikimedia.org/r/198687