Tue, Jul 16
Thu, Jul 11
Wed, Jul 10
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?
Mon, Jul 8
@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."
Thu, Jul 4
Tue, Jul 2
@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
Thu, Jun 27
Wed, Jun 26
@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.]
Fri, Jun 21
Thu, Jun 20
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
Apr 17 2019
Apr 16 2019
I'm going with No matching blocks found for the requested IP address or username
Apr 15 2019
Apr 9 2019
What is the plan here exactly? Is there any deprecation process that we have to go through?
Do we want to rename the BlockRestriction class to something else?
@daniel are there any name conventions to follow for this "servicification" we are doing? Or any other conventions for that matter?
"Store, Service, Manager", are we using those names interchangeably?
Apr 5 2019
Apr 4 2019
Apr 3 2019
Also, please consider splitting BlockManager and BlockStore. BlockStore would have all the things that touch the database, while BlockManager builds on top of BlockStore and does all the things related to cookies and sessions and such.
Apr 2 2019
I feel like that's still a bug. We shouldn't allow for non-existing namespaces to be saved. At the very least we shouldn't display an empty namespace in the BlockList.
Apr 1 2019
Mar 29 2019
Mar 28 2019
Right so basically a partially blocked user with the undelete right should be to restore any page. They'll just be unable to do any other actions on it once it is restored (if the id happens to be the same after restoration)