Some models in third_party_auth used settings.SITE_ID as a field
default, which caused Django to say migrations were out of sync whenever
settings.SITE_ID happened to be anything other than 1 for any developer:
Your models in app(s): 'third_party_auth' have changes that are not
yet reflected in a migration, and so won't be applied. Run
'manage.py makemigrations' to make new migrations, and then re-run
'manage.py migrate' to apply them.
This could easily happen if a developer is testing out site
configuration or site-specific theming and ends up with a SITE_ID other
than 1.
The fix, inspired by a StackOverflow answer [1], is to simply create
a wrapper function for the dynamic default value. The wrapper function,
rather than the current value of SITE_ID, will be serialized to the
migraiton file.
This commit includes a migration file, but from a database perspective,
the migration is a no-op.
[1] https://stackoverflow.com/a/12654998
As of Python 3.3, the 3rd-party `mock` package has been subsumed into the
standard `unittest.mock` package. Refactoring tests to use the latter will
allow us to drop `mock` as a dependency, which is currently coming in
transitively through requirements/edx/paver.in.
We don't actually drop the `mock` dependency in this PR. That will happen
naturally in:
* https://github.com/openedx/edx-platform/pull/34830
This switches the static asset check over from the deprecated
paver commands to the new 'npm run build' command. Doing so allows us
to check both the prod AND dev build, whereas before we were only
checking the prod build.
Please note that, as before, the "check" is only ensuring that the build
returns 0. It is not checking the contents of the build output.
Closes: https://github.com/openedx/edx-platform/issues/34834
removed unencrypted columns of user data credentials in blackboard config ENT 8010
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master`
This is an attempt to fix a performance problem on the libraries home page. When you go to studio home and click on the libraries tab, on prod it will be quick for admins but extremely slow for course instructors (> 12 seconds) and leads to timeouts. It grows with the number of libraries that are assigned to the instructor.
The Python code for the request to load libraries for a particular user goes through all existing libraries and then checks all of the user's roles for each library, which results in a complexity of O(l*r), l=libraries, r=roles. This PR improves the complexity to O(l).
The BulkRoleCache and RoleCache classes were using a python set to store all roles for a particular user. A user can have a large number of roles, and lookup speed of iterating through a set is slow (O(n)). Most roles don't have the same course id, however. So if you have the course id of the role you're looking for, we can use a dict of course ids that contain related roles. The number of roles per course id is negligible, so we arrive at a lookup speed of O(1) when looking up a user's roles that belong to a specific course id.
The BulkRoleCache now caches and stores user roles in a data structure like this:
{
user_id_1: {
course_id_1: {role1, role2, role3}, # Set of roles associated with course_id_1
course_id_2: {role4, role5, role6}, # Set of roles associated with course_id_2
[ROLE_CACHE_UNGROUPED_ROLES_KEY]: {role7, role8} # Set of roles not tied to any specific course or library. For example, Global Staff roles.
},
user_id_2: { ... } # Similar structure for another user
}
While this changes the data structure used to store roles under the hood and adds the new property `roles_by_course_id` to the RoleCache,
when initializing the RoleCache will store roles additionally in the previous data structure - as a flat set - in the `_roles` property accessible via `all_roles_set`. This establishes
backwards compatibility.
We are now storing roles twice in the RoleCache (in each of the two data structures), which means this takes twice as much memory, but only in the scope of a request.
Open edX implements its a JwtAuthentication class in edx-drf-extensions
(in edx_rest_framework_extensions.auth.jwt.authentication). This class
updates the local User database entry to match certain values in the
token. It's used as a way to automatically provision and update users
with their LMS user information on other Open edX services like
ecommerce.
Since LMS and Studio keep the record of truth in its database tables,
they should *not* update their database user information based on the
JWT. Doing so would allow stale JWTs to incorrectly reset user values
after they had been changed in the LMS. This is done by having the
EDX_DRF_EXTENSIONS['JWT_PAYLOAD_USER_ATTRIBUTE_MAPPING'] setting be an
empty dictionary, and was set correctly for the LMS in its common.py env
settings module. Unfortunately, this was *not* being set for Studio.
This commit adds the same setting to Studio's common settings module.
Prior to this commit, it was possible for a stale JWT to reset user
attributes if the user hit a Studio API endpoint that used JWT for auth
(e.g. endpoints used by the Course Authoring MFE). This opened up a
potential security issue where a global staff user (is_staff=True) that
had their global staff status removed (is_staff=False) could have up to
a one hour window in which they could use their stale-but-still-valid
global-staff JWT token to regain global staff status by calling a Studio
endpoint with their browser.
[APER-3241]
This PR updates the retirement pipeline to purge learners' names from certificate records when their account is being retired.
It also introduces a new management command that can be used by Open edX operators to purge the leftover name data (PII data) from the `certificates_generatedcertificate` table. This is designed as a one-time use data fixup, as the retirement functionality should clean this moving forward.
