Tue, Sep 17
Looking into this
Mon, Sep 16
Fri, Sep 13
Pull Request here: https://github.com/wikimedia/InteractionTimeline/pull/117
Thu, Sep 12
Wed, Sep 11
Tue, Sep 10
Thu, Sep 5
Tue, Sep 3
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.
Tue, Aug 27
Mon, Aug 26
Fri, Aug 23
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?
Jul 8 2019
@Niharika Just to confirm. Should the form header include User: as part of the text or just the username?
"Please select your mute preferences for User:Vandal."
"Please select your mute preferences for Vandal."
Jul 4 2019
Jul 2 2019
@Niharika this task introduces a few changes that conflict with the error messages we added on T218265: Mute: Add links to disable email and mute specific user to emails sent via Special:EmailUser
Jun 27 2019
Jun 26 2019
@Niharika emails from Special:EmailUser are in plain/text. Currently the default email footer looks as follow if I use the plain msg:
This email was sent by Admin to Vandal by the "Email this user" function at devwiki. If you reply to this email, your email will be sent directly to the original sender, revealing your email address to them. [http://dev.wiki.local.wmftest.net:8080/wiki/Special:Mute/Admin Manage email preferences for Admin.]
Jun 21 2019
Jun 20 2019
Jun 5 2019
+1 for CompositeBlock. IMO the name fits/describes how the object behaves (https://en.wikipedia.org/wiki/Composite_pattern)
Jun 3 2019
May 31 2019
No. My point is that we need to make them checkboxes now, and avoid using verbs when arriving at this page.
This is what I was doing initially and we talked and agreed on not using a checkbox because there is only one option and it was bad UX (merging the lists or no)
May 30 2019
May 28 2019
Her are all the screens for this feature (so far)
May 24 2019
@Niharika After discussing with @dbarratt we agreed that for this task it is not necessary to have a checkbox since the only available option will be to mute or unmute emails (for now). We propose to have a message indicating what action would happen depending if the user is already muted or not.
I think I already asked this but it escapes me if I did. Why was it that we can't check if a given option is already a global preference or a local exception?
In other words, when saving "whatever-option" on onUserSaveOptions we could determine if it is a global preference and/or if it has a local override and make the changes wherever they need to be done.
Considering that the choice to make something a global or a local exception is made by the user I would say that it will be expected that any changes to those options will be stored based on the user's choice.
May 17 2019
You could also create a new topic on https://www.mediawiki.org/wiki/Manual_talk:Coding_conventions/PHP. It might add more visibility.
May 3 2019
I think that supporting the definition to be either a callable or a string would be ideal (so a combination of your suggestions). It will make it backward compatible and we can start migrating into DI in incremental changes. SpecialPageFactory::getPage() already supports a string or a callable so a "quick" change would be to make $coreList non-static and adjust the SpecialPageFactory accordingly.
I'm not sure about Api Modules 'cause I haven't seen how that works
May 2 2019
i did say feature flag originally ;)
You did, sorry I missed it :)
Copying over the "in-patch" comment for better discussion
Apr 29 2019
Apr 24 2019
Apr 19 2019
It might also be a good idea to provide more info about mute (https://www.mediawiki.org/wiki/Help:Notifications#mute) and/or more information on how they can see their current email/mute list on Special:Preferences