Add edi_product_endpoint glue module to fix origin_edi_endpoint_id registry crash

[Copilot]

The OCB CI job failed at registry setup with KeyError on product.template.origin_edi_endpoint_id. The crash happens because edi_endpoint_oca extends edi.exchange.consumer.mixin with origin_edi_endpoint_id, and edi_product_oca inherits that mixin on product.template / product.product / product.packaging — but edi_product_oca no longer depends on edi_endpoint_oca, so the related field target can be missing at registry time.

This PR fixes the issue by introducing an auto-installed glue module, mirroring the existing edi_sale_endpoint pattern in this repo, keeping edi_product_oca decoupled from edi_endpoint_oca.

Changes

• New module edi_product_endpoint (auto-install)

  • depends = ["edi_product_oca", "edi_endpoint_oca"], auto_install=True.
  • Carries the view inheritance that surfaces origin_edi_endpoint_id on product.template and product.packaging forms.
  • Standard OCA scaffolding: __manifest__.py, pyproject.toml, readme/DESCRIPTION.md, readme/CONTRIBUTORS.md.

• edi_product_oca

  • Dropped edi_endpoint_oca from depends; replaced with edi_core_oca (which provides edi.exchange.consumer.mixin).
  • View references to origin_edi_endpoint_id moved out to the new glue module.

• Metapackage

  • Registered odoo-addon-edi_product_endpoint in setup/_metapackage/pyproject.toml.

Why this approach

Same pattern as edi_sale_endpoint: the glue auto-installs whenever both edi_product_oca and edi_endpoint_oca are present (exactly the situation that triggered the crash), preserves the decoupling intent of PR #275, and avoids forcing the endpoint feature on users who don't want it.

[simahawk]

@copilot this is nonsense. edi_endpoint adds a field to the mixin, the mixin is inherited by edi_product but this one does not depend on edi_endpoint anymore. Probably the easiest solution is an auto-installe glue module. Evaluate this path and alternative ones.

[Copilot]

@copilot this is nonsense. edi_endpoint adds a field to the mixin, the mixin is inherited by edi_product but this one does not depend on edi_endpoint anymore. Probably the easiest solu...

You're right, the regression test was nonsense — edi_product_oca no longer depends on edi_endpoint_oca, so there's no contract to assert. Reverted in 4d… (latest commit on the branch).

Evaluation of options for the actual underlying issue (KeyError: Field edi_endpoint_id referenced in related field definition product.template.origin_edi_endpoint_id does not exist):

1. Auto-installed glue module edi_product_endpoint (your suggestion). Mirrors the existing edi_sale_endpoint pattern in this repo (depends on edi_sale_oca + edi_endpoint_oca, auto_install=True). The glue would just declare depends = ["edi_product_oca", "edi_endpoint_oca"] and auto‑install whenever both are present, which is exactly the situation that triggers the crash (consumer-mixin extension from edi_endpoint_oca adds origin_edi_endpoint_id to every model that inherits the mixin, including product.template via edi_product_oca). Pros: keeps edi_product_oca lean (its original intent), matches the established convention in this repo, fixes CI without forcing endpoint on users who don't want it. Cons: one more module to maintain; needs its own README/manifest skeleton.

2. Re-add edi_endpoint_oca dependency on edi_product_oca. Simplest one-line revert. Cons: undoes the explicit goal of PR [18.0][IMP] edi_core: add global events handling via edi.conf #275 ("decouple from endpoint"), forces endpoint on all product EDI users, defeats the modular split that was just done.

3. Move origin_edi_endpoint_id out of the consumer-mixin extension. Add it module-by-module (per concrete model) instead of via the mixin. Cons: invasive across edi_sale_oca, edi_purchase_oca, edi_account_core_oca, edi_stock_oca, etc., and breaks the abstraction edi_endpoint_oca is built on. Not worth it.

4. Make the related field tolerate missing target. E.g. compute it conditionally / guard with hasattr. Cons: hacky, framework-fighting; we'd lose store/index/search semantics; doesn't generalize for the other glue points (sale already needed a glue module too).

Recommendation: option 1 — add edi_product_endpoint (auto‑install, depends on edi_product_oca + edi_endpoint_oca). It's consistent with edi_sale_endpoint already in the repo, resolves the CI failure precisely, and keeps the decoupling intent of PR #275 intact. Happy to push that module if you confirm the direction.

[simahawk]

@copilot go for opt 1

[simahawk]

@copilot go for opt 1

[Copilot]

@copilot go for opt 1

Done in 6802b78: added edi_product_endpoint (auto-install, depends on edi_product_oca + edi_endpoint_oca), dropped edi_endpoint_oca from edi_product_oca's deps, and moved the origin_edi_endpoint_id view inheritance into the glue. Registered in the metapackage.