feat: pdf block

[Kelketek]

Overview

This merge request pulls the PDF block in, extracted from a third party plugin. For now, it does not use its intended block name (pdf), and instead uses a temporary one (_pdf_extracted) as there's more work to do in order to fulfill the scope of the PDF Block Proposal. Once this work is completed, it will be renamed to pdf and be considered generally available.

Some minor alterations have been made to the block in order to allow it to be added to the contribs repository. These include the addition of tests, the migration from xblock_utils to xblock.utils, cleanup of lint issues and some spot improvements to docstrings. Otherwise, functionality has been largely left unchanged as this is the first part of the proposal-- moving the block into the contribs library.

Supporting information

• https://openedx.atlassian.net/wiki/spaces/OEPM/pages/5335908397/Proposal+Add+PDF+Block+to+Base+Installation
• https://github.com/open-craft/xblock-pdf

Testing Instructions

1. Bring up a standard modern tutor devstack installation
2. Rather than adding this as a requirement in the config, we must install it manually due to conflicts in the installation order:
   1. Enter the LMS with tutor dev dc exec -it lms -- /bin/bash
   2. Install the package with pip install -e git+https://github.com/open-craft/xblocks-contrib.git@fox/xblock-pdf#egg=xblocks_contrib
   3. Exit the shell and then enter the CMS shell with tutor dev dc exec -it cmd -- /bin/bash
   4. Install the package with pip install -e git+https://github.com/open-craft/xblocks-contrib.git@fox/xblock-pdf#egg=xblocks_contrib
3. In a course, enter the advanced settings and add "_pdf_extracted" to the list of advanced blocks.
4. In the authoring interface, click on the advanced modules and select the PDF Block.
5. Edit and play with it.

Deadlines

This should preferably be merged within the next couple of weeks so that other work depending on it is not blocked. The PDF Block proposal implementation is slated for Verawood.

Author Concerns

This block is fully functional, and while a large number of instances have installed it, it's not part of the standard and it might work just as well to immediately give it its intended name, pdf, and then focus on the changes to the authoring interface (which will likely be added to the frontend authoring MFE), allowing the current interface to be used until this is ready.

Merge checklist:
Check off if complete or not applicable:

• Version bumped
• Changelog record added
• Documentation updated (not only docstrings)
• Fixup commits are squashed away
• Unit tests added/updated
• Manual testing instructions provided
• Noted any: Concerns, dependencies, migration issues, deadlines, tickets

[openedx-webhooks]

Thanks for the pull request, @Kelketek!

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

[Kelketek]

@samuelallan72 I'm not sure how, but it seems I accidentally closed the other PR. Maybe some automation did it?

To answer your questions from there:

We were pulling these changes from the master branch. The initial proposal only focused on the initial contribution of the block as it exists in the community as a first step. The subsequent customizations (such as for Gotenberg document conversion support) are something we plan to do in a subsequent proposal/PRs.

I did find a couple of fixes that only existed in WGU's branch and applied those. One of them was your improvement to the messaging around downloads, and the other was the inclusion of JS linting. I have tentatively included the JS linting here (I had to change the configuration-- it works on the other repo mostly by accident.) The downside of adding JS linting is that we either have to exclude the existing JS files or else start cleaning them up. I've added an example cleanup of the Annotation block's JS in case the latter is the way to go, but we might want upstream to weigh in before committing.

There were minor changes to the JS in the wgu branch-- switching from var to const. However, I didn't port those over since nothing else in this repo does that, and it doesn't fail the linter, believe it or not.