This repo is no longer using USE-JWT-COOKIE header,
since it has the required edx-drf-extensions>10.2.0,
where it was fully removed.
This is final clean-up for this repo.
See "[DEPR]: USE-JWT-COOKIE header" for more details:
- https://github.com/openedx/edx-drf-extensions/issues/371
This commits adds a VerificationAttempt model to store implementation and provider agnostic information about identity verification attempts in the platform.
* feat: save author pronoun separately for notification to prevent info loss
* fix: missing pronoun in comment on followed post
* test: updated tests for new comment notifications
We sometimes see rendering errors in the error page itself, which then
cause another attempt at rendering the error page. I'm not sure _exactly_
how the loop is occurring, but it looks something like this:
1. An error is raised in a view or middleware and is not caught by
application code
2. Django catches the error and calls the registered uncaught error
handler
3. Our handler tries to render an error page
4. The rendering code raises an error
5. GOTO 2 (until some sort of server limit is reached)
By catching all errors raised during error-page render and substituting in
a hardcoded string, we can reduce server resources, avoid logging massive
sequences of recursive stack traces, and still give the user *some*
indication that yes, there was a problem.
This should help address https://github.com/openedx/edx-platform/issues/35151
At least one of these rendering errors is known to be due to a translation
error. There's a separate issue for restoring translation quality so that
we avoid those issues in the future (https://github.com/openedx/openedx-translations/issues/549)
but in general we should catch all rendering errors, including unknown
ones.
Testing:
- In `lms/envs/devstack.py` change `DEBUG` to `False` to ensure that the
usual error page is displayed (rather than the debug error page).
- Add line `1/0` to the top of the `student_dashboard` function in
`common/djangoapps/student/views/dashboard.py` to make that view error.
- In `lms/templates/static_templates/server-error.html` replace
`static.get_platform_name()` with `None * 7` to make the error template
itself produce an error.
- Visit <http://localhost:18000/dashboard>.
Without the fix, the response takes 10 seconds and produces a 6 MB, 85k
line set of stack traces and the page displays "A server error occurred.
Please contact the administrator."
With the fix, the response takes less than a second and produces three
stack traces (one of which contains the error page's rendering error).
* feat: removing visible_date-to-creds updates per-cert
The credentials IDA now relies on the course certificate configuration
and (if present) `certificate_available_date` for displayability. We no
longer need to send `visible_date` updates for every awarded certificate
when a course overview changes.
[APER-2823]
Removes React compoents and functionality tied to a private 2U/edx.org-specific Demographics IDA from edx-platform.
This PR attempts to remove everything added from this PR: https://github.com/openedx/edx-platform/pull/24956/. This includes the React components created to collect and transmit Demographics data, as well as functionality for managing JWT and CSRF tokens copied from `frontend-platform` to edx-platform when originally implementing the CTA and modal components.
* feat: linting before touching all these files
All these files are old enough, relative either to our current linting
rules or our current linter automation, that modifying anything in them
either makes the linter cranky or wants to reformat the entire file.
Rather than mixing cleanup with code changes, this commit just lints
this set of files to our current standards.
The LMS `certificates` app `README` has been, and the
openedx core `credentials` and `programs` READMEs have been created.
This will clarify not only what the limited responsibilities
of each of these django apps is, but also the way they interact with
each other.
FIXES: APER-2929
Deleted according to flaky test process:
https://2u-internal.atlassian.net/wiki/spaces/TE/pages/12812492/Flaky+Test+Process
Flaky test ticket: https://2u-internal.atlassian.net/browse/CR-6899
Failed multiple times with this error, but not consistently:
```
FAILED lms/djangoapps/commerce/tests/__init__.py::DeprecatedRestApiClientTest::test_tracking_context - requests.exceptions.ConnectionError: HTTPSConnectionPool(host='ecommerce.example.com', port=443): Max retries exceeded with url: /api/v2/baskets/1/ (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f0708b91f50>: Failed to establish a new connection: [Errno -2] Name or service not known'))
```
Note that there is another test class with a name differing by only one
letter earlier in this file, `DeprecatedRestApiClientTests` (plural), with
a method with the same name. That one hasn't been failing.
