Fix Container Blocks in the New Unit Editor#38636
Conversation
openedx-webhooks
added
open-source-contribution
|
Thanks for the pull request, @salman2013! This repository is currently maintained by Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review. 🔘 Get product approvalIf you haven't already, check this list to see if your contribution needs to go through the product review process.
🔘 Provide contextTo help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:
🔘 Get a green buildIf one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green. 🔘 Update the status of your PRYour PR is currently marked as a draft. After completing the steps above, update its status by clicking "Ready for Review", or removing "WIP" from the title, as appropriate. Where can I find more information?If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources: When can I expect my changes to be merged?Our goal is to get community contributions seen and reviewed as efficiently as possible. However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
|
Thanks for the pull request, @salman2013! This repository is currently maintained by Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review. 🔘 Get product approvalIf you haven't already, check this list to see if your contribution needs to go through the product review process.
🔘 Provide contextTo help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:
🔘 Get a green buildIf one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green. 🔘 Update the status of your PRYour PR is currently marked as a draft. After completing the steps above, update its status by clicking "Ready for Review", or removing "WIP" from the title, as appropriate. Where can I find more information?If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources: When can I expect my changes to be merged?Our goal is to get community contributions seen and reviewed as efficiently as possible. However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
| Return a single context manager that makes the vertical appear to be a | ||
| StudioContainerWithNestedXBlocksMixin instance for the duration of the test, | ||
| returning the given NestedXBlockSpec list from get_nested_blocks_spec(). | ||
|
|
||
| Replaces StudioContainerWithNestedXBlocksMixin in the utils module with | ||
| type(self.vertical) so that isinstance(xblock, <that class>) is True for | ||
| any VerticalBlock instance, then patches get_nested_blocks_spec to return | ||
| the caller-supplied specs. |
There was a problem hiding this comment.
This is a very detailed technical explanation of what this code is doing, but it doesn't explain why we're doing that. If we're using such a complicated patch, we need a compelling justification and a very clear explanation of why, please.
If you just need an XBlock with StudioContainerWithNestedXBlocksMixin, why don't you use a special-purpose testing XBlock that actually subclasses StudioContainerWithNestedXBlocksMixin, using @XBlock.register_temp_plugin like this?
| course_sequence_ids = get_sequence_usage_keys(course) | ||
| component_templates = get_component_templates(course) | ||
|
|
||
| component_templates = _filter_component_templates_for_xblock(component_templates, xblock) |
There was a problem hiding this comment.
The problem with filtering the existing component_templates list is that some XBlocks, or at least Problem Builder, expect to be able to add new types of XBlock to this list.
For example, Problem Builder has all kinds of special child blocks that it allows, as well as plain html children:
So we should see a list of XBlocks like this:
But, since most of those aren't available in the "normal" list of components, all we see on the sandbox is this:
There was a problem hiding this comment.
Ah that makes sense. @salman2013 , do you know where to go from here?
5 participants
Description
Note: The changes in this PR is generated by Claude Sonet 4.6, reviewed by Salman. Based on the implementation plan suggested on the original ticket (openedx/frontend-app-authoring#2620)
The bug details can be found on the ticket: openedx/frontend-app-authoring#2620
As per the proposed implementation plan
In this PR we fixes issues caused by legacy add-component buttons being rendered for non-vertical container types inside the MFE iframe.
We introduce changes to ensure that container blocks rendered inside the MFE only expose component templates that are explicitly allowed by the container XBlock configuration.
frontend-app-authoring changes PR is available: openedx/frontend-app-authoring#3058
Acceptance Criteria
Using the Steps to reproduce mention here (conditional + at least one of xblock-controlled-navigation, xblock-content-restrictions, xblock-extemporaneous-grading):
Testing:
Sandbox for testing: https://github.com/openedx/frontend-app-authoring/pull/3058/checks?check_run_id=75731943406