Skip to content

sr_ewaste_compliance v1.0.0 — 2026-04-12

Author: Dan Branch: jan Conflicts with staging-2: None Commit: d62a6a77 (packaging fix)

What Changed

First installation of sr_ewaste_compliance into the Scott Recycling production database (sr_live_jan19_backup on EXP). The module was already written and committed but had never been installed — this deployment closes four compliance gaps identified in the Enterprise Master Plan Section 16 (E-Waste Compliance Operations).

Functionality Provided

  1. Chain of Custody Tracking — compliance.intake and compliance.intake.line models track material from pickup through final disposition. Each intake links to the originating pickup, driver, date, destination bin, and handoff chain.
  2. NIST 800-88 Data Destruction — compliance.data.destruction records destruction events with method (Clear/Purge/Destroy), verification, witness, and certificate generation. Integrates with the existing HIPAA workflow.
  3. Focus (Hazardous) Material Tracking — compliance.focus.material tracks storage duration of regulated materials (CRTs, batteries, mercury-containing equipment) with automated alerts when storage exceeds regulatory thresholds.
  4. Downstream Vendor Certification Management — compliance.downstream.vendor and compliance.vendor.certification track R2, e-Stewards, ISO, NAID certifications for every vendor that receives material from us. Daily cron warns when certifications are approaching expiry.
  5. Diversion Reporting — compliance.diversion calculates diversion rates (material recycled vs. landfilled) per period, per material type. Generates customer-facing diversion certificates.
  6. Certificate Generation — compliance.certificate produces compliance certificates for customers (destruction, diversion, chain of custody) with sequential numbering and audit trail.
  7. Nwipe/ShredOS Integration — compliance.nwipe.import.log parses nwipe wipe logs and shreddos verification logs, matching them to device records. Cron runs every 30 minutes to pick up new logs from the drop directory.

Tables Created (9)

  • compliance_intake — chain of custody parent record
  • compliance_intake_line — individual items in a chain of custody entry
  • compliance_data_destruction — NIST 800-88 destruction events
  • compliance_focus_material — hazardous material tracking with storage alerts
  • compliance_downstream_vendor — vendors receiving material from us
  • compliance_vendor_certification — R2/e-Stewards/ISO/NAID cert tracking
  • compliance_certificate — customer-facing certificates
  • compliance_diversion — diversion rate tracking
  • compliance_nwipe_import_log — nwipe/ShredOS import history

Cron Jobs Created (3, all active by default)

Cron Interval Purpose
Compliance: Check Focus Material Storage Alerts 1 day Flag hazardous materials exceeding storage duration threshold
Compliance: Check Expiring Vendor Certifications 1 day Warn when vendor R2/e-Stewards certs approach expiry
Compliance: Import nwipe/ShredOS Logs 30 min Parse new wipe logs from drop directory, match to devices

Sequences Created (3)

  • compliance.intake — sequential intake numbering
  • compliance.certificate — sequential certificate numbering
  • compliance.data.destruction — sequential destruction event numbering

Packaging Fix

The initial install attempt on EXP failed with a PermissionError from docutils. Root cause: the module had no static/description/index.html, so Odoo's ir_module_module._get_desc() fell back to rendering the manifest's RST description field via docutils. docutils tried to locate html4css1.css via a CWD-relative path walk, which the odoo service user could not stat, triggering PermissionError and aborting the registry load.

Fix (commit d62a6a77): Added a standard placeholder sr_ewaste_compliance/static/description/index.html. This short-circuits the docutils path entirely and matches how every other sr_ module is packaged. This fix is permanent and works on all databases and all servers.

Important: If any prior sr_ewaste_compliance install worked elsewhere (including your localhost dev box), it was working by accident — the docutils CWD walk happened to land in a readable directory for the odoo17 user. The placeholder HTML file is the correct permanent fix.

Deploy Commands

# 1. Pull the code (must include commit d62a6a77)
cd /opt/odoo/custom_addons/Dan-Odoo
git pull origin jan
test -f sr_ewaste_compliance/static/description/index.html || echo "MISSING FIX — ABORT"

# 2. Take a pre-install backup (safety net)
sudo -u postgres pg_dump <DATABASE> | gzip > /opt/backups/odoo/pre_ewaste_install_$(date +%Y%m%d_%H%M).sql.gz

# 3. Stop the service
sudo systemctl stop odoo.service     # EXP uses odoo.service, not odoo17

