Eh this is the only bug I could find so far, I was sure this was in another bug somewhere else too - I recall discussing it with Petr/Tim some time ago.

Added UI Mockup: <xml settings manager mockup>

Edited UI Mockup <xml settings manager mockup>: Added mockups of the setting import interface and a mockup of how to preview a settings file.

The functionality is a good idea in itself, adding flexibility. And great to see you're using balsamiq . My main concern is however that expressing the relationship between the actual settings screen and these meta-settings will be challenging.

Chris, should you take this challenge in GSoC, I would like to encourage you to think through the entire navigation structure in Moodle configuration: where would the menu item for this meta-configuration reside, and how would you communicate that there is in a sense a hierarchical relationship between the this and the actual configuration screens? I think it would be helpful to add mockups from entire Moodle screens that include this functionality, and demonstrate workflows with sequences of mockups.

Critical usability goals:
A) Let non-experienced admins ignore this new functionality, benefit from progressive disclosure: http://www.useit.com/alertbox/progressive-disclosure.html
B) When a template is active, this is a global mode that affects the entire Moodle. Consider where (and in what situations) this should be visible, without compromising A) and still helping the user be aware of what it is that is that is affecting the settings. Is it planned that when a template is turned on, all the settings in the ordinary settings screens are disabled (unchangeable)?

Hello Chris,

Congratulations on getting this far in the Google Summer of Code. You have two great mentors, so I have high expectations for this functionality . Seriously though: if this is done right it will save many people many hours of work.

I have a couple comments:

1. Where are you planning to put the boundaries when it comes to which settings can be saved/imported/exported. Are you planning to include all role related settings (yes, please!)? Would it include language files (not likely, but think about the added value it could have...)

2. It would be great to also get access to a viewable representation of the settings file (like a printable PDF or a nicely styles HTML file). This could be used to document the chosen settings

3. An easy way to make a diff between two setting files would be excellent. Imagine this. We configure a Moodle installation a particular way for a client and export their settings. The clients then continues to use the environment and changes some settings, eventually leading to something not working. It would then be trivial to see what changes were made, pointing us in the right direction.

4. I am not sure I see the value in having multiple settings files. Shouldn't a setting file be an integral thing? That way you can allay some of Olli's worries and it would make things more simple. You can export you current settings to an XML file and you can import settings from an XML file. An import should make your Moodle identically configured to the Moodle from which the import file was exported. Otherwise it will get confusing.

I would be willing to try out any early releases that you might create and give my feedback.

Good luck!

Hans

Any update on this ?

