fix(docker): stop legacy PyPDF2 3.x shadowing pypdf, breaking multi-record PDF print

[gonzalesedwin1123]

Summary

• Install Odoo with uv pip install --no-deps in docker/Dockerfile. Odoo's setup.py declares an unpinned PyPDF2, so the editable install pulled legacy PyPDF2 3.0.1 alongside the pypdf 5.4.0 that OCB's requirements.txt pins for Python 3.13 (all of Odoo's real dependencies are already installed from that requirements file two layers earlier).
• odoo/tools/pdf probes the legacy PyPDF2 package before pypdf with no version guard, so PyPDF2 3.x won the backend selection — and its removed 1.x API (reader.numPages, getPage) raises PyPDF2.errors.DeprecationError in ir.actions.report._render_qweb_pdf_prepare_streams whenever a report is printed for more than one record (single-record printing skips the split path, which is why it still worked).
• Add a regression test in spp_base_common (test_pdf_backend.py) that exercises the exact legacy split API against the image's selected PDF backend; it fails with the production error on any image that regresses.
• Bump spp_base_common to 19.0.2.0.2 with a readme/HISTORY.md fragment.

OpenProject

• Fixes OP#1168 (Unable to print PDF for multiple records)

Test plan

• TDD red: test fails on the pre-fix image with PyPDF2.errors.DeprecationError: reader.numPages ... removed in PyPDF2 3.0.0 — identical to the OP#1168 screenshot
• TDD green: ./spp t spp_base_common on the rebuilt image — 7 passed, 0 failed, 0 errors
• Rebuilt image has no PyPDF2 installed; odoo.tools.pdf selects the _pypdf backend (pypdf 5.4.0)
• End-to-end: _render_qweb_pdf('base.report_irmodulereference', res_ids=[<3 ids>]) in the running dev container returns a valid PDF through wkhtmltopdf + the multi-record split path
• No bundled addon imports PyPDF2 directly (grepped /mnt/extra-addons and the OCA addon trees)

Notes

• Root cause is upstream: OCB setup.py:52 unpinned PyPDF2 contradicts its own requirements.txt pin of PyPDF==5.4.0 for py3.13, and odoo/tools/pdf/_pypdf2_2.py accepts PyPDF2 3.x without a version guard. Upstream reports to follow; this PR fixes our image regardless.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.34%. Comparing base (c33d3cb) to head (fd828cd).

Additional details and impacted files

@@            Coverage Diff             @@
##             19.0     #407      +/-   ##
==========================================
+ Coverage   71.49%   72.34%   +0.84%     
==========================================
  Files         243      404     +161     
  Lines       20785    29008    +8223     
==========================================
+ Hits        14860    20985    +6125     
- Misses       5925     8023    +2098     

Flag	Coverage Δ
spp_analytics	93.25% <ø> (?)
spp_api_v2_change_request	66.53% <ø> (ø)
spp_api_v2_cycles	71.03% <ø> (?)
spp_api_v2_data	77.77% <ø> (?)
spp_api_v2_entitlements	70.23% <ø> (?)
spp_api_v2_gis	71.57% <ø> (?)
spp_api_v2_programs	92.22% <ø> (?)
spp_api_v2_service_points	71.03% <ø> (?)
spp_api_v2_simulation	71.19% <ø> (?)
spp_approval	50.34% <ø> (?)
spp_area	80.16% <ø> (?)
spp_area_hdx	81.60% <ø> (?)
spp_audit	72.13% <ø> (?)
spp_base_common	91.07% <ø> (ø)
spp_case_cel	89.50% <ø> (?)
spp_case_demo	94.75% <ø> (?)
spp_programs	65.27% <ø> (ø)
spp_registry	87.22% <ø> (+0.07%)	⬆️
spp_security	69.56% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
see 162 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[gonzalesedwin1123]

Upstream reports filed: odoo/odoo#281660 (odoo/odoo#281660) and OCA/OCB#1346 (OCA/OCB#1346). If either lands a proper fix (version guard in odoo/tools/pdf or a setup.py pin), the --no-deps here remains correct and harmless — it simply keeps requirements.txt as the single source of dependency pins.

[emjay0921]

LGTM — correct root-cause fix, and self-proving in CI.

Root cause (correctly diagnosed): Odoo's setup.py declares an unpinned PyPDF2, so uv pip install -e pulled legacy PyPDF2 3.0.1 alongside the pypdf 5.4.0 that OCB's requirements.txt pins. odoo.tools.pdf probes PyPDF2 before pypdf with no version guard, so 3.x won backend selection — and its removed 1.x API (numPages/getPage) raises DeprecationError in the multi-record split path only.

Fix: --no-deps on the editable Odoo install — safe because the real runtime deps were already installed from the pinned requirements.txt two layers earlier.

Verified (not just trusted):

• CI builds the image from this exact Dockerfile per-SHA (file: docker/Dockerfile, load: true, tags: openspp-test:${{ github.sha }}) and runs 20 module suites on it — so green CI proves --no-deps dropped no needed runtime dep.
• The new test_pdf_backend.py exercises the exact legacy split API (numPages/getPage/addPage) through odoo.tools.pdf; it fails with the production DeprecationError on a PyPDF2-3.x image, so its passing proves the rebuilt image now selects pypdf. Genuine TDD guard, well-placed in the always-installed base module.
• Confirmed no bundled addon imports PyPDF2 directly, so removing it breaks nothing.

Non-blocking notes:

1. Operational: the real fix is the Dockerfile — a running deployment needs an image rebuild, not just a spp_base_common module upgrade. The 19.0.2.0.2 bump only carries the test + HISTORY; worth calling out in the release note so nobody upgrades the module alone and expects a fix.
2. Latent assumption: --no-deps relies on OCB's requirements.txt being a complete superset of Odoo's runtime deps; a future Odoo bump adding a dep only in setup.py would be silently dropped — but CI would catch it immediately (import errors), so it's self-guarding.
3. Cross-repo: this is the root-cause fix for the same PyPDF2-3.0 multi-record print bug flagged on DSWD #1835 — that side benefits once its image rebuilds on the fixed base.