/
githubmirror
/
edx-platform
ОбзорДокументацияВойти
/
githubmirror
/
edx-platform
Код
Запросы
0
Пакеты
0
Релизы
0
Аналитика
Безопасность
ДокументацияПоддержка
Политика конфиденциальностиПользовательское соглашениеПолитика использования «cookies»Согласие субъекта персональных данных
2026 ©
edx-platform/
.../djangoapps/user_api/
..
accounts

feat: simplify retirement cleanup by removing custom redaction value parameters (#412)

9 дней назад
course_tag

fix: add a couple guards for anonymous users

5 лет назад
management

fix: correct fallback handling for email opt-in report (#38410)

21 день назад
migrations

chore: Update retire_user management command (#31966)

3 года назад
preferences

refactor: Remove HIBP settings from CMS (#36998)

год назад
templates

revert: add brand_color variable for the email templates (#33421)"

3 года назад
tests

test: Make pytz api related tests more resilient.

год назад
verification_api

feat: deprecate get_verification_details_by_id (#35560)

2 года назад
README.rst

feat: fixing swagger doc for user accounts (#37043)

год назад
__init__.py

Add base support for cohorted group configurations

12 лет назад
admin.py

feat: display the reset toggles for a report (#37556)

10 месяцев назад
api.py

feat: purge name from certificate records during user retirement (#34799)

2 года назад
errors.py

refactor: Ran pyupgrade on openedx/core/djangoapps/user_api

5 лет назад
helpers.py

fix: fixed django4 warnings (#29643)

4 года назад
legacy_urls.py

fix: redirect to account MFE when using any legacy account URL (#36894)

год назад
message_types.py

refactor: Ran pyupgrade on openedx/core/djangoapps/user_api

5 лет назад
middleware.py

Use full names for common.djangoapps imports; warn when using old style (#25477)

6 лет назад
models.py

feat: make notification emails translatable (#36775)

год назад
partition_schemes.py

fix: fix github url strings (org edx -> openedx)

4 года назад
permissions.py

BOM-2329: Applied pylint-amnesty to system_wide_roles, theming, user_api, user_authn

6 лет назад
rules.py

chore: log the user triggering the retirement flow chore: change user retirement permissions to allow support staff

3 года назад
serializers.py

Refactor: Removed unused imports Removed unused imports from openedx/core/djangoapps/user_api

5 лет назад
urls.py

feat!: remove `skill_levels` API (#35863)

2 года назад
views.py

feat: lint this file (#35348)

2 года назад
README.rst
Status: Active
 
Responsibilities
================
The user_api app is currently a catch all that is used to provide various apis that are related to the user and also to features within the platform.
 
Intended responsibility: To manage user profile and general account information and to provide APIs to do so easily. This includes the following features: user preference, user profile, user retirement, and account activation/deactivation.
 
Direction: Decompose
====================
Currently this app is a catch all for many user related information even when that information should really belong in a different app. If you are building a feature and need to provide information about a user within the context of your feature, you should localize that API to your feature and make your assumptions about what user information you need clear.
 
For example authentication related APIs have already been moved to the user_authn django app.
 
Glossary
========
 
More Documentation
==================
 
Persisting Optional User Metadata
*********************************
The User API is capable of storing optional learner metadata through the use of a feature called the **Extended Profile**. The **Extended Profile** is a lightweight option for storing optional user data that doesn't require the modification or update of existing Django models.
 
This data is persisted as part of the ``meta`` field of a learner's UserProfile instance.
 
Storing data requires a *PATCH* request to be made to the User API endpoint.
 
This request data must include a key named **extended_profile** that contains a list of dictionaries representing the additional data we wish to store for the learners. Each dictionary in the list must include two fields:
 
* ``field_name``: A name describing the data to be stored
* ``field_value``: The data to be stored
 
An example request using *curl*, storing information in a field named ``occupation``:
 
.. code-block:: bash
 
curl --request PATCH '{{lms_host}}/api/user/v1/accounts/{{lms_username}}' \
-- header 'Authorization: JWT {{jwt_token}}' \
-- header 'Content-Type: application/merge-patch+json' \
-- data '{
"extended_profile": [
{
"field_name:" "occupation",
"field_value": {
"name": "Organic Farmer",
"salary": "65000"
}
}
]
}'
 
It is important to note that this data will not be returned as part of the User API until the system's Site Configuration has been updated. Details on how to update the Site Configuration can be found at `Retrieving Extended Profile Metadata`_.
 
.. _Retrieving Extended Profile Metadata: https://docs.openedx.org/en/latest/site_ops/install_configure_run_guide/configuration/retrieve_extended_profile_metadata.html