Could plug-ins define user profile fields?

Could plug-ins define user profile fields?

by Jenny Gray -
Number of replies: 13

I'm gathering a set of requirements for our next generation VLE (Moodle 2) which all 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 really like is for a plug-in (module, block, course format, local plug-in...) to be able to define a user profile field that relates to the plug-in and have that field automatically added to the edit profile screen.

At the moment what I'm doing is using the "custom user profile fields" to set up  the controls that I want, and then using them from the plug-in.  I get the plug-in installer to create the custom profile field in the db rather than manually using the admin screens to create it.

I'd like feedback from other developers - would you like to be able to add user profile controls from your plug-ins?

On a related note, I'd like to extend the custom user profile fields so that they can display the "description" text that the admin enters to the user.  As far as I can tell that text is never used at the moment.  I'd also like to add additional help text for my custom field that would pop up with the help button. The idea is to allow it to look a bit like this...

 

Does that sound useful to other people?

Finally, we're going to end up with a very long user profile edit screen.  One suggestion to resolve this has been to put each of the custom profile categories onto a separate tab within the edit profile screen, so they could be edited and saved separately to the basic profile.

Views, opinions?

I haven't set anything up in Tracker for this yet, but I will, once I've got a feel for whether its "just me" or not!!

Average of ratings: -
In reply to Jenny Gray

A collection of improvements for custom user profile fields

by Jenny Gray -

I've been doing a bit more thinking about this, and split up all the different things into separate issues as some are easier than others to acheive!

Here are the tracker references - please vote or leave comments if you're interested!

MDL-26342 - add help popups to custom profile fields

MDL-26343 - display a description prompt with custom profile fields

MDL-26344 - new radio button custom profile field type

MDL-26345 - add static description text to custom profile category

MDL-26346 -  split custom profile categories onto separate tabs of the edit profile screen

MDL-26347 - plug-ins controlling custom profile fields

Note, Dan Marsden also pointed out an improvement to custom user profile fields that he's been wanting for a while that would allow you to move fields anywhere in the main profile. MDL-10504.  I like that idea too, but I'm not sure how it would fit with the tabbed user profile screen.  Can we do the two together, or does it have to be an either/or choice?

Average of ratings: Useful (2)
In reply to Jenny Gray

Re: A collection of improvements for custom user profile fields

by Dan Marsden -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Plugins guardians Picture of Testers Picture of Translators

tabs and reordering should be possible to do together -each tab would generate it's own mform - the reordering code would then allow you to re-order the fields on each page.

Average of ratings: -
In reply to Jenny Gray

Re: A collection of improvements for custom user profile fields

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

It all sounds sensible and worth doing to me, except MDL-26347.

To start with, that sort of user-preference should have its UI within the owning plugin's UI at the point of use (e.g. quiz reports just remember the settings you last used). These settings should be stored using get/set_user_preferences. That mechanism is not really aware of different plugins, but there should a strong convention that preferences start with the plugin name (so block_myblock_somesetting.

However, perhaps there is a value in having a secondary UI seeing all your user preferences somewhere in your profile, and being able to edit them. If that was implemented, then we could take some existing settings out of the user table (e.g. forum auto-subscribe, use html editor, use ajax, ...).

However, rather than abusing custom user profile fields for this, I think the correct solution is to make a system like the admin settings tree, that lets plugins declare what settings they store in user_preferences in a way that lets Moodle automatically build a UI for users to edit those settings. This could take the form of a userprefereces.php, that is a bit like settings.php.

If you were doing that, I would also suggest that at the same time you change the user_preferences system so that it is explicitly aware of which plugins each preference belongs to. That is, you should add a component field to the user_preferences table that holds the frankenstyle plugin name, and make and appropriate change to the get/set_user_preferences API. Hopefully you can do that while keeping things backwards compatible.

Average of ratings: -
In reply to Tim Hunt

Re: A collection of improvements for custom user profile fields

by Jenny Gray -

I commented in the tracker issue that arguably this stuff should be in get/set_user_preferences and that the UI should be at the point of use.  Its an ongoing debate I'm having with our design team.

Their concern is that having a number of these settings "scattered" throughout the UI for a range of different plug-ins is confusing for students, and that it would be better for them to be gathered together in one place - and the obvious place for that is the user profile.

That's one of the reasons I posted this - maybe we're going about it the wrong way and I wanted to see if any-one else could see a use for this.

Average of ratings: -
In reply to Jenny Gray

Re: A collection of improvements for custom user profile fields

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

I think that if you get the UI right, the sudents should not even have to be aware that there is a list of settings.

For example, when your browser pops up the "Do you want to save this password" message, the choice to never ask to save passwords again is right there. That seems to be the right UI to me.

Average of ratings: -
In reply to Jenny Gray

Re: A collection of improvements for custom user profile fields

by sam marshall -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

(note: I haven't read Jenny's feature requests. Just commenting about this specific issue.)

I think there's a good argument for having an interface to user preferences in the profile, but not instead of a custom interface in a more appropriate location; in some cases, in addition to it.

