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

      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

          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

              People

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

                Dates

                • Created:
                  Updated: