Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-28452

Convert user profile fields for messaging/networking into custom profile fields

    Details

    • Type: Improvement
    • Status: Reopened
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 2.1, 2.2.2, 2.7, 2.9.2, 3.0, 3.1
    • Fix Version/s: BACKEND
    • Component/s: Libraries, User management
    • Labels:
    • Affected Branches:
      MOODLE_21_STABLE, MOODLE_22_STABLE, MOODLE_27_STABLE, MOODLE_29_STABLE, MOODLE_30_STABLE, MOODLE_31_STABLE

      Description

      These fields are pretty easy to convert during an upgrade.

      1) Create a new user custom field. If it's not possible to replicate the full functionality using a text field type (eg note that Skype can show an online/offline icon) then you will have to create a special new user profile field type as a new plugin.
      2) Copy existing data into this new field.
      3) Drop old column from the user table.
      4) Make sure that all code no longer relies on this field.
      5) Make sure that all code that provides user data (eg web services) behaves as expected and APIs are not changed.

      Fields include:

      • Web URL
      • ICQ
      • Skype
      • AIM
      • Yahoo
      • MSN

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

              Hide
              quen Sam Marshall added a comment -

              Suggestion: For fields which are not very popular and might be dropped from a fresh install, the upgrade process should not migrate these fields unless there is at least one user entry that actually has them set.

              Note: I suspect this change might require alterations to backup/restore, which isn't noted in the description.

              Show
              quen Sam Marshall added a comment - Suggestion: For fields which are not very popular and might be dropped from a fresh install, the upgrade process should not migrate these fields unless there is at least one user entry that actually has them set. Note: I suspect this change might require alterations to backup/restore, which isn't noted in the description.
              Hide
              dobedobedoh Andrew Nicols added a comment -

              Translation is also a consideration – at present, the existing user fields are translatable, but by moving these to custom profile fields, they would cease to be translatable.

              Show
              dobedobedoh Andrew Nicols added a comment - Translation is also a consideration – at present, the existing user fields are translatable, but by moving these to custom profile fields, they would cease to be translatable.
              Hide
              dobedobedoh Andrew Nicols added a comment -

              Another thing to note with this is that the existing fields have certain additional options:

              • hidden unless moodle/usre:viewhiddendetails is set
              • as a URL

              The hidden details may require a change to customfields to allow testing against a specific capability rather than the default options of:

              • Not Visible
              • Visible to User
              • Visible to everyone

              The latter should be relatively easy to sort using the 'link' and 'link target' options.

              Show
              dobedobedoh Andrew Nicols added a comment - Another thing to note with this is that the existing fields have certain additional options: hidden unless moodle/usre:viewhiddendetails is set as a URL The hidden details may require a change to customfields to allow testing against a specific capability rather than the default options of: Not Visible Visible to User Visible to everyone The latter should be relatively easy to sort using the 'link' and 'link target' options.
              Hide
              aborrow Anthony Borrow added a comment -

              Andrew - I've linked this as being a duplicate of MDL-19043 and perhaps the issue of translation might better be handled if the fields were related to message providers. I am not sure that treating them as custom user profile fields is the best way to go. I've not thought it completely through but it seems that messaging/networking is more related to messaging than the custom user profile fields. I would like to see custom profile fields truly be user custom profile fields so that we do not obscure the meaning of those fields. Peace - Anthony

              Show
              aborrow Anthony Borrow added a comment - Andrew - I've linked this as being a duplicate of MDL-19043 and perhaps the issue of translation might better be handled if the fields were related to message providers. I am not sure that treating them as custom user profile fields is the best way to go. I've not thought it completely through but it seems that messaging/networking is more related to messaging than the custom user profile fields. I would like to see custom profile fields truly be user custom profile fields so that we do not obscure the meaning of those fields. Peace - Anthony
              Hide
              dobedobedoh Andrew Nicols added a comment -

              In which case Anthony, I shall pass the gauntlet back to moodle.com until a better plan is formulated!

              Cheers,

              Andrew

              Show
              dobedobedoh Andrew Nicols added a comment - In which case Anthony, I shall pass the gauntlet back to moodle.com until a better plan is formulated! Cheers, Andrew
              Hide
              poltawski Dan Poltawski added a comment -

              [we discussed this at EU meeting]

              The problem is that most of the fields aren't used for messaging, so at the moment putting them into message providers isn't really useful

              Show
              poltawski Dan Poltawski added a comment - [we discussed this at EU meeting] The problem is that most of the fields aren't used for messaging, so at the moment putting them into message providers isn't really useful
              Hide
              mudrd8mz David Mudrák added a comment -

              There is an issue with having the field titles, descriptions a helps localized. Currently the texts are defined as core strings. Once we convert them to custom fields, we need to find a way how to have the titles localized, too. We have the same issue with role names, for example. We can use multilang filter but for multilang sites like moodle.org (with many langs installed), the string is then very very long (hardly to even fit to the DB column).

              Show
              mudrd8mz David Mudrák added a comment - There is an issue with having the field titles, descriptions a helps localized. Currently the texts are defined as core strings. Once we convert them to custom fields, we need to find a way how to have the titles localized, too. We have the same issue with role names, for example. We can use multilang filter but for multilang sites like moodle.org (with many langs installed), the string is then very very long (hardly to even fit to the DB column).
              Hide
              salvetore Michael de Raadt added a comment -

              Thanks for reporting this issue.

              We have detected that this issue has been inactive for over a year. It was reported as affecting versions that are no longer supported.

              If you believe that this issue is still relevant to current versions (2.5 and beyond), please comment on the issue. Issues left inactive for a further month will be closed.

              Michael d.

              TW9vZGxlDQo=

              Show
              salvetore Michael de Raadt added a comment - Thanks for reporting this issue. We have detected that this issue has been inactive for over a year. It was reported as affecting versions that are no longer supported. If you believe that this issue is still relevant to current versions (2.5 and beyond), please comment on the issue. Issues left inactive for a further month will be closed. Michael d. TW9vZGxlDQo=
              Hide
              salvetore Michael de Raadt added a comment -

              I'm closing this issue as it has been inactive for over a year has been recorded as affecting versions that are no longer supported.

              This is being done as part of a bulk annual clean-up of issues.

              If you still believe this is an issue in supported versions, please create a new issue.

              Show
              salvetore Michael de Raadt added a comment - I'm closing this issue as it has been inactive for over a year has been recorded as affecting versions that are no longer supported. This is being done as part of a bulk annual clean-up of issues. If you still believe this is an issue in supported versions, please create a new issue.
              Hide
              marina Marina Glancy added a comment -

              Reopening the issue, because it is still relevant. And the more time passes since original Moodle development, the less sense the fields like "AIM", "ICQ" or "MSN" make. At the same time the existing list is not enough, moodle.org had to add "Twitter" and "Google+" to this list.

              Show
              marina Marina Glancy added a comment - Reopening the issue, because it is still relevant. And the more time passes since original Moodle development, the less sense the fields like "AIM", "ICQ" or "MSN" make. At the same time the existing list is not enough, moodle.org had to add "Twitter" and "Google+" to this list.
              Hide
              nadavkav Nadav Kavalerchik added a comment -

              Considering performance (of joining DB tables), It would be nice if we could create a Poll on the forums to get the community's opinion on the most important and most common (maybe 5) user profile fields and have them added to the user table, at the same time we remove some redundant out. or just convert their names, for example: maybe even convert "ICQ" to "User's title" (Mr. Ms. Dr.... ) and migrate existing fields with data to new custom profile fields.
              What do you all think?

              Show
              nadavkav Nadav Kavalerchik added a comment - Considering performance (of joining DB tables), It would be nice if we could create a Poll on the forums to get the community's opinion on the most important and most common (maybe 5) user profile fields and have them added to the user table, at the same time we remove some redundant out. or just convert their names, for example: maybe even convert "ICQ" to "User's title" (Mr. Ms. Dr.... ) and migrate existing fields with data to new custom profile fields. What do you all think?
              Hide
              aborrow Anthony Borrow added a comment -

              Converting some of the social media related fields to custom profile fields would at least allow folks to add what they need. Nothing is preventing them from doing so now. Then the user table could be cleaned up. I still think it might be worthwhile to think through how Moodle might interact with social media sites and to have a default list of the current most popular ones which could be added to or removed by site admins as desired. One of the pieces of information to note is whether the social media site could function as a messenger. Ultimately, we should consider the question of what the primary goal of having this information is. Do we want users to be able to interact with each other outside of Moodle, do we want Moodle to communicate with users using social media, might the Moodle site itself take on the role of social user, or other ways of leveraging social media for building knowledge? I would be interested in some community brain storming about what would be helpful.

              I would not be in favor of 'converting' a field to be something else. If we need to add a salutation then we should add whatever fields that we need and then figure out how to convert existing fields into something else so that the data can be moved to those tables and fields. Peace - Anthony

              Show
              aborrow Anthony Borrow added a comment - Converting some of the social media related fields to custom profile fields would at least allow folks to add what they need. Nothing is preventing them from doing so now. Then the user table could be cleaned up. I still think it might be worthwhile to think through how Moodle might interact with social media sites and to have a default list of the current most popular ones which could be added to or removed by site admins as desired. One of the pieces of information to note is whether the social media site could function as a messenger. Ultimately, we should consider the question of what the primary goal of having this information is. Do we want users to be able to interact with each other outside of Moodle, do we want Moodle to communicate with users using social media, might the Moodle site itself take on the role of social user, or other ways of leveraging social media for building knowledge? I would be interested in some community brain storming about what would be helpful. I would not be in favor of 'converting' a field to be something else. If we need to add a salutation then we should add whatever fields that we need and then figure out how to convert existing fields into something else so that the data can be moved to those tables and fields. Peace - Anthony
              Hide
              abias Alexander Bias added a comment -

              Hi all,

              in the course of getting rid of some of our core hacks, I examined this ticket here.
              We want to have the profile settings page of our users as short as possible and have therefore hidden unnecessary fields like the fields which are mentioned here with a core hack.
              Additionally, we don't want users to diligently fill fields which are not shown to anyone because of $CFG->hiddenuserfields.

              Therefore, we would be happy to see these fields which are mentioned in the ticket description removed from the user table and from the user settings:

              • icq
              • skype
              • yahoo
              • aim
              • msn
              • url

              I even would go one step further and also remove the personal information fields

              • phone1
              • phone2
              • institution
              • department
              • address
              • city
              • country
              • description
              • descriptionformat
                from the user table so that in the end, the user table only contains the personal information fields which are vital for a user account to exist. Everything else can be created by the admin according to their needs. I know that this issue is part of an Epic and should deal only with messaging profile fields, but in the end the additional fields I have mentioned should be handled exactly in the same way.

              We are thinking about spending some developer time on this issue, but have to be sure that we are doing it right.

              As a process, we would
              1. implement the upgrade steps described in the issue description + transfer the visibility of the newly created custom profile fields for existing installs
              2. remove the fields completely for new installs

              Concerning the translation problem which came up in the discussion:
              I think multilang strings are a feasible way of dealing with it. If it is a hard requirement to have these fields translated in the language customization and / or delivered by the language pack maintainers, then we are in a dead end situation and the fields can't be removed at all.

              I would be happy to hear your comments and therefore ping Martin Dougiamas, Marina Glancy, David Mudrák, Andrew Nicols

              Thanks,
              Alex

              Show
              abias Alexander Bias added a comment - Hi all, in the course of getting rid of some of our core hacks, I examined this ticket here. We want to have the profile settings page of our users as short as possible and have therefore hidden unnecessary fields like the fields which are mentioned here with a core hack. Additionally, we don't want users to diligently fill fields which are not shown to anyone because of $CFG->hiddenuserfields. Therefore, we would be happy to see these fields which are mentioned in the ticket description removed from the user table and from the user settings: icq skype yahoo aim msn url I even would go one step further and also remove the personal information fields phone1 phone2 institution department address city country description descriptionformat from the user table so that in the end, the user table only contains the personal information fields which are vital for a user account to exist. Everything else can be created by the admin according to their needs. I know that this issue is part of an Epic and should deal only with messaging profile fields, but in the end the additional fields I have mentioned should be handled exactly in the same way. We are thinking about spending some developer time on this issue, but have to be sure that we are doing it right. As a process, we would 1. implement the upgrade steps described in the issue description + transfer the visibility of the newly created custom profile fields for existing installs 2. remove the fields completely for new installs Concerning the translation problem which came up in the discussion: I think multilang strings are a feasible way of dealing with it. If it is a hard requirement to have these fields translated in the language customization and / or delivered by the language pack maintainers, then we are in a dead end situation and the fields can't be removed at all. I would be happy to hear your comments and therefore ping Martin Dougiamas , Marina Glancy , David Mudrák , Andrew Nicols Thanks, Alex
              Hide
              maherne Michael Aherne added a comment - - edited

              It's worth mentioning that it's not uncommon for system administrators to hijack one or more of the existing fields in the user table to hold important student identifiers as, unlike custom profile fields, these can be displayed as part of the user identity in the gradebook etc.

              For example, we use idnumber to hold a system "person code" which is essential for linking up to other systems, but this means nothing to academics, who use "registration number" to identify students. We pull registration number into the "msn" field so that it can be shown in the gradebook. I've always been a bit embarassed about this as it's such a horrible hack, but owned up to it at the last Moodlemoot and discovered at least 3 other sysadmins who are doing something similar!

              Before just removing these fields from the user table it might make sense either to:

              • allow custom profile fields to be shown as part of the "user identity", or
              • have a couple of generic identity fields in the user table that can be used for this sort of thing
              Show
              maherne Michael Aherne added a comment - - edited It's worth mentioning that it's not uncommon for system administrators to hijack one or more of the existing fields in the user table to hold important student identifiers as, unlike custom profile fields, these can be displayed as part of the user identity in the gradebook etc. For example, we use idnumber to hold a system "person code" which is essential for linking up to other systems, but this means nothing to academics, who use "registration number" to identify students. We pull registration number into the "msn" field so that it can be shown in the gradebook. I've always been a bit embarassed about this as it's such a horrible hack, but owned up to it at the last Moodlemoot and discovered at least 3 other sysadmins who are doing something similar! Before just removing these fields from the user table it might make sense either to: allow custom profile fields to be shown as part of the "user identity", or have a couple of generic identity fields in the user table that can be used for this sort of thing
              Hide
              abias Alexander Bias added a comment -

              Hi all,

              well, there was no answer from Moodle HQ staff after my post in january.

              I dare to ping again Martin Dougiamas, Marina Glancy, David Mudrák, Andrew Nicols who were part of the previous discussion to get some feedback and hope to be able to continue our work.

              Thanks,
              Alex

              Show
              abias Alexander Bias added a comment - Hi all, well, there was no answer from Moodle HQ staff after my post in january. I dare to ping again Martin Dougiamas , Marina Glancy , David Mudrák , Andrew Nicols who were part of the previous discussion to get some feedback and hope to be able to continue our work. Thanks, Alex
              Hide
              mudrd8mz David Mudrák added a comment -

              Localisation should not be an issue as we can convert every single field we have now into a separate custom field type plugin. It would also allow us to keep existing features like dynamic links to the social networks etc. Existing fields would continue being the standard plugin types and they could be easily used as templates for custom field types (e.g. when someone comes up with the cool "moodlr" app).

              Show
              mudrd8mz David Mudrák added a comment - Localisation should not be an issue as we can convert every single field we have now into a separate custom field type plugin. It would also allow us to keep existing features like dynamic links to the social networks etc. Existing fields would continue being the standard plugin types and they could be easily used as templates for custom field types (e.g. when someone comes up with the cool "moodlr" app).

                People

                • Votes:
                  11 Vote for this issue
                  Watchers:
                  15 Start watching this issue

                  Dates

                  • Created:
                    Updated: