test: DO NOT MERGE - Dummy PR to track upstream master#824
Draft
kaustavb12 wants to merge 136 commits intoopen-craft:kaustav/downstream_pr_targetfrom
Draft
test: DO NOT MERGE - Dummy PR to track upstream master#824kaustavb12 wants to merge 136 commits intoopen-craft:kaustav/downstream_pr_targetfrom
kaustavb12 wants to merge 136 commits intoopen-craft:kaustav/downstream_pr_targetfrom
Conversation
…regardless of nesting or randomization (#36677) This PR ensures that the instructor "Problem Responses" report in Open edX includes all student responses to all problems under any selected block, including those that are nested or randomized (such as those from legacy library_content blocks). Previously, the report could miss responses to problems that were not directly visible to the instructor or admin user generating the report, especially in courses using randomized content blocks or deep nesting. In courses that use randomized content (e.g., legacy library_content blocks) or have deeply nested structures, the instructor dashboard’s problem response report was incomplete. It only included responses to problems visible in the block tree for the user generating the report (typically the admin or instructor). As a result, responses to problems served randomly to students, or problems nested in containers, were omitted from the CSV export. This led to inaccurate reporting and made it difficult for instructors to audit all student answers.
…37991) We hope this will fix an error where loremipsum is using pkg_resources, which setuptools dropped support for as of v82 (released yesterday).
- Fixes the issues described in openedx/frontend-app-authoring#2762 (comment): - Changed the background color for the library icon in the unit page. - Update punctuation for the library icon tooltip in the unit page. - Allows breaking the tooltip into multiple lines.
- Returns top parent key instead of boolean in upstream info api - Adds edited_on raw time in course outline api - Adds has_changes to course details api
* chore: discussion service to enable permission and access provider
#38005) - Fix a simple typo in an unsupported reason message for blocks with children in content libraries
This commit introduces several improvements to database migration scripts to enhance compatibility between MySQL and PostgreSQL, ensure case-sensitive behavior where needed, and improve migration safety and correctness. The changes include dynamic SQL generation based on the database engine, improved transaction handling, and adjustments to field types and adapters for better cross-database support. Database compatibility and case sensitivity improvements: - Migration scripts in split_modulestore_django and learning_sequences now dynamically generate SQL statements for altering column case sensitivity and uniqueness based on whether the database is MySQL or PostgreSQL, ensuring correct behavior across both backends. - common/djangoapps/split_modulestore_django/migrations/0001_initial.py - openedx/core/djangoapps/content/learning_sequences/migrations/0001_initial.py - The courseware.fields module now checks for "postgresql" in the database engine string instead of a specific backend name, improving compatibility with different PostgreSQL drivers. - lms/djangoapps/courseware/fields.py - The 0011_csm_id_bigint migration in courseware now supports both MySQL and PostgreSQL for altering column types, with specific SQL for each backend. - lms/djangoapps/courseware/migrations/0011_csm_id_bigint.py - The 0009_readd_facebook_url migration in course_overviews now introspects the table structure using backend-specific SQL for MySQL and PostgreSQL, ensuring correct detection of existing fields. - openedx/core/djangoapps/content/course_overviews/migrations/0009_readd_facebook_url.py Migration safety and correctness: - Service user creation and deletion in the commerce app is now wrapped in atomic transactions to ensure database consistency. - lms/djangoapps/commerce/migrations/0001_data__add_ecommerce_service_user.py - The move_overrides_to_edx_when migration in courseware now specifies a no-op reverse migration, preventing accidental data loss on migration rollback. - lms/djangoapps/courseware/migrations/0008_move_idde_to_edx_when.py Adapter registration and code cleanup: - The common_initialization app now registers custom adapters for CourseLocator and related classes in psycopg2 when using PostgreSQL, ensuring proper serialization of these types. - openedx/core/djangoapps/common_initialization/apps.py - Minor code cleanup and formatting improvements in migration files, including import order and field formatting for readability. - lms/djangoapps/grades/migrations/0015_historicalpersistentsubsectiongradeoverride.py
Upgrades openedx-learning from 0.31.0 to 0.32.0, incorporating a major openedx-learning Python API restructuring: ca0b3eb
- Change the `i18n` service declaration from `wants` to `needs`, since the runtime must provide it for the block to function correctly. - Update the `public_view` webpack JS reference from `VideoBlockMain` to `VideoBlockDisplay`, as all VideoBlock JS files are bundled into `VideoBlockDisplay` and `VideoBlockMain` is not referring to anything or no longer exists in the repository.
- Styles to make component cards selectable. - Action to select a component and send a message to the parent of the iframe - Handler for a "deselect all" message and for selecting a specific component
build!: Switch to openedx-core (renamed from openedx-learning) Instead of installing openedx-learning==0.32.0, we install openedx-core==0.34.1. We update various class names, function names, docstrings, and comments to represent the rename: * We say "openedx-core" when referring to the whole repo or PyPI project * or occasionally "Open edX Core" if we want it to look nice in the docs. * We say "openedx_content" to refer to the Content API within openedx-core, which is actually the thing we have been calling "Learning Core" all along. * In snake-case code, it's `*_openedx_content_*`. * In camel-case code, it's `*OpenedXContent*` For consistency's sake we avoid anything else like oex_core, OeXCore, OpenEdXCore, OexContent, openedx-content, OpenEdxContent, etc. There should be no more references to learning_core, learning-core, Learning Core, Learning-Core, LC, openedx-learning, openedx_learning, etc. BREAKING CHANGE: for openedx-learning/openedx-core developers: You may need to uninstall openedx-learning and re-install openedx-core from your venv. If running tutor, you may need to un-mount openedx-learning, rename the directory to openedx-core, re-mount it, and re-build. The code APIs themselves are fully backwards-compatible. Part of: openedx/openedx-core#470
…lemBlock (#37998) * fix: move xqueue services
Update our calls to the openedx_content API to reflect 0.35.0's shift in terminology from "contents" to "media". --------- Co-authored-by: Kyle McCormick <kyle@axim.org>
fix: don't update business logic fix: comparison condition fix: linting errors fix: linting error test: progress api test test: add not-null scenario fix: linting errors test: fix assertion refactor: tests
…-update fix: calculate last_grade_publish_date for all unreleased subsections
Commit generated by workflow `openedx/openedx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master` Co-authored-by: navinkarkera <10894099+navinkarkera@users.noreply.github.com>
…length (#38044) refactor: remove some 'max_length=255' to be more DRY feat: example of making an OpaqueKeyField case_sensitive (modulestore_migrator) test: update test now that we're using case-insensitive collation on SQLite
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
setuptools 82+ removed pkg_resources, which pyfilesystem2 (fs) still uses for namespace package declarations. The constraints.txt pin handles this for full installs, but the static-assets-check workflow only installs requirements/edx/assets.txt. Pre-installing pip-tools.txt ensures setuptools 81.x is in place before the assets install runs. See: PyFilesystem/pyfilesystem2#577 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
And add back and comment the old 3.11 tests for when we drop future major dependencies.
6.7.0 | invite new enterprise admins email Commit generated by workflow `openedx/openedx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master`
- Add decorator to enforce AuthZ course permissions - Add ADR documenting the new Authz Django app
Commit generated by workflow `openedx/openedx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master` Co-authored-by: salman2013 <4454296+salman2013@users.noreply.github.com>
Co-authored-by: Kiro <noreply@kiro.dev>
fix: backward compat for transmit learner data task Commit generated by workflow `openedx/openedx-platform/.github/workflows/upgrade-one-python-dependency.yml@refs/heads/master`
XModuleMixin and CourseOverview both provided some backcompat names for some XBlock key attributes. Due to refactors that have happened in edx-platform and improvements to the XBlock API that have happened over the years, we can now simplify these backcompat mappings. The new mappings (old -> new) are: * .course_id -> .context_key * .location -> .usage_key * .url_name -> .usage_key.block_id * .category -> .usage_key.block_type These are the ways we would like developers to access these attributes going forward, so it's important that we set the example in XModuleMixin and CourseOverview. Note: It is technically correct to go through `.scope_ids` for these fields, but it's harder to read. Under the hood, the XBlock API indeed uses `.scope_ids`: https://github.com/openedx/XBlock/blob/v5.3.0/xblock/core.py#L422-L446 Part of: openedx/xblocks-contrib#125
* chore: test enable PR for extracted discussion block
* fix: discussion tab visibility on import * fix: quality issues * refactor: move the logic to update_discussions_settings_from_course in task * test: add test * fix: remove old code * fix: issue * chore: update openedx-events version
* chore: team discussion template error fix
- Remove ('enterprise', None) and ('consent', None) from OPTIONAL_APPS in
openedx/envs/common.py. Now that edx-enterprise registers enterprise and
consent as openedx LMS plugins via entry_points, get_plugin_apps() adds
them to INSTALLED_APPS automatically. Keeping them in OPTIONAL_APPS would
cause duplicate app label errors.
- Update enterprise_enabled() in enterprise_support/api.py to use
django_apps.is_installed('enterprise') instead of the raw string check
'enterprise' in settings.INSTALLED_APPS. The new plugin entry_point-based
registration uses 'enterprise.apps.EnterpriseConfig' (not 'enterprise') in
INSTALLED_APPS, so the raw string check no longer works.
ENT-11663
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…uctor dashboard v2 API (#38018)
feat: remove enterprise and consent from OPTIONAL_APPS
This file contains hidden or 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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
20 participants
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.
Settings