# 4. Install (note: launch from /tmp for CWD safety)
sudo -u odoo bash -c 'cd /tmp && /opt/odoo/odoo17-venv/bin/python3 /opt/odoo/odoo17/odoo-bin -c /etc/odoo/odoo.conf -d <DATABASE> -i sr_ewaste_compliance --stop-after-init --logfile=/tmp/ew_install.log'

# 5. Check log for errors
grep -iE "ERROR|CRITICAL|Traceback" /tmp/ew_install.log | tail -20
# Expected: empty or only pre-existing unrelated warnings

# 6. Restart
sudo systemctl start odoo.service
sleep 5
curl -s -o /dev/null -w "HTTP %{http_code}\n" http://localhost:1819/web/login
# Expected: HTTP 200

Post-Deploy Verification

# Module state
sudo -u postgres psql <DATABASE> -c "SELECT name, state, latest_version FROM ir_module_module WHERE name = 'sr_ewaste_compliance';"
# Expected: installed | 17.0.1.0.0

# Tables
sudo -u postgres psql <DATABASE> -c "\dt compliance_*"
# Expected: 9 tables listed

# Crons
sudo -u postgres psql <DATABASE> -c "SELECT cron_name, active FROM ir_cron WHERE cron_name ILIKE '%compliance%';"
# Expected: 3 active crons

# Sequences
sudo -u postgres psql <DATABASE> -c "SELECT name, code FROM ir_sequence WHERE code LIKE 'compliance.%';"
# Expected: 3 sequences

Test Checklist

EXP (already verified 2026-04-12)

  • Module upgrades without errors
  • All 9 tables created
  • 3 active crons visible in ir_cron
  • 3 sequences created
  • Odoo HTTP 200 after restart
  • /opt/monitoring/health-check.sh reports all services healthy
  • No new errors in journalctl -u odoo.service

1820

  • Module upgrades without errors
  • All 9 tables created
  • Crons visible and active
  • HTTP 200 after restart
  • Load the Compliance menu in Odoo web UI — should render without errors
  • Create a test compliance.intake record manually
  • Create a test compliance.data.destruction record linked to a device
  • Run functional tests: FUNCTIONAL_TESTS_EWASTE_COMPLIANCE.md

Staging (1717)

  • Module upgrades without errors
  • All above tests pass
  • Cron jobs run once successfully (check ir_cron.lastcall)
  • No performance regression on existing workflows

Production

  • Pre-install backup taken and verified restorable
  • Module upgrades without errors on production database
  • No impact on existing operations
  • First 24 hours: monitor for new errors in journalctl
  • First week: verify the 3 crons run without errors

Programmer's Notes

  • Dependencies: sr_management, hr, mail — all standard, no conflicts.
  • Localhost 1818 test1 already has the module installed at v17.0.1.0.0 (with test data). The packaging bug didn't surface there because the dev CWD at service start is readable. Don't be surprised to find tables already populated with test records on that database.
  • The three crons are benign with zero records — they just scan empty tables until data exists. Low overhead. Monitor log volume during the first week to confirm.
  • Nwipe import directory — the nwipe cron reads from a directory configured via system parameter (check ir_config_parameter for the key). If nwipe is not in use, the cron runs and finds nothing, no error.
  • Chain of custody is append-only — existing intake records should never be modified after creation. Edits leave audit trail in mail.message. This is intentional for compliance integrity.
  • Model not yet linked to existing workflows — the compliance models are standalone. Linking them to customer.pickups, processed.inventory.item, and the CSR pickup flow is a future enhancement. For now the module provides the data model and the admin UI; operational linkages come next.
  • R2 certification readiness — installing this module is a prerequisite for R2 certification, not a sufficient condition. Full R2 requires operational changes documented in compliance/r2-certification.md.

Rollback

# Option 1: Restore from pre-install backup (cleanest)
sudo systemctl stop odoo.service
sudo -u postgres psql -c "DROP DATABASE <DATABASE>;"
sudo -u postgres psql -c "CREATE DATABASE <DATABASE> OWNER odoo;"
gunzip -c /opt/backups/odoo/pre_ewaste_install_<TIMESTAMP>.sql.gz | sudo -u postgres psql <DATABASE>
sudo systemctl start odoo.service

# Option 2: Uninstall via Odoo (leaves residual data)
# Not recommended for this module — chain of custody tables are audit records.
# Prefer option 1 if rollback is needed.