-
Improvement
-
Resolution: Fixed
-
Minor
-
2.9.3
-
MOODLE_29_STABLE
-
MOODLE_37_STABLE
-
MDL-52167_hide_settings -
Note: These tests should be executed on both themes (boost and clean).
Setup
- Login as admin.
- Download the attached local plugin: testhideif.zip
- Install it through the "Site administration > Plugins > Install plugins" section.
Testing scenario 1: hideif setting
- Visit "Site administration > Development > Test hide_if()". If you can't see this link, you can access directly $CFG->wwwroot/admin/settings.php?section=testhideif
- In each section, update the first item in the section in order to show/hide each of the other items in the section (descriptions of the expected outcomes are built into the plugin).
- For instance, when "local_testhideif | checkbox" is not checked, only the "local_testhideif | checkedtext" will be displayed; however, when "local_testhideif | checkbox" is checked, "local_testhideif | checkedtext" is hidden and "local_testhideif | uncheckedtext" is displayed.
- CHECK that the settings are hidden/displayed as explained on each description.
Testing scenario 2: search for a hideif setting
- Visit the "Site administration" search page.
- Search for "multiselect".
- CHECK that all the settings of the "Test hide_if()" local plugin with the "multiselect" string are displayed.
- CHECK that "Text eq", "Text neq" and "Text in" settings contain the following message: "This setting may be hidden, based on the value of local_testhideif | multiselect".
Note : These tests should be executed on both themes (boost and clean). Setup Login as admin. Download the attached local plugin: testhideif.zip Install it through the "Site administration > Plugins > Install plugins" section. Testing scenario 1: hideif setting Visit "Site administration > Development > Test hide_if()". If you can't see this link, you can access directly $CFG->wwwroot/admin/settings.php?section=testhideif In each section, update the first item in the section in order to show/hide each of the other items in the section (descriptions of the expected outcomes are built into the plugin). For instance, when "local_testhideif | checkbox" is not checked, only the "local_testhideif | checkedtext" will be displayed; however, when "local_testhideif | checkbox" is checked, "local_testhideif | checkedtext" is hidden and "local_testhideif | uncheckedtext" is displayed. CHECK that the settings are hidden/displayed as explained on each description. Testing scenario 2: search for a hideif setting Visit the "Site administration" search page. Search for "multiselect". CHECK that all the settings of the "Test hide_if()" local plugin with the "multiselect" string are displayed. CHECK that "Text eq", "Text neq" and "Text in" settings contain the following message: "This setting may be hidden, based on the value of local_testhideif | multiselect".
It's not unusual to have plugin (Moodle core as well as 3rd party plugins) settings on admin settings pages which only make sense if another setting has a certain status.
For example, on /admin/settings.php?section=modsettingforum, the forum_rsstype and the forum_rssarticles setting only need to be visible when forum_enablerssfeeds is set to yes.
Other applications often have mechanisms to show / hide these depending settings on the fly based on the status of the leading setting. I.e. as soon as an admin changes the status of the leading setting on the settings page, the depending settings get shown and the other way round.
At the moment, Moodle lacks such a mechanism. The solution for plugin developers is a) to describe the dependency in the settings' descriptions (like it's done in the above-mentioned example) or to code a special solution for the plugin's settings page.
Having such a mechanism would help clean up the admin settings pages and help understanding dependent settings on the admin pages.
----------------
This issue is strongly related to MDL-49363, but as far as I understood, MDL-49363 is targeted to a static dependency and misses a "on the fly" part.
----------------
PS: A similar on-the-fly mechanism already exists in the course settings when the course format is changed and for activity settings where the disableif attribute can be used to disable activity setting widgets on the fly based on another activity setting's status. Perhaps you don't have to reinvent the wheel completely.
