feat: add a method for calling python APIs #580
Closed
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
Adding generic permission class. Added standard authentication classes.
created migration to create a system-wide enterprise role named `enterprise_provisioning_admin`. Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master`
…dx-enterprise-39dd3c0 feat: Upgrade Python dependency edx-enterprise
fix: serialize 'course_key' from the CourseDetails model by @brobro10000 in openedx#2185 Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master` Co-authored-by: brobro10000 <[email protected]>
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).
…e-country-database-0359d52 Update GeoLite Database
* fix: use versioning.last_publish_log for components * chore: bump openedx-learning to 0.10.1
although the demographics IDA has not been entirely deprecated as yet, it is about to be, so removing from the retirement pipeline.
…penedx#35189) * feat: added custom setting attribute for gradebook freeze timedelta
…nterprise-version-4.22.4 chore: bumping enteprise version to 4.22.4
* feat: upgrading simple api to drf compatible.
Update to latest version with updates to function trace functionality. Commit generated by workflow `openedx/edx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master` Co-authored-by: dianakhuang <[email protected]>
There are a few migrations going into this library which cause operational headaches for operators. We would like to pin until the migrations settle down and then we can unpin this again.
fix: updated unit tests fix: updated unit tests
* feat: upgrading simple api to drf compatible.
Xblock used to allow overrides of the built-in xblocks. The latest version introduced a regression.
…35247) This was failing to capture /c4x/ URLs when the `content_server.use_view` waffle flag was enabled, so we were returning 404s for those during our rollout test. Part of openedx#34702
Faraz32123
force-pushed
the
feat/migrate_from_http_to_python_call
branch
4 times, most recently
from
ea99719
to
8158027
Compare
regisb
requested changes
Sep 12, 2024
| @@ -204,3 +218,46 @@ def check_forum_heartbeat(): | |||
| return 'forum', False, res.get('check', 'Forum heartbeat failed') | |||
| except Exception as fail: | |||
| return 'forum', False, str(fail) | |||
|
|
|||
|
|
|||
| def check_service_enabled(): | |||
There was a problem hiding this comment.
What is this for? The fact that we have to repeatedly call check_service_enabled() is a red flag, and we should get rid of that function.
There was a problem hiding this comment.
I think we can remove this function/code as we have already added ENABLE_DISCUSSION_SERVICE=true in our forum_v2 plugin.
openedx/core/djangoapps/django_comment_common/comment_client/utils.py
Outdated
Show resolved
Hide resolved
Faraz32123
force-pushed
the
feat/migrate_from_http_to_python_call
branch
10 times, most recently
from
294da72
to
0a467f2
Compare
Faraz32123
force-pushed
the
feat/migrate_from_http_to_python_call
branch
2 times, most recently
from
f0d0389
to
9bbe4e9
Compare
* feat: Add Forum v2 request logging send request to forum v2 alongside v1 validate both responses and log info in case of diff * feat: modify comparison and formatting - compare json objects instead of response objects - format the added lines of code --------- Co-authored-by: Taimoor Ahmed <[email protected]> Co-authored-by: Muhammad Faraz Maqsood <[email protected]>
Updated settings to use Forum v2. All requests will be handled by Forum v2. The Forum v2 includes a proxy for redirecting all requests to the CS Commerce app that are not implemented within Forum v2. This ensures that any unhandled requests are appropriately forwarded, maintaining seamless integration with the CS Commerce application.
- add a method named `check_service_enabled` for checking if the forum service is enabled or not as it was being checked in v1 - call python methods instead of HTTPs APIs for getting response/data for pin, unpin thread, commentables count_stats and get user's data by user_id - add a method named `handle_response` for handling returned results from forum v2 methods as same as v1 responses were handled
Faraz32123
force-pushed
the
feat/migrate_from_http_to_python_call
branch
from
9bbe4e9
to
2ea9621
Compare
|
closing this PR in favor of this PR |
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.
check_service_enabledfor checking if the forum serviceis enabled or not as it was being checked in v1
for pin, unpin thread and get user's data by user_id
handle_responsefor handling returned results fromforum v2 methods as same as v1 responses were handled