feat: easy alternative views

[Kelketek]

Description

This PR makes it easier to test the studio and authoring views from within the workbench. This is already supported, but currently requires you to manually specify the scenario URL. This desire to avoid picking specific views made sense in the context of XBlock's original vision which might not expect there to necessarily be a studio as part of the spec. In practice, the Open edX platform is the only implementation, and is expected to stay that way, so adding some opinionated conveniences helps here.

This also includes a 'notify' function shim for the runtime. Both the LMS and studio have this notify function. We implement it here as logging.

Testing instructions

1. Set up the workbench
2. Install a block you'd like to test
3. Visit the block's scenario
4. Verify you can also load the studio scenario, and the authoring scenario, if present
5. Save, and refresh to verify the state has changed

[openedx-webhooks]

Thanks for the pull request, @Kelketek!

This repository is currently maintained by @openedx/axim-engineering.

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.

[samuelallan72]

@Kelketek 👍

• I tested this: followed test instructions
• I read through the code
• I checked for accessibility issues
• Includes documentation

[Kelketek]

@farhan Would you be up for reviewing this?

[farhan]

@farhan Would you be up for reviewing this?

Changes LGTM, adding some test cases would be great

[Kelketek]

@farhan Added a test for this.

[farhan]

@Kelketek
Do you access to merge it or do you want me to merge it?

[Kelketek]

@farhan I don't have merge rights on this repository. Please merge it if it looks good to you. :)

[farhan]

@Kelketek alright, let me give it a test run on monday, as I am on leaves, after that I will share results or merge it.
Thanks for the contribution!

[Kelketek]

@farhan Follow-up ping here. Did you have a chance to test this?

[farhan]

@Kelketek all seems good, thanks for valuable addition of studio and author view test rendering.

I tested on html_demo, helloworld_demo, and filethumbs blocks exist within xblocks-sdk

Here is the screenshot of author_view of filethumbs which doesn't exist (not implemented)

---

Bug: get_block_views() advertises views that child blocks cannot render

🤖 Following is Claude Code generated analysis and fix.

Problem

get_block_views() in workbench/views.py calls hasattr(block, view_name) on the root block only. For scenarios where the root is a container like VerticalBlock (which inherits ExtraViewsMixin), __getattr__ intercepts any *_view attribute lookup and returns True — so author_view and studio_view links are shown in the UI even when the actual child blocks don't implement those views.

In the filethumbs scenario, the root is VerticalBlock with three FileThumbsBlock children. FileThumbsBlock only implements student_view and has no fallback_view. Navigating to /author_view/ renders the broken error:

No such view: author_view on <FileThumbsBlockWithMixins ...>

Suggested Fix

Replace get_block_views() in workbench/views.py with the following two methods:

def _block_can_render_view(block: XBlock, view_name: str) -> bool:
    """Check if a block can render a view (has explicit method or fallback_view catch-all)."""
    return (
        getattr(block, view_name, None) is not None or
        getattr(block, 'fallback_view', None) is not None
    )


def get_block_views(block: XBlock) -> set[str]:
    """Get the available views for a block.

    For container blocks, checks direct children — a view is only offered if all
    children can actually render it, preventing structural wrappers (e.g. VerticalBlock
    with ExtraViewsMixin) from advertising views that their children cannot handle.
    """
    children = getattr(block, 'children', [])
    if children:
        child_blocks = [block.runtime.get_block(child_id) for child_id in children]
        return {
            view_name for view_name in KNOWN_BLOCK_VIEWS
            if all(_block_can_render_view(child, view_name) for child in child_blocks)
        }
    return {
        view_name for view_name in KNOWN_BLOCK_VIEWS
        if _block_can_render_view(block, view_name)
    }

_block_can_render_view() mirrors the XBlock runtime's own view resolution logic: a block can render a view if it has an explicit method for it or a fallback_view catch-all. This is important — e.g. HtmlBlock only defines fallback_view, so a plain hasattr check on the child would incorrectly return False for all views.

After Fix — Test Results

Scenario	Root block	Children	Views shown (before)	Views shown (after)
html_demo	VerticalBlock	HtmlBlock (has fallback_view)	student_view, author_view, studio_view	student_view, author_view, studio_view ✓
helloworld_demo	HelloWorldBlock (no children)	—	student_view only	student_view, author_view, studio_view (all handled via fallback_view) ✓
filethumbs	VerticalBlock	FileThumbsBlock (only student_view, no fallback_view)	student_view, author_view, studio_view ✗	student_view only ✓

[Kelketek]

Thanks @farhan . Good catch on the other views-- I had been testing in a virtualenv only with the blocks we were developing on and missed those scenarios. I wrote a simpler form of what Claude suggested and its behavior matches the table it gave.