Unfortunately the GSOC project failed to get off the ground and sadly had to be abandoned (source: http://docs.moodle.org/en/GSOC/2009 )

Hi,

I saw that this project was discontinued and like to know if I can work on it as a part of my end of degree project, I should begin on February.

Hi David,

You're welcome to work on this project, however please note that Moodle is not going to be part of GSoC 2010 in order that we can focus on the Moodle 2.0 release (see http://moodle.org/mod/forum/discuss.php?d=143919).

Hi,

Thanks for the info Helen, that is not a problem, I think that this is a useful functionality and could save a lot of time, I'm glad I can work on it.

About Hans questions, I'll begin with the standard settings, but as you said, there are a lot of important external settings like roles that could be really important in some cases. I don't have preferences, I hope that the community will give me feedback about the external settings implementation priority and the project limits. I also agree with you that there must be a template preview and something like a diff command, I think that the complexity comes with multiple templates applied and her rollbacks.

I have always worked with 1.9, I'm a 2.0 newcomer, before I begin to code I must read docs and 2.0 code to learn how Moodle 2.0 manages the admin settings tree, $CFG and the new config_log table as well as other Moodle components changes.

I'll thank all the comments, feedback, help...

David

Hi,

I wrote two months ago to see if I can work on this, I've been implementing it as a site level block named settings_templates since Helen told that there is no problem work on that project. I'm following the Moodle Docs requested features <http://docs.moodle.org/en/Development:XML_Administrator_Settings>.

The attached block version (compatible with the lastest HEAD) has the following features implemented:

• Import from .xml to the settings templates block tables
• Export from system settings to block DB tables
• Load from the settings templates tables to system config (applied changes and skipped settings list)
• Partial template export and load
• List of the avaiable templates with options: preview, load, download xml and delete
• Templates versioning (not applicable settings list)
• Changes logged (TODO: Rollback)
• Exclude sensible data option when exporting
• Settings with multiple values supported
• Using YUI TreeView to show the admin tree, xmlize to import, html_table to list, moodleforms and the adminlib.php admin_setting children classes.

TODO

• add special settings pages (roles, manage___ui, ...)
• rollback
• refactor from "template" to "preset"?
• change the pretty fruit icons for more seriuos icons
• add a block setting to edit the sensible settings
• the code // TODOs
• all the suggestions will be welcomed

I'm working on it in a google public svn repository and, if it's not a problem for you of course, I'll continue attaching here the new block versions

David

Hi, I've uploaded the latest stable version (renamed from settings_templates to admin_presets) on a contrib issue (http://tracker.moodle.org/browse/CONTRIB-2393). Since the last upload I've been solving all the block issues I found and adding new features:

Features

• Rollback applied presets
• Exclude "sensible" settings option and a new block setting to define that sensible settings
• Support for all the admin settings types
• New preset info fields

Issues solved

• XHTML Strict compliant
• Follows Moodle 2.0 javascript guidelines
• xml_writer for xml output and simplexml parsing
• JS tree compatibility for UTF-8 chars
• Format issues

Download link: http://tracker.moodle.org/secure/attachment/22343/admin_presets_2010112200.zip

Cool, thanks David!

Thanks David for the file:
http://tracker.moodle.org/secure/attachment/22343/admin_presets_2010112200.zip

Just a commentary the update of 2.0.2 use now the YUI 2.8.2

So we have to update the files styles.css who use some lib of YUI.

Hi Gilles,

To avoid the same issue on each YUI 2.x update I've copied the check icons to admin_presets/pix/ and I've changed the styles.css reference. Latest version available on https://github.com/dmonllao/moodle-block_admin_presets

Thanks for the report, all feedback will be veeeery welcomed

Hi, I've listed below all the related proposals I've found (and not already done) to see if there is enough work to do on that project to apply for GSOC and complete it. There are a lot of watchers and votes here and I suppose that someone will have preferences or new ideas.

• Finish all kind of plugins settings: auth, web services, plagiarism...
• Diff between presets
• Work with the command line installer
• Include roles and language files (and/or local strings)
• Include installed modules, question types...
• Viewable representation of presets (printable PDF or a nicely styles HTML file)
• Organize applied templated by preference

Download link on to the block <a href="http://moodle.org/mod/data/view.php?d=13&rid=4660" target="_blank">modules and plugins entry</a>

Hi David, here at The Open University we are looking into how we can easily synchronise settings across the multiple instances of Moodle that we have. I see there are no comments for the last year, is this project still active at all?
Thanks
Bryan

Hi Bryan,

admin_presets was the beginning of Moodle flavours, it was discountinued when began the development of flavours, I've just installed it in the latest MOODLE_22_STABLE and it works. Both projects exports/imports the site settings but they differs a bit; to resume admin_presets allows rollback, has an higher granularity and displays info about each setting but on the other hand it requires code modifications every time a new admin_settings child class is added to moodle core since it's an extension (non-intrusive) of the core admin settings tree classes, flavours does not have this limitation but doesn't manage presets history, settings changes...

This is the list of admin_settings not currently available to import/export using the admin_presets

• mod_quiz_admin_review_setting
• mod_quiz_admin_setting_grademethod
• mod_quiz_admin_setting_browsersecurity
• admin_setting_question_behaviour
• admin_setting_configmultiselect_modules
• admin_setting_devicedetectregex

I'll try to update the block during this week

Bryan, I've updated the block adding the missing settings types (http://tracker.moodle.org/browse/CONTRIB-3518) and solving a little visualisation problem (http://tracker.moodle.org/browse/CONTRIB-3519)

Last version in the new modules and plugins database, http://moodle.org/plugins/view.php?plugin=block_admin_presets (just uploaded, waiting for approval)

Repo URL: https://github.com/dmonllao/moodle-block_admin_presets

David - I've gone ahead and approved the block so folks can access it. Peace - Anthony

David, I guess admin_presets is looking promising for our needs and has the extra features that flavours does not have. What is required is the need to compare the settings you are importing, and going to apply to a server, with the settings currently on that server.

Thanks for making the updates, I'll take a look.

Bryan

Hi Bryan, I created an issue (http://tracker.moodle.org/browse/CONTRIB-3559) and added you as a watcher, the idea is to replace the current preview option with a preview of what happens if I apply that preset (~ a diff)