[18.0][IMP] edi_core_oca: add listener action

[ArnauCForgeFlow]

Move _trigger_edi_event_make_name method to edi_core_oca module in order to make the listener usable without requiring the edi_component_oca module

[OCA-git-bot]

Hi @simahawk, @etobella,
some modules you are maintaining are being modified, check this out!

[ArnauCForgeFlow]

@simahawk Thanks for the review!

So, basically, your suggestion is moving the helper method _trigger_edi_event_make_name from the component module to the core, and then simply calling the _trigger_edi_event hook from the other modules?

[simahawk]

@simahawk Thanks for the review!

So, basically, your suggestion is moving the helper method _trigger_edi_event_make_name from the component module to the core, and then simply calling the _trigger_edi_event hook from the other modules?

yes. And we should move the hook to the consumer mixin so that the logic won't be put into generic models like exc record.

[ArnauCForgeFlow]

@simahawk Thanks for the review!
So, basically, your suggestion is moving the helper method _trigger_edi_event_make_name from the component module to the core, and then simply calling the _trigger_edi_event hook from the other modules?

yes. And we should move the hook to the consumer mixin so that the logic won't be put into generic models like exc record.

The problem with moving the hook to the consumer mixin is that for input exchanges that fail early, there is no record_id yet. For example, in edi_storage_oca, even if the process fails, we still need to execute the hook to move the file from 'pending' directory to 'error' directory. Any idea on how to handle this?

Thanks!

[simahawk]

@ArnauCForgeFlow good point. Well, that's why components have been used so far 😄

A possible approach is the one I took on endpoint_route_handler to check cross models that we wouldn't have any routing conflict. See https://github.com/OCA/web-api/blob/18.0/endpoint_route_handler/models/endpoint_route_handler.py#L90

We could collect all models inheriting from consumer mixin and trigger their handlers if any.
Something like that:

class EDIExchangeConsumerMixin(models.AbstractModel):
    _name = "edi.exchange.consumer.mixin"
    [...]

    @api.model
    def _get_edi_consumer_models(self):
        global EDI_CONSUMER_MODELS
        if EDI_CONSUMER_MODELS.get(self.env.cr.dbname):
            return EDI_CONSUMER_MODELS.get(self.env.cr.dbname)
        models = []
        for model in self.env.values():
            if (
                model._name != self._name
                and not model._abstract
                and self._name in model._inherit
            ):
                models.append(model._name)
        EDI_CONSUMER_MODELS[self.env.cr.dbname] = models
        return models

    def edi_trigger_consumer_models(self, trigger, records=None):
        """Trigger EDI config execution on all related models."""
        for model_name in self._get_edi_consumer_models():
            model = self.env[model_name]
            if hasattr(model, trigger):
                getattr(model, trigger)(records)

WDYT?

[simahawk]

Answering myself: this can lead to overlapping handlers as you could have the same hook for different exchanges.

Could we leverage edi.configuration then?
By default edi config are meant to work w/ the partners linked to a record/model and a trigger.
We could have a generic configuration that does not need a partner but only a trigger and a model.
This will leave the door opened for manual configuration and to place the final handler where you prefer.

[ArnauCForgeFlow]

Hi @simahawk Thanks for the suggestion! I've been looking into the edi.configuration approach, but to be honest, I'm a bit lost, so I'd love a bit more context on the implementation details.

• Which method should be the trigger? on_edi_exchange_done / on_edi_exchange_error, or _trigger_edi_event?
• In which model should I place the hooks? A custom one, edi.exchange.record, or edi.exchange.consumer.mixin?

Any quick example or guidance would be appreciated. Thanks!