Fri, Dec 13
My apologies for the misunderstanding then.
Actually you are right. A cross makes more sense here since we are excluding from the search in this case
I don't think so. The messages are ready to be translated. I just did es :)
Thu, Dec 12
So just to be clear, what goes inside the parenthesis in the IP column should be UA independent. Right?
We really need to get more things in writing 'cause I recall having this conversation with someone at some point and completely forgot about it. Having had this information while we were deciding to use a pager or a fake wrapper would have significantly speed the decision and make it easy and obvious (at least to me)
Which icon is better — trash, cross, funnel?
AFAIK a funnel is generally understood as "filter".
Tue, Dec 10
Mon, Dec 2
Wed, Nov 27
- Banana made 17 edits
- Other users made 10 edits
- The total of edits from that IP is 27
Fri, Nov 22
Thu, Nov 21
Wed, Nov 20
Nov 14 2019
@Niharika What is the acceptance criteria for this task? Should ip users also be supported as part of this or is it supporting only registered accounts enough?
Waiting on T237532: Preferences are saved as GlobalPreferences when autoglobal is enabled for the field to be fixed
Nov 13 2019
Nov 12 2019
Considering that the use of internal API requests is discouraged I assume that we are mentioning CentralAuth API only if we can't run the db queries and instead we would load whatever we need from the client side using ajax. Am I wrong?
Nov 8 2019
@Niharika Is CheckUser2 the name we are gonna go with? Can we go for something that can stick even if the current CheckUser cease to exists?
Here are some ideas for the name of the page (I know words like "Investigation" carry some weight but maybe somehing similar to that(?)
Writing down what I found
Nov 6 2019
Nov 1 2019
Oct 28 2019
Sep 26 2019
Sep 23 2019
Sep 17 2019
Looking into this
Sep 16 2019
Sep 13 2019
Pull Request here: https://github.com/wikimedia/InteractionTimeline/pull/117
Sep 12 2019
Sep 11 2019
Sep 10 2019
Sep 5 2019
Sep 3 2019
I'd advocate for fixing all at once if there's a clean way to do it. @dmaza did you have a way in mind?
I do not.
Aug 27 2019
Aug 26 2019
Aug 23 2019
Aug 22 2019
Aug 19 2019
Aug 15 2019
I think that's a bit gross. I would honestly rather just leave that English-only than do that.
Do you care to expand on this? I don't think "gross" is a valid argument
Aug 13 2019
@Milimetric @nettrom_WMF correct me if I'm wrong but other than annotating that the schema is active there isn't anything else I need to do to start logging events other than deploying the code that would make use of it, right?
Aug 5 2019
Here is the schema for our data capture. Feel free to make changes and I'll fix up the patches
@dom_walden can you confirm that the issue is fixed tho? (Block list and log incorrectly report "cannot edit own talk page" for some blocks) I'll take a look at how the form displays the errors anyway
Makes sense, I'll fix it
Jul 30 2019
Jul 24 2019
Sure, lets have another task and we can investigate there
Assuming $wgEnableSpecialMute = true. Neither $wgEnableUserEmailBlacklist nor $wgEchoPerUserBlacklist has to be true, which means you can see this link even if there is nothing you can do with it. I don't know why you would configure your wiki like this, though.
@dmaza I don't think we should show the link if the page is going to throw an error anyways. It's effectively an access denied (and perhaps we could use that mechanism?).
It shows an error message saying "Mute features are unavailable. This might be because: you haven't confirmed your email address or the wiki administrator has disabled email features and/or email blacklist for this wiki. "
We could check for $wgEnableUserEmailBlacklist but we can't check for $wgEchoPerUserBlacklist. I don't think there is anything we can do really other than what's already in place.
Jul 23 2019
Jul 16 2019
Jul 11 2019
Jul 10 2019
If the issue is that after unchecking "Editing", "Editing their own [...]" remains checked (although disabled), that will/should be fixed on T221117: Special:Block checkboxes should remember checked state. I personally don't see a problem other than what's described on T221117
I'm a bit confused as to what is the issue here
Expected Result: Either: Grey 'Editing their own talk page' when editing blocks are disabled
Isn't this what's happening right now?