Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-58793

Reduce the number of auth setting presented on upgrade to 3.3

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 3.3
    • Fix Version/s: 3.3
    • Component/s: Installation
    • Labels:
    • Testing Instructions:
      Hide
      1. Start with a 3.2 site.
      2. Go to Site administration > Plugins > Authentication > Manage authentication and re-save the configuration forms of enabled auth method *)
      3. Enable and configure External database auth method and eventually some others, too. There is no need to actually set it correctly to a functional state or even have some users using it. The point is to have the method enabled and its legacy config form saved in 3.2.
      4. Upgrade the site via the web interface (not CLI).
      5. TEST: Make sure there are no errors on the "Upgrading to new version" page.
      6. TEST: Make sure that during the web upgrade, the "New settings" page does not report settings for disabled auth plugins. Settings for enabled auth methods are reported only if
        • were actually added in 3.3 (such as "auth_db | updateusers")
        • or the auth method configuration was not modified/saved in 3.2
      7. Finish the upgrade.
      8. TEST: Check that you can enable/disable and configure some alternative auth methods.

      *) Note on the need to re-save the config during the testing:

      • It is not enough to just enable the auth method without saving its 3.2 config form. Moodle 3.2 does not save the auth settings without pressing the "Save changes" explicitly.
      • For the same reason, if you install a fresh new 3.2 site, it will have Manual and Email auth enabled. But it will have no settings stored unless you explicitly save the configuration form. The settings of these auto-enabled auth methods would be also reported as new ones (it is assumed that a typical production site would have these settings amended/saved).
      Show
      Start with a 3.2 site. Go to Site administration > Plugins > Authentication > Manage authentication and re-save the configuration forms of enabled auth method *) Enable and configure External database auth method and eventually some others, too. There is no need to actually set it correctly to a functional state or even have some users using it. The point is to have the method enabled and its legacy config form saved in 3.2. Upgrade the site via the web interface (not CLI). TEST: Make sure there are no errors on the "Upgrading to new version" page. TEST: Make sure that during the web upgrade, the "New settings" page does not report settings for disabled auth plugins. Settings for enabled auth methods are reported only if were actually added in 3.3 (such as "auth_db | updateusers") or the auth method configuration was not modified/saved in 3.2 Finish the upgrade. TEST: Check that you can enable/disable and configure some alternative auth methods. *) Note on the need to re-save the config during the testing: It is not enough to just enable the auth method without saving its 3.2 config form. Moodle 3.2 does not save the auth settings without pressing the "Save changes" explicitly. For the same reason, if you install a fresh new 3.2 site, it will have Manual and Email auth enabled. But it will have no settings stored unless you explicitly save the configuration form. The settings of these auto-enabled auth methods would be also reported as new ones (it is assumed that a typical production site would have these settings amended/saved).
    • Affected Branches:
      MOODLE_33_STABLE
    • Fixed Branches:
      MOODLE_33_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      MDL-58793-master-authcfgskip

      Description

      This is a followup, regression of MDL-12689.

      Every site upgrading to 3.3 will get all the "unused" (aka, previously non existent) auth settings displayed in upgrade. That can be easily some hundreds of settings for nothing.

      (see attached super_longo_spagetti.pdf)

      The idea is that we should create all those settings with default values, each one as a upgrade step within each plugin, when the setting did not exist previously.

      Only that way all those settings won't be displayed on upgrade.

      Note there is also MDL-58692 that maybe will lead to modify current upgrade steps to make them safer (avoid dupes). So maybe this can be implemented together. For your consideration.

      Ciao

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Fix Release Date:
                  15/May/17