Prevents notification failures with MySQL backend by ensuring signals
are only sent after database transactions commit. This fixes race
conditions where Celery workers couldn't see newly created threads.
- Added send_signal_after_commit() helper function
- Updated both thread creation paths to use the helper
Co-authored-by: Taimoor Ahmed <taimoor.ahmed@A006-01711.local>
BREAKING CHANGE: All references to the hardcoded 'proctortrack' string have
been removed from the codebase, as well as the `studio.show_review_rules`
waffle flag. These were used to determine whether an escalation email is
required and whether review rules should be shown. These decisions are now made
based on the value of 'requires_escalation_email' (default False) and 'show_review_rules'
(default True) config items in the PROCTORING_BACKENDS entry.
Additionally:
* The proctoring info api will now return the list of providers which require an escalation
email so that frontend-app-learning does not need to use a hardcoded check agaist
the provider name 'proctortrack'.
* Removed translation commands, mock variables and user facing strings that contained
'proctortrack'.
* Updated all test cases that were using proctortrack to use fake providers names.
Part of: https://github.com/openedx/edx-platform/issues/36329
Without this the devstack settings don't correctly proxy the features
updates made to get devstack working.
Co-authored-by: Kyle McCormick <kyle@axim.org>
After applying a "download" property on html5 anchor tag, Download Handout
link in a video component initiates a direct download instead of overlaying
over the video.
Fixed issue: https://github.com/openedx/edx-platform/issues/37081
This commit fixes the incorrect saving of the user's full name in the
credentials service by modifying how the COURSE_PASSING_STATUS_UPDATED
and CCX_COURSE_PASSING_STATUS_UPDATED events are emitted.
Previously, we had been using Django's standard User.get_full_name()
to fetch the user's full name. However, Open edX uses the convention of
storing the full name in user.profile.name and leaves the User's first
and last name fields blank. (This is to better accommodate the wide
range of international conventions regarding names.)
As part of the ongoing effort to deprecate and eventually remove xmodule,
we’ve started gradually migrating the necessary code files from xmodule
to more appropriate locations within the codebase.
Ticket: https://github.com/openedx/public-engineering/issues/445
Also: this tweaks importlinter ignores & add follow-up issue links
Co-authored-by: Kyle McCormick <kyle@axim.org>
This setting was not actually not changing installation behavior, that
is being set by whether oauth_dispatch is in INSTALLED_APPS or not.
This flag was being used to:
* Hide enable/disable certain URL paths.
* We need these paths on all the time in the LMS because all other
services and MFE rely on oauth to authenticate with the LMS so we
just end up turning this on later in the settings stack.
* We use it to only run certain oauth_dispatch tests in the LMS test
environment because the oauth_dispatch app is not installed in the
CMS.
* We use the `skip_unless_lms` decorator now instead to do this or
just run the tests in both suites because they are valid tests in
both contexts.
* chore: remove branding related code from video_block class as it is stop being used, we have plan to remove the specialized VIDEO_CDN_URL in the next phase as after removing URL nothing will reference the branding code so we're removing it first.
The Course Info Blocks API endpoint has been known to be rather slow
to return the response. Previous investigation showed that the major
time sink was the get_course_blocks function, which is called three
times in a single request. This commit aims to improve the response
times by reducing the number of times that this function is called.
Solution Summary
The first time the function get_course_blocks is called, the result
(transformed course blocks) is stored in the current WSGI request
object. Later in the same request, before the second get_course_blocks
call is triggered, the already transformed course blocks are taken
from the request object, and if they are available, get_course_blocks
is not called (if not, it is called as a fallback). Later in the
request, the function is called again as before (see Optimization
Strategy and Difficulties).
Optimization Strategy and Difficulties
The original idea was to fetch and transform the course blocks once
and reuse them in all three cases, which would reduce get_course_blocks
call count to 1. However, this did not turn out to be a viable solution
because of the arguments passed to get_course_blocks. Notably, the
allow_start_dates_in_future boolean flag affects the behavior of
StartDateTransformer, which is a filtering transformer modifying the
block structure returned.
The first two times allow_start_dates_in_future is False, the third
time it is True. Setting it to True in all three cases would mean that
some blocks would be incorrectly included in the response.
This left us with one option - optimize the first two calls. The
difference between the first two calls is the non-filtering
transformers, however the second call applies a subset of transformers
from the first call, so it was safe to apply the superset of
transformers in both cases. This allowed to reduce the number of
function calls to 2. However, the cached structure may be further
mutated by filters downstream, which means we need to cache a copy of
the course structure (not the structure itself). The copy method itself
is quite heavy (it calls deepcopy three times), making the benefits of
this solution much less tangible. In fact, another potential
optimization that was considered was to reuse the collected block
structure (pre-transformation), but since calling copy on a collected
structure proved to be more time-consuming than calling get_collected,
this change was discarded, considering that the goal is to improve
performance.
Revised Solution
To achieve a more tangible performance improvement, it was decided to
modify the previous strategy as follows:
* Pass a for_blocks_view parameter to the get_blocks function to make
sure the new caching logic only affects the blocks view.
* Collect and cache course blocks with future dates included.
* Include start key in requested fields.
* Reuse the cached blocks in the third call, which is in
get_course_assignments
* Before returning the response, filter out any blocks with a future
start date, and also remove the start key if it was not in requested
fields
* style: Drop unused imports.
I was looking at these files for some other reason and saw that these
imports were unused. Some of it looks like an artifact of the hoisting
of some settings up to the `openedx/env/common.py` file and others look
like some ancient unused imports.
Co-authored-by: Kyle McCormick <kyle@axim.org>
* Consolidates and renames the runtime used as a base for all the others:
* Before: `xmodule.x_module:DescriptorSystem` and
`xmodule.mako_block:MakoDescriptorSystem`.
* After: `xmodule.x_module:ModuleStoreRuntime`.
* Co-locates and renames the runtimes for importing course OLX:
* Before: `xmodule.x_module:XMLParsingSystem` and
`xmodule.modulestore.xml:ImportSystem`.
* After: `xmodule.modulestore.xml:XMLParsingModuleStoreRuntime` and
`xmodule.modulestore.xml:XMLImportingModuleStoreRuntime`.
* Note: I would have liked to consolidate these, but it would have
involved nontrivial test refactoring.
* Renames the stub Old Mongo runtime:
* Before: `xmodule.modulestore.mongo.base:CachingDescriptorSystem`.
* After: `xmodule.modulestore.mongo.base:OldModuleStoreRuntime`.
* Renames the Split Mongo runtime, the which is what runs courses in LMS and CMS:
* Before: `xmodule.modulestore.split_mongo.caching_descriptor_system:CachingDescriptorSystem`.
* After: `xmodule.modulestore.split_mongo.runtime:SplitModuleStoreRuntime`.
* Renames some of the dummy runtimes used only in unit tests.
This introduces the `ENFORCE_MASQUERADE_START_DATES` flag.
When the flag is disabled (default), masquerading users bypass start dates.
When the flag is enabled, masquerading users see the same start date
restrictions as regular students.
This commit removes all remaining references to cs_comments_service
except the ForumsConfig model. The only purpose of keeping the model
and table around is so that the webapp processes don't start throwing
errors during deployment because they're running the old code for a
few minutes after the database migration has run. We can drop
ForumsConfig and add the drop-table migration after Ulmo is cut.
Also bumps the openedx-forum version to 0.3.7
---------
Co-authored-by: Taimoor Ahmed <taimoor.ahmed@A006-01711.local>
This commit migrates the data calculation logic for the GradeSummary
table, which was previously in the frontend-app-learning.
This commit also introduces a new visibility option for assignment
scores: “Never show individual assessment results, but show overall
assessment results after the due date.”
With this option, learners cannot see question-level correctness or
scores at any time. However, once the due date has passed, they can
view their overall score in the total grades section on the Progress
page.
These two changes are coupled with each other because it compromises
the integrity of this data to do the score hiding logic on the front
end.
The corresponding frontend PR is: openedx/frontend-app-learning#1797
If ENABLE_MKTG_SITE is True, MKTG_URLS['ROOT'] must be set. However if
it is set to the same value as the LMS_ROOT_URL (which points to this
view), you can end up in an infinite redirect loop. If the two URLs do
match, don't redirect, just fall through to the content that this page
would have responded with instead.
The behavior of the MariaDB backend has changed behavior for UUIDField
from a `CharField(32)` to an actual `uuid` type. This is not converted
automatically, which results in all writes to the affected columns to
error with a message about the data being too long. This is because the
actual tring being written is a UUID with the `-` included, resulting in
a 36 character value which can't be inserted into a 32 character column.
The announcements editor was never ported to frontend-app-authoring, and
the announcements display was never ported to frontend-app-learner-dashboard.
This announcements feature is rarely used, undocumented, non-a11y-friendly, and
there were no volunteers to port it to the new frontends. It is the last
remaining part of the legacy Studio "Maintenance" dashboard. So, we are
removing it.
BREAKING CHANGE: This removes...
* Studio Maintenance dashboard legacy frontend
* Studio Edit Announcements legacy frontend
* The snippet of legacy learner dashboard which renders announcements
* openedx/features/announcements djangoapp
* The ENABLE_ANNOUNCEMENTS feature flag
Not removed:
* The announcements_announcement table from openedx/features/announcements .
The table is most likely very small, as it is only populated by administrators. Removing
it would be more labor for us and more risk of toil for operators than is worthwhile.
Closes: https://github.com/openedx/edx-platform/issues/36263
This removes the last remaining code that called out to the
cs_comments_service. All forums backend logic now uses the v2 API from
the forum repo (https://github.com/openedx/forum). This does NOT remove
MongoDB support.
This also implements the endpoint to retrieve all comments for a user
using the new forum backend. This is not actually called from any known
frontend code, but it has not been formally deprecated as an endpoint,
and therefore needs to be supported.
As part of the cleanup, the ENABLE_FORUM_V2 course waffle flag has also
been removed, along with all remaining switching logic that used to
route between the Python API in the forum repo and service calls to the
cs_comments_service Ruby service.
Other endpoints affected (switching logic removed):
* get course commentable counts
* get/update course user stats
* update comment/thread/user
* delete thread (implementation moved to forum repo)
* follow
* retire user
This is part of the following overall DEPR ticket:
https://github.com/openedx/cs_comments_service/issues/437
By adjusting social media sharing settings(specifically linkedin) certificate parameters are autopopulated to LinkedIn API. Additional setting parameters(such as CERTIFICATE_LINKEDIN_DEFAULTS_TO_COURSE_ORGANIZATION_NAME) are introduced to override existing(platform level parameter for organization name) parameters for an operator to configure course level organization name. This will enable learners to share certificate in to LinkedIn with an option for course associated organization to be autopopulated.
