Last modified: 2014-06-27 11:02:51 UTC
Just found a problem with how the editmyoptions interacts with wgEmailAuthentication. When I set up an account on a wiki where editmyoptions wasn't given to new users and $wgEmailAuthentication was true, the page displayed when I confirmed my email told me I didn't have permission to make that change.
Why is editmyoptions not being given to new users? It should be given to all users with an account.
(In reply to Kunal Mehta (Legoktm) from comment #1) > Why is editmyoptions not being given to new users? It should be given to all > users with an account. I would agree except that seems to ignore the fact that the "editmyoptions" permission exists. In any case, this is not a wiki I set up. I was helping someone on the Support Desk figure out why they couldn't edit their preferences.
(In reply to Mark A. Hershberger from comment #2) > (In reply to Kunal Mehta (Legoktm) from comment #1) > > Why is editmyoptions not being given to new users? It should be given to all > > users with an account. > > I would agree except that seems to ignore the fact that the "editmyoptions" > permission exists. If you mean "why does a permission exist that is supposed to be given to all users?", it's for OAuth. You probably don't want some random app changing your options on you. It's the same with rights 'viewmyprivateinfo', 'editmyprivateinfo', 'editmyusercss', 'editmyuserjs', 'viewmywatchlist', and 'editmywatchlist', every user should be allowed those but they might not want to allow an app to do those things. I'm also not seeing how editmyoptions relates to confirming email; nothing on the code path from Special:ConfirmEmail checks that permission, and I just removed editmyoptions from everyone on my local test wiki and email confirmation went through fine. More likely would be a lack of editmyprivateinfo or viewmyprivateinfo. Anyway, this bug is as valid as complaining that new users can't edit if they're not given the "edit" right. Closing as such.
(In reply to Kunal Mehta (Legoktm) from comment #1) > Why is editmyoptions not being given to new users? It should be given to all > users with an account. I would agree except that seems to ignore the fact that the "editmyoptions" permission exists. In any case, this is not a wiki I set up. I was helping someone on the Support Desk figure out why they couldn't edit their preferences. To be clear, their LocalSettings.php contains the following line: $wgGroupPermissions['*']['editmyoptions'] = false; It looks like the interpretation of permissions changed between 1.22 and 1.23 because, when I take a new installation of MW 1.22 and 1.23, the permissions for 'editmyoptions' don't change. Instead, they remain as if they were the following: $wgGroupPermissions['*']['editmyoptions'] = true; $wgGroupPermissions['user']['editmyoptions'] = false; In the meantime, 'edit' is set to true for both '*' and 'user'. Now that I look at this, I think what the person needs to do in 1.23 is $wgGroupPermissions['*']['editmyoptions'] = false; $wgGroupPermissions['user']['editmyoptions'] = true;
Reopening because it looks like the way permissions are interpreted has changed.
(In reply to Mark A. Hershberger from comment #4) > To be clear, their LocalSettings.php contains the following line: > > $wgGroupPermissions['*']['editmyoptions'] = false; Yes, that would remove the permission. Even though it has no effect for anons, it is assigned to '*' by default rather than 'user' to allow code to short-circuit more expensive per-user permissions checks by using User::isEveryoneAllowed(). > It looks like the interpretation of permissions changed between 1.22 and > 1.23 I doubt that. It looks more like you're just confused here, thinking that 'editmyoptions' is given by default to 'user' rather than (or in addition to) '*'. > because, when I take a new installation of MW 1.22 and 1.23, the > permissions for 'editmyoptions' don't change. Instead, they remain as if > they were the following: > > $wgGroupPermissions['*']['editmyoptions'] = true; > $wgGroupPermissions['user']['editmyoptions'] = false; The second line here no effect. I can't make any sense of why you are making this statement. > Now that I > look at this, I think what the person needs to do in 1.23 is > > $wgGroupPermissions['*']['editmyoptions'] = false; > $wgGroupPermissions['user']['editmyoptions'] = true; No, what they need to do is not screw with the assignments for editmyoptions and the other 'my' permissions at all. (In reply to Mark A. Hershberger from comment #5) > Reopening because it looks like the way permissions are interpreted has > changed. I'll give you one chance to provide actual evidence for this speculation before I close this again.
(In reply to Brad Jorsch from comment #6) > > because, when I take a new installation of MW 1.22 and 1.23, the > > permissions for 'editmyoptions' don't change. Instead, they remain as if > > they were the following: > > > > $wgGroupPermissions['*']['editmyoptions'] = true; > > $wgGroupPermissions['user']['editmyoptions'] = false; > > The second line here no effect. I can't make any sense of why you are making > this statement. I made this statement primarily because I saw a difference between how 'edit' and 'editmyoptions' are assigned. Note that I am not saying that those lines exist in anyone's LocalSettings.php, I'm just saying what the permissions appear to be when I used run a script that dumps out the permissions: User::groupHasPermission( 'user', $perm ) Note that when I changed the perms and added a check for a specific bureaucrat/sysop -- with $user->isAllowed( 'editmyoptions' ) -- the value of returned changed depending on the settings. > > $wgGroupPermissions['*']['editmyoptions'] = false; > > $wgGroupPermissions['user']['editmyoptions'] = true; > > No, what they need to do is not screw with the assignments for editmyoptions > and the other 'my' permissions at all. Then those options should be removed. Using my test script the above assignments seem to have the desired effect. > I'll give you one chance to provide actual evidence for this speculation > before I close this again. Please do not talk to me like I'm your child. As far as I can tell, I haven't done anything to merit this tone. But you're right: the fact is that it isn't "editmyoptions" that causes the problem. I'm not familiar with these new permissions and that was the first one that jumped out at me. Upon closer examination, it is "editmyprivateinfo" that blocks confirming email. I've retitled this bug accordingly.
Created attachment 15754 [details] test script
Now that you've changed the title, it's certain that this is working as designed. Nor has permissions handling changed as you claimed in comment 5. (In reply to Mark A. Hershberger from comment #7) > Then those options should be removed. See comment 3. These rights exist for a reason, and just because you continue to refuse to acknowledge that reason does not change the fact.
You should point to the discussion for this change: I3f03dd010020e8d43cc2d3bca7b3ef7196d1c548 I can see from that that this is acting as designed. However no documentation was added except for a hint in the commit message. > These rights exist for a reason, and just because you continue to > refuse to acknowledge that reason does not change the fact. I acknowledge the reason. But you're introducing compatibility problems with wgEmailAuthentication without clearly documenting why or providing a "breaking change" note in the release notes. > No, what they need to do is not screw with the assignments for editmyoptions > and the other 'my' permissions at all. This is open source code. You can't expect people keep their hands off an option if you don't tell them not to touch it. This is the only time I've seen any warning about changing these options.
(In reply to Mark A. Hershberger from comment #10) > This is the only time I've > seen any warning about changing these options. So, do we just need better documentation here? I'm not seeing what the issue is. If you don't have the editmyprivateinfo userright, it seems logical to me that you can't confirm my email.
(In reply to Kunal Mehta (Legoktm) from comment #11) > me that you can't confirm my email. confirm your* email.
(In reply to Kunal Mehta (Legoktm) from comment #11) > So, do we just need better documentation here? If this is the design, then, yes, the documentation should say something about this. I've filed bug #67167 for this.
