feat: use extended profile model in account settings by BryanttV · Pull Request #37119 · openedx/openedx-platform

BryanttV · 2025-08-04T18:56:38Z

Description

This PR enhances the extended profile fields functionality, allowing use the custom extended profile model in the account settings.

Currently, when we have extended profile fields associated with the REGISTRATION_EXTENSION_FORM setting, it works in this way:

In the Registration, the additional custom fields are stored in the meta field of the UserProfile model, but are also stored in the custom model associated with the form. Here is the code.
In the Account Settings, it doesn't work that way. When we get or update the additional custom fields, the values are fetched and stored only in/from the meta field of the UserProfile model, but not in/from the custom model.

This PR introduces the possibility of storing those custom additional fields in the custom model when we update the Account Settings, maintaining parity and consistency similar to the registration process.

Testing instructions

Create a Tutor environment.
Create a mount of edx-platform with the changes in this PR.
```
tutor mounts add edx-platform
```

Add the following property to the LMS Django Admin > Site Configurations > local.openedx.io:8000

{
    "extended_profile_fields": [
        "nickname",
        "interests",
        "wants_newsletter",
        "favorite_language"
    ]
}

Install this app that includes the custom extra fields mentioned above: https://github.com/bryanttv/custom-extra-fields. You can use this setting in your config.yml
```
OPENEDX_EXTRA_PIP_REQUIREMENTS:
- git+https://github.com/bryanttv/custom-extra-fields.git
```

Create a tutor inline plugin and enable it with tutor plugins enable custom-settings

# custom-settings.yml
name: custom-settings
version: 1.0.0
patches:
  openedx-common-settings: |
    REGISTRATION_EXTENSION_FORM = "custom_extra_fields.forms.CustomExtraFieldsForm"

Run tutor dev launch
Create a user in the platform.
Go to {lms_domain}/api/user/v1/accounts/{username} in your browser. Be sure to use the application/merge-patch+json Media type in the DRF UI.

Test Cases

1. No Form (`REGISTRATION_EXTENSION_FORM = None`) and no extended profile fields

The response includes the extended_profile key as an empty list. This list cannot be updated because no fields are defined in the extended_profile_fields setting, and there is no extended form either.

{
    "extended_profile": [],
}

2. No Form (`REGISTRATION_EXTENSION_FORM = None`) and with extended profile fields

The fields defined in the extended_profile_fields setting are returned and can be updated. However, these fields do not have any validation, meaning any value can be assigned to them.

{
    "extended_profile": [
        {
            "field_name": "nickname",
            "field_value": true
        },
        {
            "field_name": "interests",
            "field_value": 0
        },
        {
            "field_name": "wants_newsletter",
            "field_value": "of course"
        },
        {
            "field_name": "favorite_language",
            "field_value": "spanish"
        }
    ]
}

3. With Form (`REGISTRATION_EXTENSION_FORM = "myapp.forms.ExtendedForm"`) and no extended profile fields

Fields defined in the form will be displayed in the legacy registration form if they are marked as required. However, if the extended_profile_fields property in the Site Configuration is not defined, no fields will be returned from the endpoint.

Still, the defined fields can be updated and will be validated according to the logic in the form.

If the form is associated with a model, additional validations from the model will be executed, and its fields will be updated as well. Data for the extended profile fields will also be extracted from that model.

{
    "extended_profile": [],
}

4. With Form (`REGISTRATION_EXTENSION_FORM = "myapp.forms.ExtendedForm"`) and with extended profile fields

When both settings are defined, the fields listed in extended_profile_fields are returned, each with its corresponding validation as defined in the form.

If the form is associated with a model, additional validations from that model will be applied, and its fields will be updated accordingly. Data for the extended profile fields will also be sourced from the model.

{
    "extended_profile": [
        {
            "field_name": "nickname",
            "field_value": "codewanderer"
        },
        {
            "field_name": "interests",
            "field_value": "Programming"
        },
        {
            "field_name": "wants_newsletter",
            "field_value": true
        },
        {
            "field_name": "favorite_language",
            "field_value": "python"
        }
    ]
}

Deadline

None

Demo

