Description

I'm working on a couple of local plug-ins for the OU which have user preferences associated with them. Rather than have user controls scattered throughout the interface, I've been asked to put them all in the main user profile. Arguably these controls should be at the point of use instead/as well - but that's a different debate.

At the moment I'm creating the new profile fields by getting the plug-in database update &/or after install scripts include the custom profile category & field definitions. This is because I don't want to just use the manual admin screens for custom profile setup. Some of these plug-ins will be shared and I don't want them to go out with a long list of manual config changes.

Ideally, an extra settings script would allow the developer to define categories and/or fields in code. These categories and fields would be saved into the existing custom profile category and field infrastructure so that the display and data saving routines already in place for custom profile fields can be leveraged.

An extra database column on the custom profile category and field definition tables will be required. This will be a boolean flag to indicate whether the row has been set up manually or through a plug-in hook. Where categories and fields have been set up manually, they can be edited through the existing admin interface. However, those which have been set up through the plug-in hook should only be editable through that hook.

This needs more thought e.g. how will updates be identified on upgrade? Whats the difference between editing an existing field and deleting old & adding new field? Perhaps the boolean flag described should be a version number which can be tested on upgrade? Or will aboolean be adequate and "spot the difference" with the existing definitions? Any update mustn't drop any existing data in the field - changing an existing field's type or the uniqueness property from no to yes should cause a developer debug error. Changing uniqueness from yes to no is acceptable since this does not cause data loss.

I realise this is quite a big thing to suggest. Comments very welcome!

I'm moving this to the DEV backlog as far as it's something that shouldn't land to stable initially.

Personally, I'd say that this shouldn't land to anywhere ever, because I don't like handling/hacking potential interdependences in that way at all. IMO the solution should be something like the module, once installed, showing one big "you need to create one custom profile field xxxx" before being able to use this module" or so. And then allow the admin to do so and continue with the module.

But never mixing both worlds or "remotely/automatically" creating that sort of stuff.

Eloy Lafuente (stronk7)
added a comment - 12/Feb/11 1:22 AM I'm moving this to the DEV backlog as far as it's something that shouldn't land to stable initially.
Personally, I'd say that this shouldn't land to anywhere ever, because I don't like handling/hacking potential interdependences in that way at all. IMO the solution should be something like the module, once installed, showing one big "you need to create one custom profile field xxxx" before being able to use this module" or so. And then allow the admin to do so and continue with the module.
But never mixing both worlds or "remotely/automatically" creating that sort of stuff.
So my +1 goes for closing this as won't fix.
Ciao

The only interdependence here is between profile and plug-in, not between plug-ins. We could use something other than the existing custom profile fields tables to store the data, but I was trying to keep it simple. If anything, done correctly, this code would avoid potential naming clashes with new profile fields and so reduce interdependence risk.

What I want is a way for all the user settings for my plug-in to be defined in code, and made available for review on the profile screen. Between you, Petr and Eloy, you've triaged all my profile extensions over the last few days. Think of this very much as an extension of MDL-26346 so that the plug-in can make a new section of the profile. I like Sam's suggestion in the forum that the UI of the plug-in would offer the settings close to point of use, but that the profile category would be a gathering point, backup for review.

Jenny Gray
added a comment - 14/Feb/11 5:35 PM The only interdependence here is between profile and plug-in, not between plug-ins. We could use something other than the existing custom profile fields tables to store the data, but I was trying to keep it simple. If anything, done correctly, this code would avoid potential naming clashes with new profile fields and so reduce interdependence risk.
What I want is a way for all the user settings for my plug-in to be defined in code, and made available for review on the profile screen. Between you, Petr and Eloy, you've triaged all my profile extensions over the last few days. Think of this very much as an extension of MDL-26346 so that the plug-in can make a new section of the profile. I like Sam's suggestion in the forum that the UI of the plug-in would offer the settings close to point of use, but that the profile category would be a gathering point, backup for review.

I'd be really grateful if you could take another look at this, as I'm under pressure to develop something for the summer and would really prefer to do it in core rather than implement a nasty OU-only hack.

Jenny Gray
added a comment - 22/Feb/11 6:51 PM Following a brainstorming session with Tim and Sam, I've worked up an outline design based on user_preferences rather than custom profile fields.
http://docs.moodle.org/en/Development:User_preferences_for_plug-ins
I'd be really grateful if you could take another look at this, as I'm under pressure to develop something for the summer and would really prefer to do it in core rather than implement a nasty OU-only hack.

Petr Skoda
added a comment - 09/Aug/12 4:38 PM I suppose this could be very useful for the new tinymce subplugin preferences and the editor preferences in general MDL-33041 . Is there any plan to implement this in the near future?

Hi Petr - that's exactly the sort of thing I had it in mind for. Unfortunately we've had to limit our developments in this area for the time being because of time constraints and so this is no longer on my top-priority list. As I see MDL-33041 is assigned to Sam, I will mention this to Ross and see if he's willing to spend our time on it now or not.

Jenny Gray
added a comment - 16/Aug/12 5:09 PM Hi Petr - that's exactly the sort of thing I had it in mind for. Unfortunately we've had to limit our developments in this area for the time being because of time constraints and so this is no longer on my top-priority list. As I see MDL-33041 is assigned to Sam, I will mention this to Ross and see if he's willing to spend our time on it now or not.

We have detected that this issue has been inactive for over two years and also did not collect many votes. It is possible that it has been already implemented in a more recent version of Moodle, or it is not highly demanded. There are unlimited number of ways Moodle functinality can be expanded and improved but we would like to concentrate on the features that will benefit majority of users, and which can not be implemented as plugins. If you have a suggestion for improving Moodle core, and there is no open issue for it in the tracker, please start a new forum discussion to see how many other users agree with you, and then create a new issue providing as many details as possible.

Marina Glancy
added a comment - 21/Nov/14 4:25 PM We have detected that this issue has been inactive for over two years and also did not collect many votes. It is possible that it has been already implemented in a more recent version of Moodle, or it is not highly demanded. There are unlimited number of ways Moodle functinality can be expanded and improved but we would like to concentrate on the features that will benefit majority of users, and which can not be implemented as plugins. If you have a suggestion for improving Moodle core, and there is no open issue for it in the tracker, please start a new forum discussion to see how many other users agree with you, and then create a new issue providing as many details as possible.
==BLK2YIMP20141121==