feat(spp_drims): Dispatch page and waybill review — locked lines, one-page waybill

docker/requirements.txt

@@ -19,6 +19,17 @@ git-aggregator==4.0
 # PDF processing (reportlab uses these)
 pdfminer.six
 
+# renderPM backend for reportlab 4.x, which every barcode and QR code in every
+# Odoo report goes through: /report/barcode/ -> ir.actions.report.barcode() ->
+# Drawing.asString('png') -> renderPM. reportlab 4.1 defaults
+# rl_config.renderPMBackend to 'rlPyCairo', and without it that route answers
+# HTTP 500 with "cannot import desired renderPM backend rlPyCairo" (OP#1151).
+# Odoo's own requirements only pin a backend for win32, assuming the Debian
+# python3-renderpm package covers Linux — this image does not install it.
+# Builds fine here: the builder stage already has libcairo2-dev and the runtime
+# image ships libcairo2.
+rlPyCairo
+
 # -----------------------------------------------------------------------------
 # OpenSPP Specific (not in module manifests but required)
 # -----------------------------------------------------------------------------

spp_drims/README.rst

@@ -179,6 +179,25 @@ Dependencies
 Changelog
 =========
 
+19.0.3.0.4
+~~~~~~~~~~
+
+- feat(drims): rework the dispatch page and correct the waybill.
+  **Dispatch & Delivery** leads the form instead of sitting behind
+  Additional Info, a dispatch shows its destination location rather than
+  an empty Delivery Address, and everything the request already decided
+  — operation type, source document, source location and the DRIMS
+  fields — is locked, with Quantity left editable so a partial dispatch
+  and its backorder can still be produced. The waybill prints on one
+  page with the signature block intact and the TO box filled in (#1150,
+  #1151)
+- **Deployment note:** the waybill's barcode needs the ``rlPyCairo``
+  renderer, added to ``docker/requirements.txt`` in this change.
+  Upgrading the module is not enough — the container image has to be
+  **rebuilt**, or every report containing a barcode or QR code answers
+  HTTP 500. The waybill itself still prints without it, minus the
+  barcode (#1151)
+
 19.0.3.0.1
 ~~~~~~~~~~
 

spp_drims/__manifest__.py

@@ -5,7 +5,7 @@
     "and distribution tracking. Links to hazard incidents with multi-tier "
     "approval workflows and warehouse operations.",
     "category": "OpenSPP/Inventory",
-    "version": "19.0.3.0.1",
+    "version": "19.0.3.0.4",
     "sequence": 1,
     "author": "OpenSPP.org",
     "website": "https://github.com/OpenSPP/OpenSPP2",
@@ -68,6 +68,7 @@
         "views/request_template_views.xml",
         "views/return_views.xml",
         "views/stock_picking_views.xml",
+        "views/stock_move_views.xml",
         "views/stock_warehouse_views.xml",
         "views/stock_quant_views.xml",
         "views/stock_lot_views.xml",

spp_drims/models/stock_picking.py

@@ -1,4 +1,5 @@
 # Part of OpenSPP. See LICENSE file for full copyright and licensing details.
+import base64
 import json
 import logging
 
@@ -179,6 +180,46 @@ def action_open_gis_map(self):
         """Open the unified DRIMS Operations Map."""
         return self.env.ref("spp_drims.action_drims_operations_map").read()[0]
 
+    def _get_waybill_barcode_data_uri(self, width=300, height=50):
+        """Return the waybill number as an embedded Code128 ``data:`` URI (OP#1151).
+
+        The waybill template used to point an ``<img>`` at ``/report/barcode/``.
+        That makes the barcode depend on wkhtmltopdf being able to fetch a URL
+        from inside the rendering process, so it silently vanished whenever
+        ``web.base.url`` was not reachable there — which is the normal state of a
+        containerised deployment where Odoo listens on 8069 internally but
+        ``web.base.url`` holds an external host and port. Embedding the image
+        removes the network round trip, so the barcode renders the same in dev,
+        CI and production.
+
+        Requires reportlab's renderPM backend (``rlPyCairo``) to be installed;
+        see ``docker/requirements.txt``. Returns ``False`` rather than raising if
+        the barcode cannot be produced, since a missing barcode must not stop a
+        waybill printing.
+
+        Returns:
+            str | bool: ``data:image/png;base64,...`` or ``False``.
+        """
+        self.ensure_one()
+        if not self.waybill_number:
+            return False
+        try:
+            png = self.env["ir.actions.report"].barcode(
+                "Code128",
+                self.waybill_number,
+                width=width,
+                height=height,
+                humanreadable=0,
+            )
+        except Exception:  # noqa: BLE001 - never let a barcode break the document
+            _logger.warning(
+                "Could not render the Code128 barcode for waybill %s; printing without it. Is rlPyCairo installed?",
+                self.waybill_number,
+                exc_info=True,
+            )
+            return False
+        return "data:image/png;base64," + base64.b64encode(png).decode()
+
     def action_confirm_departure(self):
         """Confirm dispatch departure."""
         for rec in self:

spp_drims/readme/HISTORY.md

@@ -1,3 +1,8 @@
+### 19.0.3.0.4
+
+- feat(drims): rework the dispatch page and correct the waybill. **Dispatch & Delivery** leads the form instead of sitting behind Additional Info, a dispatch shows its destination location rather than an empty Delivery Address, and everything the request already decided — operation type, source document, source location and the DRIMS fields — is locked, with Quantity left editable so a partial dispatch and its backorder can still be produced. The waybill prints on one page with the signature block intact and the TO box filled in (#1150, #1151)
+- **Deployment note:** the waybill's barcode needs the `rlPyCairo` renderer, added to `docker/requirements.txt` in this change. Upgrading the module is not enough — the container image has to be **rebuilt**, or every report containing a barcode or QR code answers HTTP 500. The waybill itself still prints without it, minus the barcode (#1151)
+
 ### 19.0.3.0.1
 
 - fix(drims): a dispatch validated short no longer leaves the request looking fully dispatched. The backorder is announced on the request with a to-do for the coordinators, the request reopens as Ready for Dispatch so the remaining balance can be dispatched again, and the dispatched totals are rebuilt on the allocation rows. Applies however the transfer is validated — the web client, the barcode flow or the API (#1087)