extended-profile-fields-in-account-settings.mp4

openedx-webhooks · 2025-08-04T18:56:43Z

Thanks for the pull request, @BryanttV!

This repository is currently maintained by @openedx/wg-maintenance-openedx-platform.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
- This process (including the steps you'll need to take) is documented here.
If it doesn't, simply proceed with the next step.

🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

Dependencies

This PR must be merged before / after / at the same time as ...
Blockers

This PR is waiting for OEP-1234 to be accepted.
Timeline information

This PR must be merged by XX date because ...
Partner information

This is for a course on edx.org.
Supporting documentation
Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

Details

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

The size and impact of the changes that it introduces
The need for product review
Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

openedx-webhooks · 2025-08-04T18:56:44Z

Thanks for the pull request, @BryanttV!

This repository is currently maintained by @openedx/wg-maintenance-edx-platform.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
- This process (including the steps you'll need to take) is documented here.
If it doesn't, simply proceed with the next step.

🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

Dependencies

This PR must be merged before / after / at the same time as ...
Blockers

This PR is waiting for OEP-1234 to be accepted.
Timeline information

This PR must be merged by XX date because ...
Partner information

This is for a course on edx.org.
Supporting documentation
Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

🔘 Update the status of your PR

Your PR is currently marked as a draft. After completing the steps above, update its status by clicking "Ready for Review", or removing "WIP" from the title, as appropriate.

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

The size and impact of the changes that it introduces
The need for product review
Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

efortish

Thank you so much for the contribution @BryanttV
Everything looks good, I followed your instructions step by step and it went great!

Can we add some edge-case tests suit for the new features in api.py and registration_form.py?

BryanttV · 2025-09-30T01:19:17Z

Thanks for the review, @efortish! I will be working on the unit tests for this functionality.

mariajgrimaldi · 2025-10-03T11:03:30Z

openedx/core/djangoapps/user_api/accounts/api.py

+            extended_profile_model = extended_profile_form.save(commit=False)
+            if not hasattr(extended_profile_model, "user") or extended_profile_model.user is None:
+                extended_profile_model.user = user_profile.user
+            extended_profile_model.save()


Is there a reason why do we have to do this double step save for the extended profile? Is it because L531 should raise errors before attaching the user? Wouldn't be safer to try save within an atomic transaction?

We can indeed use an atomic transaction, but we need to include both save operations.

The first one (with commit=False) creates the model instance without saving it to the database. The second one actually saves it to the database, including the user field if the instance doesn’t already have an assigned user. If we try to save the model without a user, it will fail.

Something similar is made here:
https://github.com/openedx/edx-platform/blob/7b953a5310ccd51d24207b70a17844ce3c83e664/common/djangoapps/student/helpers.py#L704-L709

I think we can use an atomic transaction and add a comment explaining why we need both save operations.

Done: 848a743

mariajgrimaldi · 2025-10-03T11:08:34Z

openedx/core/djangoapps/user_api/accounts/api.py

    _send_email_change_requests_if_needed(update, user)


+def _get_and_validate_extended_profile_form(update: dict, user, field_errors: dict) -> Optional[forms.Form]:


Not sure if update is the best name for this field, can we try something more descriptive? Also are we not typing user on purpose?

Suggested change

def _get_and_validate_extended_profile_form(update: dict, user, field_errors: dict) -> Optional[forms.Form]:

def _get_and_validate_extended_profile_form(updated_data: dict, user, field_errors: dict) -> Optional[forms.Form]:

Thanks! Updated: b0fa90a

mariajgrimaldi · 2025-10-03T11:30:41Z

openedx/core/djangoapps/user_api/accounts/api.py

+    try:
+        extended_profile_model = get_extended_profile_model()
+
+        kwargs = {}
+        if not extended_profile_model:
+            logger.info("No extended profile model configured")
+        else:
+            try:
+                kwargs["instance"] = extended_profile_model.objects.get(user=user)
+            except ObjectDoesNotExist:
+                logger.info("No existing extended profile found for user %s, creating new instance", user.username)
+
+        extended_profile_form = get_registration_extension_form(data=extended_profile_fields_data, **kwargs)
+
+        return extended_profile_form
+
+    except ImportError as e:
+        logger.warning("Extended profile model not available: %s", str(e))
+        return None
+    except Exception as e:  # pylint: disable=broad-exception-caught
+        logger.error("Unexpected error creating custom form for user %s: %s", user.username, str(e))
+        field_errors["extended_profile"] = {
+            "developer_message": f"Error creating custom form: {str(e)}",
+            "user_message": _("There was an error processing the extended profile information"),
+        }
+        return None


I think we can redude the level of nastiness here, here's a suggestion - haven't tested it though:

try: extended_profile_model = get_extended_profile_model() except ImportError: logger.warning("Extended profile model not available: %s", str(e)) return None kwargs = {} try: kwargs["instance"] = extended_profile_model.objects.get(user=user) except AttributeError: # Kind of ugly logger.info("No extended profile model configured") except ObjectDoesNotExist: logger.info("No existing extended profile found for user %s, creating new instance", user.username) try: extended_profile_form = get_registration_extension_form(data=extended_profile_fields_data, **kwargs) except Exception: logger.error("Unexpected error creating custom form for user %s: %s", user.username, str(e)) field_errors["extended_profile"] = { "developer_message": f"Error creating custom form: {str(e)}", "user_message": _("There was an error processing the extended profile information"), } return None return extended_profile_form

Thank you for your suggestion! 5d8d330

mariajgrimaldi · 2025-10-03T11:33:11Z

openedx/core/djangoapps/user_api/accounts/api.py

+    if not extended_profile_form.is_valid():
+        logger.info("Extended profile form validation failed with errors: %s", extended_profile_form.errors)
+
+        for field_name, field_errors_list in extended_profile_form.errors.items():
+            first_error = field_errors_list[0] if field_errors_list else "Unknown error"
+
+            field_errors[field_name] = {
+                "developer_message": f"Error in extended profile field {field_name}: {first_error}",
+                "user_message": str(first_error),
+            }


I think we can reduce 1 level of nestiness here by:

Suggested change

if not extended_profile_form.is_valid():

logger.info("Extended profile form validation failed with errors: %s", extended_profile_form.errors)

for field_name, field_errors_list in extended_profile_form.errors.items():

first_error = field_errors_list[0] if field_errors_list else "Unknown error"

field_errors[field_name] = {

"developer_message": f"Error in extended profile field {field_name}: {first_error}",

"user_message": str(first_error),

}

if extended_profile_form.is_valid():

return # Nothing to do here, the form is valid

logger.info("Extended profile form validation failed with errors: %s", extended_profile_form.errors)

for field_name, field_errors_list in extended_profile_form.errors.items():

first_error = field_errors_list[0] if field_errors_list else "Unknown error"

field_errors[field_name] = {

"developer_message": f"Error in extended profile field {field_name}: {first_error}",

"user_message": str(first_error),

}

Done: db4818c, thanks!

mariajgrimaldi · 2025-10-03T11:42:49Z

openedx/core/djangoapps/user_api/accounts/serializers.py

+    def get_extended_profile_data():
+        extended_profile_model = get_extended_profile_model()

-    # pick the keys from the site configuration
-    extended_profile_field_names = configuration_helpers.get_value('extended_profile_fields', [])
+        if extended_profile_model:
+            try:
+                profile_obj = extended_profile_model.objects.get(user=user_profile.user)
+                return model_to_dict(profile_obj)
+            except (AttributeError, extended_profile_model.DoesNotExist):
+                return {}

-    try:
-        extended_profile_fields_data = json.loads(user_profile.meta)
-    except ValueError:
-        extended_profile_fields_data = {}
+        try:
+            return json.loads(user_profile.meta or "{}")
+        except (ValueError, TypeError, AttributeError):
+            return {}


This section made me question something: is the profile meta and the extended profile model out of date at some point? Should they be in sync?

Every time we update the extended profile fields, they will be updated in both the model and the meta, so they should always be synchronized.

deborahgu · 2025-10-06T20:23:27Z

openedx/core/djangoapps/user_api/accounts/api.py

    _send_email_change_requests_if_needed(update, user)


+def _get_and_validate_extended_profile_form(update: dict, user, field_errors: dict) -> Optional[forms.Form]:


I'm not super happy about having form specific code in api.py. For that matter, I'm also not super happy about having form validators in api.py. That seems like form and view and validator code to me. api.py should be dealing with abstract data models, in my opinion.

If you can point to prior art where we do this, especially recent prior art, I'm willing to change my mind about that, but this really seems like, well...not dependency inversion, but dependency reversal. Your form.py should import from the API, not vice versa.

Hello @deborahgu, thanks for your comment! I made some changes according to your suggestions. Could you check again, please?

feanil

The approach makes sense to me. I did a quick AI guided review which left the above comment with some stuff to cleanup but higher level I have a bigger suggestion.

This will change the behavior in the case where someone is already using the REGISTRATION_EXTENSION_FORM but has different data in their meta field than in the registration form, since one this code is enabled the system will not load the meta information and only load the information they have in their registration extra fields.

I wonder if it makes sense to introduce a new setting PROFILE_EXTENSION_FORM which does everything the REGISTRATION_EXTENSION_FORM does but also all the new capabilities you're adding. We can also create a DEPR for the REGISTRATION_EXTENSION_FORM as this would become redundant.

What do you think of this approach? The setting name would also become more clear and accurate which is a refactor that we'll want to do eventually anyway so maybe makes sense to do it from the beginning.

BryanttV · 2026-03-03T16:56:31Z

Hi @feanil, thanks for the thoughtful feedback!

I agree with your approach. The new name is clearer and more accurate. For now, we can introduce the new setting and start the DEPR process by creating the corresponding ticket. I’ll begin working on that.

Regarding the AI-guided review, I’m not able to find the comment you mentioned about the code cleanup. Could you please point me to it?

…ependency

…PROFILE_EXTENSION_FORM setting

openedx-webhooks added the open-source-contribution PR author is not from Axim or 2U label Aug 4, 2025

openedx-webhooks added this to Contributions Aug 4, 2025

github-project-automation bot moved this to Needs Triage in Contributions Aug 4, 2025

BryanttV force-pushed the bav/use-extended-profile-model-in-account-settings branch 2 times, most recently from 12561c1 to dc1cee2 Compare August 5, 2025 17:35

BryanttV marked this pull request as ready for review August 5, 2025 18:10

BryanttV requested review from a team as code owners August 5, 2025 18:10

BryanttV requested a review from mariajgrimaldi August 5, 2025 18:11

mphilbrick211 moved this from Needs Triage to Ready for Review in Contributions Aug 5, 2025

BryanttV mentioned this pull request Aug 6, 2025

revert: remove extension points to get/update extended profile fields in the account settings fccn/edx-platform#29

Draft

BryanttV force-pushed the bav/use-extended-profile-model-in-account-settings branch from dc1cee2 to 04cdfb7 Compare August 6, 2025 22:53

BryanttV mentioned this pull request Aug 6, 2025

feat: use extended profile model in the account settings fccn/edx-platform#30

Open

BryanttV force-pushed the bav/use-extended-profile-model-in-account-settings branch 2 times, most recently from dae3705 to 065faee Compare August 11, 2025 17:48

efortish self-requested a review September 5, 2025 18:38

efortish suggested changes Sep 5, 2025

View reviewed changes

mphilbrick211 moved this from Ready for Review to In Eng Review in Contributions Sep 16, 2025

BryanttV force-pushed the bav/use-extended-profile-model-in-account-settings branch from 065faee to 06c8680 Compare September 30, 2025 01:17

openedx-webhooks added the core contributor PR author is a Core Contributor (who may or may not have write access to this repo). label Sep 30, 2025

mariajgrimaldi requested changes Oct 3, 2025

View reviewed changes

deborahgu requested changes Oct 6, 2025

View reviewed changes

BryanttV force-pushed the bav/use-extended-profile-model-in-account-settings branch from 06c8680 to 4e25200 Compare November 11, 2025 23:10

BryanttV force-pushed the bav/use-extended-profile-model-in-account-settings branch 2 times, most recently from f234f96 to b6b08c9 Compare November 21, 2025 17:43

BryanttV marked this pull request as draft November 21, 2025 20:26

BryanttV force-pushed the bav/use-extended-profile-model-in-account-settings branch from f15cab3 to 750e00a Compare November 24, 2025 18:46

mphilbrick211 requested a review from feanil March 2, 2026 19:17

feanil reviewed Mar 3, 2026

View reviewed changes

BryanttV force-pushed the bav/use-extended-profile-model-in-account-settings branch from f30ed36 to b9b26cc Compare March 3, 2026 22:38

BryanttV added 21 commits March 3, 2026 17:39

feat: use extended profile model in the account settings

6233b2d

feat: add bettter error handling in extended profile model function

6ff0412

docs: improve function docstring

30d8cb7

refactor: rename custom form functions to extended profile form

a898336

refactor: use atomic transaction and add comments

5747b74

refactor: rename parameter in extended profile form validation function

ad36b40

refactor: reduce levels of nastiness

62174ec

refactor: reduce level of nestiness

575ffbb

fix: correct key name

bf54af1

chore: run make format

4343e62

refactor: separate extended profile form validation from api layer

74f103d

fix: handle None case for extended profile form validation

966dc40

refactor: lazy import get_auto_generated_username to avoid circular d…

62608df

…ependency

refactor: rename variable for clarity in extended profile saving process

21a6bbb

test: add unit tests for extended profile form functions

666a442

test: add unit tests for get_extended_profile function

176cd20

test: add unit tests for updating extended profile

9d2a40f

test: add unit tests for extended profile in account api view

fe47add

test: add unit tests for get_extended_profile_model function

e620c7f

chore: add missing whitespace

287bc44

test: remove unnecessary unpack decorator

4fb774b

BryanttV force-pushed the bav/use-extended-profile-model-in-account-settings branch from b9b26cc to cc79b5d Compare March 3, 2026 22:39

refactor: update registration extension form handling to support new …

350b9c1

…PROFILE_EXTENSION_FORM setting

BryanttV force-pushed the bav/use-extended-profile-model-in-account-settings branch from cc79b5d to 350b9c1 Compare March 3, 2026 23:03

refactor: remove redundant logging import in registration form view

cecbb7c

BryanttV force-pushed the bav/use-extended-profile-model-in-account-settings branch from 9ea2a62 to cecbb7c Compare March 3, 2026 23:24

		_send_email_change_requests_if_needed(update, user)


		def _get_and_validate_extended_profile_form(update: dict, user, field_errors: dict) -> Optional[forms.Form]:

Conversation

BryanttV commented Aug 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Testing instructions

Test Cases

1. No Form (REGISTRATION_EXTENSION_FORM = None) and no extended profile fields

2. No Form (REGISTRATION_EXTENSION_FORM = None) and with extended profile fields

3. With Form (REGISTRATION_EXTENSION_FORM = "myapp.forms.ExtendedForm") and no extended profile fields

4. With Form (REGISTRATION_EXTENSION_FORM = "myapp.forms.ExtendedForm") and with extended profile fields

Deadline

Demo

Uh oh!

openedx-webhooks commented Aug 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openedx-webhooks commented Aug 4, 2025

Uh oh!

efortish left a comment

Choose a reason for hiding this comment

Uh oh!

BryanttV commented Sep 30, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

deborahgu Oct 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

feanil left a comment

Choose a reason for hiding this comment

Uh oh!

BryanttV commented Mar 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

BryanttV commented Aug 4, 2025 •

edited

Loading

1. No Form (`REGISTRATION_EXTENSION_FORM = None`) and no extended profile fields

2. No Form (`REGISTRATION_EXTENSION_FORM = None`) and with extended profile fields

3. With Form (`REGISTRATION_EXTENSION_FORM = "myapp.forms.ExtendedForm"`) and no extended profile fields

4. With Form (`REGISTRATION_EXTENSION_FORM = "myapp.forms.ExtendedForm"`) and with extended profile fields

openedx-webhooks commented Aug 4, 2025 •

edited

Loading

deborahgu Oct 6, 2025 •

edited

Loading