This minimizes our footprint outside of the djangoapp, now and moving
forward. Not only can we drop the `lms/envs/common.py` change, but we
can also avoid touching `lms/urls.py` when we add the API. Everything
can stay contained within `openedx/core/djangoapps/discussions`.
This commit removes several waffle toggles that have been enabled
on edx.org for years. It's time to remove the rollout gating for
these features and enable them by default.
This doesn't directly change any behavior. But it does create new
database objects by default now and allows for enabling other
schedule based features more easily.
Specifically, the following toggles were affected.
schedules.create_schedules_for_course
- Waffle flag removed as always-enabled
- We now always create a schedule when an enrollment is created
schedules.send_updates_for_course
- Waffle flag removed as always-enabled
- Course update emails are sent as long as the ScheduleConfig
allows it.
- This is not a change in default behavior, because ScheduleConfig
is off by default.
dynamic_pacing.studio_course_update
- Waffle switch removed as always-enabled
- Course teams can now always edit course updates directly in Studio
ScheduleConfig.create_schedules
ScheduleConfig.hold_back_ratio
- Model fields for rolling out the schedules feature
- Schedules are now always created
- This commit only removes references to these fields, they still
exist in the database. A future commit will remove them entirely
This commit also adds a new has_highlights field to CourseOverview.
This is used to cache whether a course has highlights, used to
decide which course update email behavior they get. Previously every
enrollment had to dig into the modulestore to determine that.
* Remove authentication, including SessionAuthentication, to fix CSRF
exemption by dropping CSRF check of SessionAuthentication.
* Several changes to make it more clear that only POST is supported and
clean up GET method testing.
* Removed the temporary 403 error logging that wasn't working.
* Removed test_single_access_token which was written for DOP, but
doesn't work with DOT. See
[MA-2122](https://openedx.atlassian.net/browse/MA-2122) for a ticket
about implementing this for DOT, although it doesn't seem to be a
priority. NOTE: A comment was added to the ticket explaining that this
test was removed.
* GET now returns default error for methods not allowed.
ARCHBOM-1667
This feature uses the first_day_of_streak, last_day_of_streak and last_streak_celebration fields to determine whether the user should see a celebration.
AA-304
This reverts commit 0517603b6d.
This was masking a LabXchange error by blowing up with:
"Stack trace builtins:AttributeError: 'NoneType' object has no attribute 'status_code'"
Fixing tests which were failing on running alone.
Main root cause was the mongodb client connection error.
On running all tests this mongodb connection establishes by some other test.
The mobile app is getting unexpected 403s from
/oauth2/exchange_access_token/, but we have been unable
to pinpoint from where they are coming. This commit
introduces a temporary exception handler to provide stack info
for 403s on this endpoint to try to track down the source.
Requires the ENABLE_403_MONITORING setting to be set to
True to enable the logging.
ARCHBOM-1667
We use django-ratelimit to limit per IP login attempts, and then we use
django-ratelimit-backend to limit per username login attempts. This
change replaces the usage of django-ratelimit-backend with another
instance of django-ratelimit so that both limits can be managed by one
library.
This is the first step in being able to fully excise
django-ratelimit-backend from edx-platform. Note that we're still using
the `RateLimitMixin` in openedx/core/djangoapps/oauth_dispatch/dot_overrides/backends.py
because studio and the admin UI still relies on that for rate limiting.
Those login paths will have to be updated before we can remove the mixin
from our auth backend.
Instead of optionally not logging usernames and emails, do so by
default. This mostly removes some complexity from the app and is makes
it so that it's more secure by default.
I considered the question of allowing people to log usernames and
e-mails if they wanted to but opted not to for a couple of reasons:
* It would involve adding a new feature flag that would be the opposite
of the SQUELCH_PII_IN_LOGS which would be a bit confusing. When do you
use which one? or do you need both? etc.
* There is still a way to correlate the messages to eachother and in
most cases also to a specific user(email being the exception).