For example, there are a few places in our interface where we have 'don't show this again' preferences. Typically once you choose that there is no way to undo it, which causes concern smile Or else we have to build some stupid per-module 'undo the don't show this' page. The obvious place to undo these settings would be in or near the profile. But the obvious place to set them in the first place is right by the thing you don't want to show...

It might also be convenient for admin staff to have a way to see what a user has chosen for various user preferences without having to log in as that user; again, the profile would be an obvious location.

--sam

Average of ratings: -
In reply to Tim Hunt

Re: A collection of improvements for custom user profile fields

by Jenny Gray -

Following Tim's comments and some from Eloy and Petr in the tracker, I've reworked this idea, with input from Tim and Sam (many thanks) into something that will hopefully be less contentious.

http://docs.moodle.org/en/Development:User_preferences_for_plug-ins

Please comment!

Average of ratings: -
In reply to Jenny Gray

Re: A collection of improvements for custom user profile fields

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Basically, I think this is a really good idea (surprise, surprise).

Some minor comments:

  1. I was going to say that in other places, e.g. mdl_files, the plugin column was called component, and you should be consistent. Then I looked at the mdl_config_plugins table and saw that it uses plugin, so we already have a bloody mess. Oh dear.
  2. With set_user_preferences, how often would you actually want to set preferences belonging to several different plugins. So, would it be better to just add a single string $plugin argument, defaulting to null, like the other functions?
  3. I'm worried about the performance impact of having to iterate through all plugins to build the settings block.
  4. Rather than making plugin developers do work to implement the Admin override bit, can't this be automatic? A bit of the admin tree (externalpage?) that parses all the userpreferences.php files, and make a place where admins can set a site-specific default for each setting, and whether students are allowed to change from that default?
  5. The "Further tidying up possible" are all good ideas.
Average of ratings: -
In reply to Tim Hunt

Re: A collection of improvements for custom user profile fields

by Jenny Gray -

Tim, Thanks so much for commenting again.  I've added some comments to the wiki page for 1 and 2.

With 4 - I'm not sure whether that should be done outside the plug-in settings?  As an admin, I would logically expect to be able to control all the plug-in's functionality from within its settings screen rather than from a separate admin panel.

That said, I wonder if your suggestion for 4 could help with 3 - if we had a single page to switch them on/off we could store the set that are enabled as a separate config and use that rather than iterating through plugins for every settings block build.  Unless there's some other place to cache it?

To be honest, I only added the admin override as an afterthought when I realised that most of the studyplan course format personalisation options will be pointless when we move OpenLearn to Moodle 2, and I'll need to disable them! (Comments about how pointless they are in general taken as read).

Average of ratings: -
In reply to Jenny Gray

Re: A collection of improvements for custom user profile fields

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Yes, 4 could help with 3.

And, I see your point about expecting the plugin's user preference defaults to be with the pugins other admin settings. It might even be possible to automate that. Except, what about a plugin that has user preferences but no admin settings? (I expect we could generate a settings page automatically, so that would be OK.) What about a plugin that uses and admin_externalpage as its settings page (e.g. qtype_opaque, and possibly block workflow). Well, niether of those have user preferences, but if they did, you could either a. not automatically generate admin settings for the defaults; b. do some developer debugging explaining that is not possible; or c. create a new settings page for those settings.

OK, so 4. is basically doable with the user pref defaults on the plugin settings page for all plugins, and would be cool, but is not essential to implement at this stage.

Average of ratings: -
In reply to Jenny Gray

Re: Could plug-ins define user profile fields?

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
We've been doing a project with this and all sorts of other post-install configuration changes (new roles etc). I ended up creating a local plugin (guaranteed to load last) and did it all in the db/install.php file.

It's ok but it would be nicer if the field could be bound in some way to the plugin.

My other missing plugin feature was allowing a plugin to create its own roles and add capabilities to them.

Another one... having plugins that define instances (e.g. blocks and modules) appear by default in defined places.

There's lots of fun stuff that can be added to plugins smile

Average of ratings: -
In reply to Jenny Gray

Re: Could plug-ins define user profile fields?

by stuti bhavsar -

Hello Jenny!

I also want to implement the same functionality in my one of the sites (placing help button next to custom user profile field on the signup page) but I am not getting to it.

Can you please suggest me how to implement the same?

Average of ratings: -
In reply to stuti bhavsar

Re: Could plug-ins define user profile fields?

by Jenny Gray -

Custom profile fields are defined in the user/profile folder of the codebase.  There's a folder for each type of custom profile field: checkbox, datetime, menu...

You'd need to find the folder for the type of field you want to use and edit the code to

  • add a box for admins to type in the help text when setting up the custom profile field
  • add the help to the form field on display

I haven't had time to work out exactly which file/function you edit to do each of these, but I think define.class is the first one and field.class is the second one.

If you wanted to do something generic, you should extend profile_define_base and profile_field_base so that it ought to work for all types of custom profile field.  This could then be offered through the tracker issue MDL-26342 for integration.

Hope that helps

Jenny

Average of ratings: -