Moodle
  1. Moodle
  2. MDL-26347

Allow plug-ins to define new user profile fields

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Inactive
    • Affects Version/s: 2.0.1
    • Fix Version/s: DEV backlog
    • Component/s: General
    • Labels:
    • Database:
      Any
    • Difficulty:
      Moderate
    • Affected Branches:
      MOODLE_20_STABLE

      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!

        Gliffy Diagrams

          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.
            Hide
            Marina Glancy added a comment -

            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==

            Show
            Marina Glancy added a comment - 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==

              People

              • Votes:
                5 Vote for this issue
                Watchers:
                9 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: