Several of our cookies are meant to be shared between the LMS
and the marketing site. The previous assumption was that
SESSION_COOKIE_DOMAIN would cover both. We would like to make
it so that these can be set independently of each other.
https://openedx.atlassian.net/browse/ARCHBOM-1831
common.py has queue names that always get overridden by production.py
and lead to confusion. Set a default SERVICE_VANIANT in common.py and
then set the queue names based on that in common.py so that
production.py doesn't make it more complicated.
This should prevent the issue where if you copy a queue name in
common.py it ends up being incorrect in the production system. This is
what happened with the sample_task change.
https://github.com/edx/edx-platform/pull/23731 made it so that the queue
name for that queue is independently configurable but the default was
set to the value of HIGH_PRIORITY_QUEUE in common.py which is not the
same as the value set in production.py leading to stale tasks that never
get picked up in production.
BREAKING_CHANGE: If anyone was building a different settings file on top
of common, the default names in common.py are now change to be service
variant specific. eg 'edx.cms.core.high' instead of 'edx.core.high'
In order to allow the learning MFE's progress tab to show a
different UX for FBE exceptions (where some exams can still be
completed by audit learners), this commit adds access information
to each exam.
AA-829
Code in ./common/lib/xmodule/xmodule should
be imported as `from xmodule`, since `xmodule`
is a locally-installed package.
This is weird, but as long as it is the case,
we should be consistent.
(In BOM-2584, I propose moving the files to
./xmodule, which would quell this confusion.)
MST-846. We no longer want proctored exam content to be viewable past the exam's due date. This behavior is now controlled by a django setting, so other instances of open edX can choose to turn it on/off.
The get_course_members API returns a dict of users associated with a course.
This is a potentially expensive operation on a large course, so there is a
control in place to limit its cost. If a course has more than
settings.COURSE_MEMBER_API_ENROLLMENT_LIMIT enrollments, then the function
raises an OverEnrollmentLimitException.
This API was added to help implement the LTI 1.3 Names and Roles Provisioning
service.
Jira references: [BD-24] [BB-2726] [TNL-7330]
Pull request: #25843
Co-authored-by: Giovanni Cimolin da Silva <giovannicimolin@gmail.com>
* Badgr integration fix
Badges are no longer created on the Badgr side with a given
'slug'. Instead, a slug(v1) or an entityId(v2) will be generated
for each badge on the Badgr side and we will need to use that
value to check if a certain badge matching a BadgeClass on our side
exists and/or to create assertions for it.
This commit introduces a new field to the badgeclass:
'badgr_server_slug' by cherry-picking the following commit from
3309aab2a2eb00d28c5ca3d3145c8dddb15e6159
- TTK-18543: fix Badgr Server
connection (https://github.com/teltek/edx-platform/pull/46)
This commit also modifies the cherry-picked commit by making the newly
added field optional since the BadgeClass is not neccessarily always used
with the Badgr backend.
Co-authored-by: mrey <mrey@teltek.es>
* Implement OAuth2 tokens flow for BadgrBackend
* Use Badgr v2 API
Co-authored-by: mrey <mrey@teltek.es>
The user_tasks app is only needed by a cms feature.
However, it has been listed under INSTALLED_APPS
for both cms and lms because app-permissions only ran
in an lms context until recently.
Since app-permissions now creates the user_tasks_admin
group in a cms context, the app can be safely removed
from lms's INSTALLED_APPS.
TNL-8274
This djangoapp was designed for talking to sailthru, in a fairly
edx.org-specific way. Nowadays, edx.org doesn't need this code and
if other installations do, it's better off as a more distinct
plugin anyway, rather than direct support in the platform.
I've moved the one signal that was still useful (calling
segment.identify() whenever user fields change) into user_authn.
And I've left the EmailMarketingConfiguration model alone for now,
but will remove that shortly. Nothing uses it as of this commit.
AA-607
DEPR-139
* Enable import failure and email with Errors/Warnings
This PR enables course import failure in case of olx validation errors. Here is the flow.
* Course Import tries to import foo.tar.gz into their course shell
* Course olx contains validation errors
* During course import, olx is validated and import is failed with the error message "Course olx validation failed. Please check your email."
* System generates an email with ERRORs & WARNINGs in the body of the email.
This PR also adds a waffle flag contentstore.bypass_olx_failure. The purpose of this test flag is to allow course teams to unblock by enabling them to bypass the
the olx-validation failure.
The workaround is shared on the ticket TNL8214.
* Disable olx validation out of the box.
Attempting to import packages from
lms/djangoapps, cms/djangoapps, or common/djangoapps
as if they are import roots will now
simply raise ImportErrors (like any other invalid
import) instead of DeprecatedEdxPlatformImportError.
See docs/decisions/0007-sys-path-modification-removal.rst
for more details.
* Use config settings for olxcleaner
Use config settings instead of hardcoded values for olx validation. This would help in adding a great deal of control when you want to change these settings in the future. With this approch we would not need a redeploy.
* Use configs and deprecate waffleflag and also add / update tests
We have decided not to pursue the decentralized devstack design right
now and so we want to cleanup files and task that were built as a part
of the process.
Related Ticket: ARCHBOM-1685
Currently, login and registration forms and view to log the user in
are sharing same ratelimit settings which is causing too much noise
while rendering forms.This PR will introduce a separate
setting for logistration forms.
VAN-436
This adds a new django app to allow the GDPR user retirement via
Open edX's REST API. Prior to this the only way to trigger the user
retirement was either by the user themself clicking "Delete my account"
in the account setting page or via creating a User Retirement request
by admin. With these changes, the user retirement process can be
triggered using REST API.
This:
1. Introduces a new override using the `pluggable_override` decorator.
It is now possible to specify a custom way of getting XBlock's icon
by defining `GET_UNIT_ICON_IMPL` in settings.
2. Introduces a way to add custom `XBLOCK_MIXINS` by defining
`XBLOCK_EXTRA_MIXINS` in settings. This allows, e.g. to add
new fields to XBlocks.
A variety of updates were made to improve the toggle documentation:
* Added comments to help ensure that the waffle(), waffle_switches(),
waffle_flags() anti-pattern won't be contagious (copied).
* Some minor toggle_description updates.
* Removed empty toggle_target_removal_date annotations for
non-temporary toggles.
* Removed empty optional toggle_warnings annotations.
* Removed empty optional toggle_tickets annotations.
* Removed deprecated toggle_category, toggle_status,
and toggle_expiration_date annotations.
* Fixed some indents, use cases, and implementations.
ARCHBOM-1721
