User preferences for plug-ins

This page is associated with discussion about allowing plug-ins to declare their own user settings screens.

• Forum thread http://moodle.org/mod/forum/discuss.php?d=168322
• Tracker issue MDL-26347

Overview

One strand of development for the Open University UK's next generation VLE focusses on features which allow the student to be able to personalise their experience with various different parts of the system. What it boils down to is them being able to switch bits on and off.

What I'd like is for a plug-in (module, block, course format, local plug-in...) to be able to define a user settings screen that relates to the plug-in and have that screen automatically added to the profile section of the settings block.

Discarded thoughts

Initially I thought this could be done through the custom user profile fields, where each plug-in would define a custom profile category (only editable through code) and each category would be displayed as a separate item in the profile settings navigation.

There was a lot of concern (see MDL-26347 comments) from Eloy and Petr about interdependence of functionality.

This new proposal builds on a suggestion from Tim in the forum thread to use user_preferences instead, since this does not have a UI for admins to interact with. Tim, Sam and I have worked together to rough this outline for further discussion...

Database

User preferences will be stored in the existing core user_preferences table, rather than in tables associated with the plug-in.

The user_preferences table will be extended to add a plug-in column, for improved data integrity (optional - the rest of this design could work without this change, either in the short term to allow an early inclusion in 2.0.x or for ever).

Current best practice is to include the plug-in name in the name of the user_preference, so this extension will simplify that. The table will be populated as follows

• Userid
  • the id number for current $USER
  • as currently defined
• plugin
  • frankenstyle name
  • allowed null for backward compatibility
• Name
  • the setting being stored
  • as currently defined
• value
  • the user's choice
  • as currently defined

Get and Set functions

The data continues to be accessed through the existing functions which are extended to cope with the optional plugin parameter.

get_user_preferences

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be checked when accessing the data. Otherwise, just the name and user parameters, and a null plugin value will be checked.

set_user_preference

An additional optional plugin parameter will be added. This will default to null if no parameter is passed, for backward compatibility.

If the plugin parameter is received then this, as well as the name and user parameters will be inserted in the database. Otherwise, just the name and user parameters, and a null plugin value will be inserted.

set_user_preferences

This function takes an array of key/value pairs and saves all of them in the user_preferences table. This would be extended to optionally take an array of arrays of key/value pairs.

The first array would be indexed with the plugin name, so $array['plugin1'] contains all the key/value pairs for plugin1.

If an array of arrays is received, then each array's key/value pairs are inserted with the array's index inserted as the plugin value in the database row. If a simple array of key/value pairs is received, these are inserted with a null plugin value.

Settings block

Where these plugins are not enabled, the settings page would not be included in the profile settings navigation.

The user/edit.php page will need to display the Settings block. Therefore, its pagelayout would need to be set to something that displayed user blocks as they are displayed on the view profile page. Core themes (like boxxie) which add blocks on the user/edit.php page would need to be updated to remove that control.

Plug-in interface

The code within userpreferences.php would be an extension of the way admin configuration settings.php files work. However, since the forms will be aimed at users rather than admins, the form fields will optionally need additional help text.

Each userpreferences.php file would create a new form, which would appear in the user profile section of the Settings block as an extra link below Edit profile. The link will be highlighted with CSS to indicate the currently open page – in the same way as currently happens for edit profile.

Further tidying up possible

A number of fields on the current user profile form could be moved and placed more appropriately with their plug-ins, or into a new form for general preferences. This would leave the main profile form solely responsible for personal data about the user.

Here is a list of current user profile fields which fall into this situation - most would problably move to a "general" tab as they affect multiple plugins. In particular, I'm not sure what to do with the messaging ones, as they shouldn't be disabled if system private messaging is disabled, but they don't belong just with forum.

• General
  • Use HTML editor
  • Ajax and JavaScript
  • Screen reader
  • Preferred language
• Messaging
  • Email format
  • Email display
  • Email digest type
• Forum
  • Forum autosubscribe
  • Forum tracking

Generated settings form

The save and cancel buttons should intuitively take you back to the course home page. If they visit their profile from a course home or content page, the global $COURSE variable will be available and the id property can be used to define the redirect. Alternatively, the lastcourseaccess property of the global $USER variable stores the last visit on all their available courses, and so can be used to identify the last course they looked at for the definition of the redirect. If the lastcourseaccess property of the global $USER variable is empty, the user should be redirected to the latest course on which they were enrolled.

Backup and restore

User settings, because they are stored using the core user_preferences functionality are already catered for in backup and restore procedures, so no further extension will be required.

Template:CategoryDeveloper