[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!

[simahawk]

All starts with notify_action_complete. This must be called all the times an "official" action is done.
In turns, it calls _trigger_edi_event, which should take care of what we are discussing now.

There we should trigger the event an all related records and all consumer models.
The trigger on related records partly implemented is since the split https://github.com/OCA/edi-framework/blob/18.0/edi_core_oca/models/edi_exchange_record.py#L525 but it's incomplete as _trigger_edi_event does nothing ATM.

Hence, for related records, we should do what is done already for state change, create and write https://github.com/OCA/edi-framework/blob/18.0/edi_core_oca/models/edi_exchange_consumer_mixin.py#L449
There's it's easier because the lookup of edi.config is done already via _edi_config_field_relation (eg:

edi-framework/edi_sale_oca/models/sale_order.py

Line 16 in b7ca2bc

return self.partner_id.edi_sale_conf_ids

).

When we don't have a record, we have to decide how to lookup for edi.confg. Today we always rely on a m2m relation via partner (we have a m2m relation to be able to reuse configs). We should probably state which configs are meant to run globally for a given model (eg: w/ a flag global or non_record_related, whatever).

I hope it's clear. Otherwise we can organize a call 😉