Add Django settings flags to roll out the extracted XBlocks

[farhan]

Add Waffle flags to roll out the extracted XBlocks
Flags will use to toggle between the old and new block quickly
without putting course content or user state at risk.

Ticket: #35308

Django Settings Flags

Following built in blocks wafffle flags are in action in this PR and has been implemented:

• word_cloud
• annotatable
• poll_question
• lti
• html
• discussion
• problem
• video

[open-craft-grove]

Sandbox deployment failed 💥
Please check the settings and requirements.
Retry deployment by pushing a new commit or updating the requirements/settings in the pull request's description.
📜 Failure Logs
ℹ️ Grove Config, Tutor Config, Tutor Requirements

[open-craft-grove]

Sandbox deployment failed 💥
Please check the settings and requirements.
Retry deployment by pushing a new commit or updating the requirements/settings in the pull request's description.
📜 Failure Logs
ℹ️ Grove Config, Tutor Config, Tutor Requirements

[open-craft-grove]

Sandbox deployment failed 💥
Please check the settings and requirements.
Retry deployment by pushing a new commit or updating the requirements/settings in the pull request's description.
📜 Failure Logs
ℹ️ Grove Config, Tutor Config, Tutor Requirements

[open-craft-grove]

Sandbox deployment successful 🚀
🎓 LMS
📝 Studio
ℹ️ Grove Config, Tutor Config, Tutor Requirements

[open-craft-grove]

Sandbox deployment successful 🚀
🎓 LMS
📝 Studio
ℹ️ Grove Config, Tutor Config, Tutor Requirements

[kdmccormick]

It looks like you had to correct various tests because the name of the class changed. Is the name of the class also going to show up in exports or other serializations? If so, we should not update the name here or update the name back to preserve the name in serializations.

This is a good thing to keep in mind when changing the names of any classes which are persisted to the DB. In this particular case, though, I think we are OK. As far as I know, there are no features that depend on the literal class name of the block. The names that are used in de/serialization are the tag name(s) (problem, video, etc.) that each block is mapped to in setup.py.

Looking through the test cases which were updated, it seems that they were checking the class name rather than the class itself only because the class itself (BlahBlockWithMixins) is generated on-the-fly by mixologist.

[kdmccormick]

@farhan Taking a look at your screenshot, it seems that either some CSS or JS (or both) is missing. And if you are able to still submit the problem's answer successfully, then that would imply that the JS is present, and that only the CSS is missing.

If you haven't already, try re-building static assets (npm run build-dev within tutor dev run lms bash). If that doesn't work, then I imagine that we have broke something which maps the builtin block classes to their corresponding static assets.

[kdmccormick]

One fix you could try, related to @feanil 's comment earlier, would be setting __name__ on the built-in class after its definition:

_BuiltInProblemBlock.__name__ = "ProblemBlock"

This essentially tells Python "From the perspective of the module, the class goes by one name (_BuiltInProblemBlock), but I want it to appear to other objects as if it has a different name (ProblemBlock)".

[farhan]

@kdmccormick Thanks for sharing thoughts

1. Related to exporting of course, xblocks are exporting fine as they are using tags rather than xblock class names
2. I have checked again even rebuilding assets via npm run build is not fixing UI issue (Problems, Video)
3. Running ./manage.py lms collectstatic is not fixing the ui either
4. CSS files are generated and present but they are not linking correctly or reading css from the required files
5. Problem is submitting and checked status exist even on reloading page
6. When I run the same assets on master branch, UI/styling fixes.

Next:

• So my as per my analysis, we needs to look into why css files are not linking correctly after changing of class names.
• Check the effectiveness of following solution:
  _BuiltInProblemBlock.__name__ = "ProblemBlock"

[kdmccormick]

Sounds good @farhan . You may already know this, but just in case: if you are running on tutor dev, then you will want to use npm run build-dev rather than npm run build. If you are running tutor local, then npm run build is appropriate.

[farhan]

Sounds good @farhan . You may already know this, but just in case: if you are running on tutor dev, then you will want to use npm run build-dev rather than npm run build. If you are running tutor local, then npm run build is appropriate.

I had tried npm run build-dev as well.

[farhan]

PR is available for code review.
Problem and Video Blocks are rendering normal after following change.
https://github.com/openedx/edx-platform/pull/35549/files#diff-2adcf1a5ddc155e832aeab0472da97156e8487a683da9f786198332367eacc20R2519

I have reverted the test case fixing commit.

[kdmccormick]

Good work. I have not tested it myself but I see that you have.

[kdmccormick]

We need to ensure that the HTML subclasses (CourseInfoBlock, AboutBlock, and StaticTabBlock) are based on the extracted HTML block code rather than the built-in code, as they are now. This may require exposing a new HTMLMixin class from xblocks-contrib.

This can be done in a follow-up.

[edx-pipeline-bot]

2U Release Notice: This PR has been deployed to the edX staging environment in preparation for a release to production.

[edx-pipeline-bot]

2U Release Notice: This PR has been deployed to the edX production environment.

[edx-pipeline-bot]

2U Release Notice: This PR has been deployed to the edX production environment.