Moodle
  1. Moodle
  2. MDL-26347

Allow plug-ins to define new user profile fields

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.0.1
    • Fix Version/s: DEV backlog
    • Component/s: General
    • Labels:
    • Database:
      Any
    • Difficulty:
      Moderate
    • Affected Branches:
      MOODLE_20_STABLE
    • Rank (Obsolete):
      15987

      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!

        Issue Links

          Activity

          Hide
          Jenny Gray added a comment -

          There's some forum discussion on this one here http://moodle.org/mod/forum/discuss.php?d=168322

          Show
          Jenny Gray added a comment - There's some forum discussion on this one here http://moodle.org/mod/forum/discuss.php?d=168322
          Hide
          Eloy Lafuente (stronk7) added a comment -

          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

          Show
          Eloy Lafuente (stronk7) added a comment - 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
          Hide
          Petr Skoda added a comment -

          my +1 for will not fix too because plugin interdependence is very problematic

          Show
          Petr Skoda added a comment - my +1 for will not fix too because plugin interdependence is very problematic
          Hide
          Jenny Gray added a comment -

          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.

          Show
          Jenny Gray added a comment - 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.
          Hide
          Jenny Gray added a comment -

          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.

          Show
          Jenny Gray added a comment - 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.
          Hide
          Martin Dougiamas added a comment -

          I like that approach much better! (thanks for the nice spec!)

          Show
          Martin Dougiamas added a comment - I like that approach much better! (thanks for the nice spec!)
          Hide
          Petr Skoda added a comment -

          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?

          Show
          Petr Skoda added a comment - 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?
          Hide
          Jenny Gray added a comment -

          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.

          Show
          Jenny Gray added a comment - 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.

            People

            • Votes:
              4 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated: