Refactor or deprecate parent-child relationships between XBlocks

[kdmccormick]

This would be a long-term initiative. It probably belongs on the platform-roadmap.

Context

We have decided that parent-child relationships should only exist at/below the VerticalBlock: https://github.com/openedx/edx-platform/blob/master/docs/decisions/0006-role-of-xblock.rst

We have further discussed that parent-child relationships in their entirety should be removed; I'm not sure if we came to a consensus on that.

TODO -- Add more context ( @ormsbee , @kdmccormick , and @bradenmacdonald ).

Tasks

Off the top of my head...

• File a DEPR encompassing our plan to:
  • Remove parent-child relationships on the base XBlock class. Delete the _HasChildrenMetaclass. Move all parent-child logic to a new subclass, XBlockWithChildren. Make it XBlock.has_children a read-only class property. Some details.
  • Raise an exception if get_parent is called at or above the VerticalBlock level.
  • For all XBlockWithChildren subclasses above the VerticalBlock (so, CourseBlock, SectionBlock, and SequenceBlock): Move their implementations to either Learning Core or edx-platform djangoapps.
• Decide: Should parent-child relationships still exist at/below the Vertical block?
  • Either way -> ADR it.
  • Yes -> We're done.
  • No -> File another DEPR encompassing our plan to:
    • Raise deprecation warnings on the XBlockWithChildren class.
    • For all remaining XBlockWithChildren subclasses in edx-platform (eg, LibraryContentBlock, SplitTestBlock):
      Move their implementations to either Learning Core or edx-platform djangoapps.
    • Write guidance on how custom XBlockWithChildren subclasses can be similarly migrated. Ensure that, for example, OpenCraft's ProblemBuilder block can be migrated using this guide.
    • Delete the XBlockWithChildren class, and delete all parent-child logic from the XBlock repository.
    • Delete all parent-child logic from modulestore and edx-platform's XBlock runtimes.

[bradenmacdonald]

Should parent-child relationships still exist at/below the Vertical block?

Other than the "structural" XBlocks (course, sequential, vertical/unit, etc.), the only blocks I know of with has_children are:

• ConditionalBlock (built-in)
• SplitTestBlock (built-in, for A/B testing)
• LibraryContentBlock (built-in, may be renamed to Problem Bank or Item Pool Block)
• Problem Builder (which we may deprecate)
  • Problem Builder makes extensive use of child blocks. If we deprecated has_children, we'd need to figure out a path forward for courses that use Problem Builder, but that's been known for a while so needn't be a blocker here, just something to solve at the same time.

For the other three (conditional, split, LCB), I think they're going to be a blocker for now until we have some kind of Outline concept that can unify and replace them. But what I'd love to do is put in a restriction so that only those three blocks can have children, and attempting to do it for other blocks will raise an error. That way we can prevent people from introducing new dependencies on has_children.

[bradenmacdonald]

@kdmccormick @ormsbee Apparently there are three other XBlocks from eduNEXT which also rely on XBlock children, and currently only work in the legacy Studio UI:

• https://github.com/eduNEXT/xblock-controlled-navigation - kind of like a randomize content block without a library - can randomize and show only a subset of its children.
• https://github.com/eduNEXT/xblock-content-restrictions - restricts children's visibility to only allowed IP addresses or browsers or people with the password.
• https://github.com/eduNEXT/xblock-extemporaneous-grading - "allows the course author to set a due date and a late due date for a set of components. The learner will only be able to see the content of the components if they are within the established dates."

Now, these all seem like things that should be "selectors" / outline transformers / dynamic containers rather than XBlock components in our new world. So I'll mention these use cases on that other thread. But I bring it up here because I think we need to make a clear decision on what will happen to XBlocks that depend on children, i.e. DEPR that, and also we need to add something to the Authoring MFE UI to either temporarily support these use cases or state that they're unsupported, rather than the status quo of displaying a broken UI.

Thoughts?