Moodle
  1. Moodle
  2. MDL-14183

Users can't update their profiles or passwords, thought in Authenticated user and Student roles these capabilities Allowed.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 1.9
    • Fix Version/s: 1.9.1
    • Component/s: Authentication
    • Labels:
      None
    • Affected Branches:
      MOODLE_19_STABLE
    • Fixed Branches:
      MOODLE_19_STABLE
    • Rank:
      31080

      Description

      Users can't update their profiles or passwords, thought in Authenticated user and Student rolesthese capabilities are Allowed (so users can't also restore forgotten passwords).

      As far as I can see this bug was reported, but never reproduced, and it can be related to upgrading from 1.8. to 1.9. If you have trouble reproducing this bug, you may see it on an URL above using student's login: student and password std. If you need some admin information, please comment and I try to provide it.

        Issue Links

          Activity

          Hide
          Petr Škoda added a comment -

          Is the authenticated user role selected in $CFG->defaultuserroleid ?

          Show
          Petr Škoda added a comment - Is the authenticated user role selected in $CFG->defaultuserroleid ?
          Hide
          Oleg Sychev added a comment -

          No. I set this, and problem resolved.
          Probably system behavour silently chages during upgrade, which causing those problems.

          Show
          Oleg Sychev added a comment - No. I set this, and problem resolved. Probably system behavour silently chages during upgrade, which causing those problems.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Petr, we have had a bunch of reports about problems with this setting changing to "guest" and so.

          If the solution is always to change it to authenticated user... what's the key about allowing it to be selected? Also... could we, as one step in upgrade... check for it (if empty or so) and set it to default? I guess a lot of people don't "save" the upgrade form on upgrade (I've had some reports about other missing settings like emoticons...) in recently upgraded to 1.9 sites.

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Petr, we have had a bunch of reports about problems with this setting changing to "guest" and so. If the solution is always to change it to authenticated user... what's the key about allowing it to be selected? Also... could we, as one step in upgrade... check for it (if empty or so) and set it to default? I guess a lot of people don't "save" the upgrade form on upgrade (I've had some reports about other missing settings like emoticons...) in recently upgraded to 1.9 sites. Ciao
          Hide
          Martin Dougiamas added a comment -

          Yes, it seems many sites have ended up with $CFG->defaultuserroleid == guest after an upgrade which causes all kinds of serious problems.

          Can you make sure it gets set to Authenticated User by default, Petr?

          Show
          Martin Dougiamas added a comment - Yes, it seems many sites have ended up with $CFG->defaultuserroleid == guest after an upgrade which causes all kinds of serious problems. Can you make sure it gets set to Authenticated User by default, Petr?
          Hide
          Petr Škoda added a comment -

          hi,
          the problem was in 1.7.x - I suppose that any site that went through that version is affected, the reason why it was not switched in 1.8 was that it sort of worked which is not the case in 1.9 anymore.

          going to fix it somehow...

          Show
          Petr Škoda added a comment - hi, the problem was in 1.7.x - I suppose that any site that went through that version is affected, the reason why it was not switched in 1.8 was that it sort of worked which is not the case in 1.9 anymore. going to fix it somehow...
          Hide
          Oleg Sychev added a comment -

          Hello, Petr

          You wrote "the problem was in 1.7.x - I suppose that any site that went through that version is affected"

          I can say that our site was upgraded from 1.6.x straight to 1.8.1. and later to 1.9beta during Bugathon and so on, and it was affected.

          Show
          Oleg Sychev added a comment - Hello, Petr You wrote "the problem was in 1.7.x - I suppose that any site that went through that version is affected" I can say that our site was upgraded from 1.6.x straight to 1.8.1. and later to 1.9beta during Bugathon and so on, and it was affected.
          Hide
          Petr Škoda added a comment -

          patch committed into cvs,
          thanks for the report

          Show
          Petr Škoda added a comment - patch committed into cvs, thanks for the report
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Hi Petr,

          was reviewing this and it seems that you are changing those "guest" roles to NULL (instead of "Authenticated role". Is that the expected behaviour? Shouldn't we default to the authenticated one?

          That's the only point preventing me to close this, as the list now is properly skipping guest roles to be selected and everything else seems to be working ok.

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Hi Petr, was reviewing this and it seems that you are changing those "guest" roles to NULL (instead of "Authenticated role". Is that the expected behaviour? Shouldn't we default to the authenticated one? That's the only point preventing me to close this, as the list now is properly skipping guest roles to be selected and everything else seems to be working ok. Ciao
          Hide
          Petr Škoda added a comment -

          the set_config('xxx', null) deletes the value, right?

          /**

          • Set a key in global configuration
            *
          • Set a key/value pair in both this session's {@link $CFG}

            global variable

          • and in the 'config' database table for future sessions.
            *
          • Can also be used to update keys for plugin-scoped configs in config_plugin table.
          • In that case it doesn't affect $CFG.
            *
          • A NULL value will delete the entry.
            *
          • @param string $name the key to set
          • @param string $value the value to set (without magic quotes)
          • @param string $plugin (optional) the plugin scope
          • @uses $CFG
          • @return bool
            */
            function set_config($name, $value, $plugin=NULL) {
          Show
          Petr Škoda added a comment - the set_config('xxx', null) deletes the value, right? /** Set a key in global configuration * Set a key/value pair in both this session's {@link $CFG} global variable and in the 'config' database table for future sessions. * Can also be used to update keys for plugin-scoped configs in config_plugin table. In that case it doesn't affect $CFG. * A NULL value will delete the entry. * @param string $name the key to set @param string $value the value to set (without magic quotes) @param string $plugin (optional) the plugin scope @uses $CFG @return bool */ function set_config($name, $value, $plugin=NULL) {
          Hide
          Eloy Lafuente (stronk7) added a comment -

          yup, yup. That's not the question I wanted to do, hehe.

          Some comments above Martin commented "Can you make sure it gets set to Authenticated User by default, Petr?", and that's not current behaviour. Just that.

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - yup, yup. That's not the question I wanted to do, hehe. Some comments above Martin commented "Can you make sure it gets set to Authenticated User by default, Petr?", and that's not current behaviour. Just that. Ciao
          Hide
          Martin Dougiamas added a comment -

          Yes, can we set it to "Authenticated User" by default? Most admins aren't going to read all the 100 new settings, they just accept defaults. And for this setting it almost always needs to be set to Authenticated User otherwise strange stuff happens.

          Show
          Martin Dougiamas added a comment - Yes, can we set it to "Authenticated User" by default? Most admins aren't going to read all the 100 new settings, they just accept defaults. And for this setting it almost always needs to be set to Authenticated User otherwise strange stuff happens.
          Hide
          Petr Škoda added a comment -

          I does set it to authenticated user by default. Only if guest found there, it is unset and the admin is notified that he/she should chose some other role, but again the authenticated role is preselected in upgrade settings.

          I do not think we should just switch that setting without informing admins, because even the guest role might have some overrides or customisations.

          Show
          Petr Škoda added a comment - I does set it to authenticated user by default. Only if guest found there, it is unset and the admin is notified that he/she should chose some other role, but again the authenticated role is preselected in upgrade settings. I do not think we should just switch that setting without informing admins, because even the guest role might have some overrides or customisations.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Well,

          I think that Petr's approach is also valid if it's IMPOSSIBLE to bypass the settings page (i.e. if somebody tries to continue with installation... the new settings page is showed again until saved). And will show, in any case the default "authenticated user" in any case.

          But... if it's possible to bypass the settings page, then we MUST set it in upgrade (instead of unsetting).

          so, they key here is... does the new settings page in upgrade REQUIRE to be saved to continue upgrade?

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Well, I think that Petr's approach is also valid if it's IMPOSSIBLE to bypass the settings page (i.e. if somebody tries to continue with installation... the new settings page is showed again until saved). And will show, in any case the default "authenticated user" in any case. But... if it's possible to bypass the settings page, then we MUST set it in upgrade (instead of unsetting). so, they key here is... does the new settings page in upgrade REQUIRE to be saved to continue upgrade? Ciao
          Hide
          Petr Škoda added a comment -

          The missing settings get shown again if you go to admin/index.php

          hmm, maybe I could add a new hack to test the new settings once for admin after login and redirect to upgradesettings if needed, this would also solve the problem with bumping of main version when settings are added in modules.

          Show
          Petr Škoda added a comment - The missing settings get shown again if you go to admin/index.php hmm, maybe I could add a new hack to test the new settings once for admin after login and redirect to upgradesettings if needed, this would also solve the problem with bumping of main version when settings are added in modules.
          Hide
          Martin Dougiamas added a comment -

          I'm OK with it as it is now I think, but the hack sounds good too.

          Show
          Martin Dougiamas added a comment - I'm OK with it as it is now I think, but the hack sounds good too.
          Hide
          Petr Škoda added a comment -

          reclosing then and filing new issue for the proposed hack

          Show
          Petr Škoda added a comment - reclosing then and filing new issue for the proposed hack
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Closing. Thanks!

          Show
          Eloy Lafuente (stronk7) added a comment - Closing. Thanks!

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: