Add Waffle 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.

Testing notes:

It requires to restart lms/cms to put the waffle flag into effect

Ticket: #35308

Waffle 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

Current Status:

• Waffle flags word_cloud, annotatable, poll_question, lti, html has been tested on lms and cms
• Waffle flags discussion, problem, video has been tested on lms and cms
  • They are currently reverted because of excessive amount of test cases were failing.

Next action items:

• Fix all the test cases related to word_cloud, annotatable, poll_question, lti, html
• Put back implementation of discussion, problem, video (one by one if required)
• Fix all the test cases

[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

[farhan]

@kdmccormick @openedx/axim-aximprovements @ttqureshi PR is available for code review
Things to mention:

1. Please review the settings files, either I have added the flags in right module
2. Tests are failing 9b75f1e when turn the extracted block flags, which is fine but should be tested when we will publish the extracted block functionality in the xblocks-contrib pypi package.
   a. We should add it in the acceptance criteria of the extracted xblock story.

[ttqureshi]

Looks good to me!

[kdmccormick]

Thanks for converting the flags to toggles. Just a couple more comments from me.

[farhan]

@kdmccormick @feanil
PR is available for code review again
CMS requires to add the settings flags into its cms/envs/common.py file, so I have imported there as well
Tests were failing 2b57c29

Please squash & merge in time slot, if all seems ok

[feanil]

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.

[farhan]

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.

Thanks for sharing your extensive thoughts @feanil

On my recent testing experience with some Problem XBlocks, their UI is disturbed, it's fine on master

Let's figure out the ripples and have its testing
cc: @irtazaakram @ttqureshi

[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.