Validation when publishing with publish_dependencies=False

[bradenmacdonald]

Solving this problem. Part of #463

openedx-core/tests/openedx_content/applets/containers/test_api.py

Lines 1692 to 1700 in 6b75da3

	Publishing a container with publish_dependencies=False when its unpinned
	children have never been published should either fail at publish time or
	produce a readable published state.
	If this validation is missing, the published container references child
	entities that have no Published row. Reading the published container's
	contents via get_entities_in_container(published=True) will crash with
	RelatedObjectDoesNotExist because row.entity.published doesn't exist for
	never-published children.

For now I opted for the first approach, raising an error, but I could opt to fix the get_children instead.

[openedx-webhooks]

Thanks for the pull request, @bradenmacdonald!

This repository is currently maintained by @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.

[ormsbee]

I feel like this might be another argument for making new PublishableEntities always get an entry in Published (even if it's null), but I'm not sure what kind of secondary effects that would have. In any case, this PR looks good to me. It's always easier to make things less restrictive later.

[bradenmacdonald]

@ormsbee Thanks! I'm curious, when do we even use publish_dependencies=False btw?

[ormsbee]

@bradenmacdonald: In the UX today, we don't. It's come up in discussions in the past, I believe at WGU and possibly elsewhere. I think it came up in the context of situations where you have a Section that represents a bunch of modules that are being worked on by different groups. You want to be able to add a Subsection Module to your Section, but you just want to point to the latest--i.e. you want your Section of pointers to be published, but you don't want to force the Subsections to publish their drafts.

I think that was it anyway. I just remember saying that library publishing always published all dependencies, but that the content API would allow their use case. Honestly, I suspect that it might be better handled with something like library-to-library sync--and that we should always copy/reference across contexts when we cross ownership boundaries. But that's another long conversation...