Migrated legacy library content should be published upon migration

[edschema]

Current Behavior
Upon migration from a legacy library to a Content Library, all migrated components are in a never-published status.

This can be a pain point for users in the following scenario:

• A large legacy library is used in a course.
• The legacy library is migrated with the intent of using the Content Library to make changes and push to the course, but also reuse content in other ways
• In order to make those components available to re-use, each component in that large legacy library needs to be published individually, or through the library publish button. The bulk action is not ideal because there may be changes outside of the legacy library that are not ready for publish. The individual publish method is not ideal because it will be very time intensive
• Once those migrated components are published, a course will see all the components listed separately on the library updates page.

Desired Behavior
Upon migration from a legacy library to a Content Library, content should be published and ready for re-use.

[ChrisChV]

Hi @jmakowski1123 @sdaitzman @edschema this is ready for AC testing on the sandbox

[edschema]

Hi @ChrisChV, components that are migrated are now published upon migration. This solves the above issue of necessitating a publish on all components within the library. The second issue is still unsolved: upon migration, each component that has been migrated is now shown on the library updates page.

I can't think of a graceful solution here... If we auto-sync all components upon updating the reference seems like the simplest, but I'm concerned about the scenario where, between a migration and a course author updating the reference, somebody published a new version of a component. In that case, if we auto-sync upon updating the reference, a course will have a version of a component the course author never approved/ saw... Can you think of a good way to handle this scenario?

I'd be curious to hear your thoughts as well @sdaitzman

[sdaitzman]

Definitely not ideal, but I would probably be inclined toward not auto-syncing if that check for any intervening versions is impossible, and leaving the requirement that course authors accept the update (even though it may show no content changes). It's a significant hassle, but it should affect a relatively small number of users, and those users only once per block they update. I'll think more about it, and definitely very open to other suggestions if there are technical options available...

[kdmccormick]

Based on our conversation at sync:

I believe a check for intervening versions is possible. We just need to make a record of the original version (currently, we're just recording the post-migration reference version as "0", which is conservative, and makes it so that a sync is always available). I think the fix can be done here: https://github.com/openedx/edx-platform/blob/b1f01ed8fa848124cfd367fc303cee49dfc9320a/xmodule/library_content_block.py#L325-L327

I'll work on a getting a PR up soon.