Confirmation modal to preview and accept v2 library updates [FC-0062]

[bradenmacdonald]

Description

Part of openedx/frontend-app-authoring#1341 . Used when an author has copied library content into their course and there is a newer "upstream" version available. Implements a new modal dialog that allows authors to compare the new version to the old and then accept or ignore the update.

Video:

WIP.screen.recording.mov

Supporting information

Part of openedx/frontend-app-authoring#1341

Builds on #34925

Depends on openedx/frontend-app-authoring#1393

Testing instructions

1. Check out this branch and run tutor dev exec lms openedx-assets build --env=dev to rebuild your static assets
2. Check out View for comparing published version of library block to previous [FC-0062] frontend-app-authoring#1393 in the authoring MFE
3. Find a component, e.g. a text component, publish it, copy it, paste it into a course.
4. Edit that component in the library and publish it. You should now see the "Update available" button in the course. Click it.
5. Test the Accept and Ignore functionality. Make edits in the library as needed to facilitate testing. Confirm that only the published version will be shown as an update, and pulled in when the update is accepted.

Deadline

Before Sumac cut.

Notes

I'm not sure if there's a reasonable way to write useful/meaningful tests for this type of Backbone legacy UI code. I have updated the backend tests and will of course write tests for the parts in the MFE and the eventual equivalent we build therein.

[openedx-webhooks]

Thanks for the pull request, @bradenmacdonald!

What's next?

Please work through the following steps to get your changes 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.

🔘 Let us know that your PR is ready for review:

Who will review my changes?

This repository is currently maintained by @openedx/wg-maintenance-edx-platform. Tag them in a comment and let them know that your changes are ready for review.

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.

[pomegranited]

👍 Very clean UI for handling (what could be) a complex issue! Works perfectly.

When using this UI to preview changes to a Problem component, I'm not able to submit answers to the problem. So if it's something about correctness or hints or other config that changed in the upstream problem, downstream editors may not be able to see what changed before they have to accept it. But this could be fixed in the next iteration.

• I tested this using the PR test instructions, plus
  • Edited a copied component, then checked that Accepting upstream changes still works.
  • Ignored upstream change, and tested the Accepting the next round of changes still works.
• I read through the code
• I checked for accessibility issues by using my keyboard to navigate
• Includes documentation
• User-facing strings are extracted for translation

[DanielVZ96]

LGTM!

[bradenmacdonald]

Thanks @pomegranited! Turns out that bug is unrelated to this PR, but does reveal a problem with calling XBlock handlers on a specific version of an XBlock. I'll plan to fix in a separate follow-up PR.

Edit: issue: #35673

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