Sync opencraft-release/redwood.1 with Upstream 20241014-1728865275 #696
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…smiss button (openedx#34914) This hides the survey report banner from the Django Admin for a particular user for one month after they click on the "dismiss" button. This is done completely on the client side using localStorage, so the same user could see the banner again if they're logging in with a different browser.
chore: update Django to 4.2.14 for Redwood - Security Patch
…social_auth Feanil/backport django social auth
Feanil/backporting
…) to redwood (openedx#35248) * fix: disable submit button for archived courses (openedx#34920)
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 openedx#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 (openedx/openedx-translations#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).
…page-render-recurse [Backport] fix: Prevent error page recursion (openedx#35209)
* feat: course about page markup and styles improvements * test: update tests according to changes * fix: relocate course organization and return removed prerequisites info * fix: display org info above the course title --------- Co-authored-by: oleksandr.buhaienko <[email protected]> Co-authored-by: Eugene Dyudyunov <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Syncing opencraft-release/redwood.1 with Upstream
Important❗
Please always use the "Create a merge commit" option as it avoids issues when checking diffs with upstream.
Note on Conflicts⚠️
In cases of conflicts you can go ahead and resolve it here on Github if it is simple enough. However if it is a more complicated conflict please follow the steps below:
sync-open-release/redwood.master-20241014-1728865275locally:opencraft-release/redwood.1into that branch, make sure your[REMOTE]is pointing toopencraft-release/redwood.1:sync-open-release/redwood.master-20241014-1728865275to update this PRNote: Please use the "Create a merge commit" option as it avoids issues when checking diffs with upstream.