Fixes errors thrown when previewing/editing (built-in) LTI blocks in a Libraries v2 context.
These fixes allow Library Authors to store LTI blocks in their content libraries.
- Removed unnecessary blank lines in the add-remove-label-on-comment.yml and check_python_dependencies.yml files to improve readability and maintainability.
- Introduced `remove_special_characters_from_name` and `generate_username_suggestions` functions to enhance username handling.
- Added comprehensive test cases for username generation, including ASCII validation and uniqueness checks.
- Implemented tests for special character removal and suggestion generation based on various input scenarios, including edge cases.
- Updated `generate_username_suggestions` function to include validation for non-ASCII characters.
- Improved function documentation to clarify arguments, return types, and username generation logic.
- Added type hints for better code clarity and maintainability.
Adds a new field `user_fk` to EnterpriseCustomerUser table. Part 1 of multiple releases to add a user foreign key.
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master`
This is a pure refactoring of cms/envs/production.py, removing several
redundant statements that have accrued over the years as the platform moved
from python-only, to python+json, to python+json+yaml, to today's python+yaml
setup.
This is the CMS version of:
* a81493ce7f
* (originally 15939232d5)
Also included:
* Add some more explicit structure to the both LMS's and CMS's
production.py using big comments.
* In both LMS and CMS settings, alphabetize the production overrides,
and remove the extraneous comments. Separate out the handful of settings
which have useful comments. The rest of the settings' comments were not
helpful--they were either just stating the obvious, or they were duplicative
of what's documented in common.py.
Co-Authored-By: Feanil Patel <feanil@axim.org>
Part of: https://github.com/openedx/edx-platform/issues/36215
This file is very out of date so just buliding it from scratch to get
the latest versions of 2nd order dependencies that are still compatible
with our explicit dependencies.
Exposes Waffle-based feature flag for migrating to CatalogQuery-based Algolia filtering on frontends.
Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master`
Co-authored-by: adamstankiewicz <2828721+adamstankiewicz@users.noreply.github.com>
The get_service_user method used to do a local call to the
get_user_model function because it was not guaranteed to be properly
initialized at the time of import. This was partly due to how we did
custom initialization using lms/startup.py, but it was also because
when it was implemented (commit f318661), the platform was still
running on Django 1.8.18. At that time, get_user_model was guaranteed to
work only after Django has imported all models.
In Django 1.11, the behavior of get_user_model was changed:
https://docs.djangoproject.com/en/1.11/releases/1.11/#django-contrib-auth
> get_user_model() can now be called at import time,
> even in modules that define models.
Now that lms/startup.py is gone and get_user_model is safe to call at
the module level, I'm refactoring the catalog app's models.py file to
follow the convention we use everywhere else in edx-platform with
respect to get_user_model.
The cms/startup.py and lms/startup.py files were created to
allow us to do a lot of custom initialization around things
like the ModuleStore, monkey-patching, adding MIME types to
our process, etc. As far back as 2017, we recognized that
this was a bad thing, marked these modules as "deprecated",
and started removing things or putting them in the standard
Django locations for them (0279181).
In its current state, these startup modules no longer do any
custom work, and just invoke django.startup(). But this is
meant for running Django code in "standalone" usage, e.g. if
you have a script that isn't a management command but needs
some Django functionality.
The "runserver" command used during development normally
launches a child process to serve requests and knows how to
kill and respawn that process when files are modified, so
that changes are reflected. It can also normally handle the
case where there's a SyntaxError in the child process, and
fixing that error will reload the code again.
Something about running django.startup() manually interferes
with this functionality in "runserver". It still reloads the
code in response to changes, but if the code gets into a
broken state for any reason (like a syntax error), the master
process itself dies. That causes the container to restart,
only to die again shortly afterwards in a loop until the
error is fixed. The container restarts will break any shell
you had opened into the container, as well as any IDE
integrations that connected to that container to access the
files and Python instance.
Getting rid of the custom startup code fixes this and moves
us one small step closer to being a more normal Django
project.
