Fix Container Blocks in the New Unit Editor

[salman2013]

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):

• All Add New Component buttons function — no silent no-ops on Text / Library Content / Open Response / Advanced.
• Video editor closes cleanly; no "connection error" panel afterwards.
• No oversized grey iframe around Problem/Video editors.
• A container block that declares a restricted allowed_nested_blocks shows only the declared subset, with disabled / single_instance honored if surfaced.
• A container block that does not use StudioContainerWithNestedXBlocksMixin shows the full standard button set and behaves identically to a normal unit.
• No additional API round-trips on container open vs. today.

Testing:

Sandbox for testing: https://github.com/openedx/frontend-app-authoring/pull/3058/checks?check_run_id=75731943406

[openedx-webhooks]

Thanks for the pull request, @salman2013!

This repository is currently maintained by @openedx/wg-maintenance-openedx-platform.

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 approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

• If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
  • This process (including the steps you'll need to take) is documented here.
• If it doesn't, simply proceed with the next step.

🔘 Provide context

To 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:

• Dependencies

  This PR must be merged before / after / at the same time as ...

• Blockers

  This PR is waiting for OEP-1234 to be accepted.

• Timeline information

  This PR must be merged by XX date because ...

• Partner information

  This is for a course on edx.org.

• Supporting documentation
• Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

Details

---

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:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

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:

• The size and impact of the changes that it introduces
• The need for product review
• Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

[openedx-webhooks]

Thanks for the pull request, @salman2013!

This repository is currently maintained by @openedx/wg-maintenance-openedx-platform.

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 approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

• If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
  • This process (including the steps you'll need to take) is documented here.
• If it doesn't, simply proceed with the next step.

🔘 Provide context

To 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:

• Dependencies

  This PR must be merged before / after / at the same time as ...

• Blockers

  This PR is waiting for OEP-1234 to be accepted.

• Timeline information

  This PR must be merged by XX date because ...

• Partner information

  This is for a course on edx.org.

• Supporting documentation
• Relevant Open edX discussion forum threads

🔘 Get a green build

If 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 PR

Your 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:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

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:

• The size and impact of the changes that it introduces
• The need for product review
• Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

[bradenmacdonald]

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?

[bradenmacdonald]

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:

https://github.com/open-craft/problem-builder/blob/b89d0419ae247ad0a39bc4af989859b9a3014270/problem_builder/mentoring.py#L379-L384

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:

[kdmccormick]

Ah that makes sense. @salman2013 , do you know where to go from here?

[salman2013]

@kdmccormick I am not really sure, as per my understanding, the plan said

edx-platform — extend the existing container_handler response so its component_templates list is filtered by allowed_nested_blocks when the container uses the mixin. Blocks that don't use the mixin keep getting the unfiltered (default) list.

Should I send the unfiltered list from the backend, as the existing code currently does?

[kdmccormick]

The logic you have implemented is this:

• Start with the base component_templates
• Is the block a StudioContainerWithNestedXBlocksMixin?
  • Yes -> Filter component_templates based on block.get_nested_xblock_spec
  • No -> Just use component_templates

Instead, the logic should be this:

• Is the block a StudioContainerWithNestedXBlocksMixin?
  • Yes -> Ignore component_templates. Use block.get_nested_xblock_spec instead.
  • No -> Use component_templates

This matters because block.get_nested_xblock_spec contains new templates which are not part of component_templates, such "Ranged Value Slider" and "Long Answer Recap" (see Braden's screenshot above). Those new templates should be displayed even though they're not part of component_templates.

Currently, we're only seeing Text (HTML) because that is the only template shared both by both component_templates and by ProblemBuilder.get_nested_xblock_spec.

[salman2013]

@bradenmacdonald @kdmccormick
I have fixed the logic and now the following results are showing

[salman2013]

@bradenmacdonald @kdmccormick

The MFE has built-in support for the following component types (each has an explicit case in this switch):

• discussion
• drag-and-drop-v2
• problem
• video
• library
• itembank
• library_v2
• advanced
• openassessment
• html

Any other type — for example container-specific blocks declared via StudioContainerWithNestedXBlocksMixin.allowed_nested_blocks on the
backend — falls to the default case. The types would appear inside the Advanced components modal instead of creating a new XBlock directly.

To show the components like this I need to handle this on the frontend side

handleCreateNewCourseXBlock({ type, category: type, parentLocator: blockId });

Ref openedx/frontend-app-authoring@98cfa13