[14.0][IMP] edi_oca: Add new model edi.configuration

[thienvh332]

Real life examples:

• [14.0] edi_sale_oca: use edi.configuration  #1067
• [14.0][ADD] edi_sale_ubl_oca #1024
• purchase soon

Specs

In edi_oca

Add generic edi.configuration model with these characteristics:

Fields

active
description: describe what the conf is for
backend_id
type_id

model: model the conf applies to

trigger_id: m2o field to make easier and more explicit the use of the conf for a specific event (eg: on_post_account_move, on_so_confirm, etc)
    default option: empty

snippet_before_do: validate the state, used to collect records todo
    can be used to do anything before the action that triggered it
  
    eval ctx:
        trigger = create/write/$name_of_the_event
        conf = current conf

    the snippet can return:
        todo = True/False
        snippet_do_vars = {}  # set of variables to pass over to the next snippet
        event_only
        tracked_fields
        edi_action
        .. in fact, any other variable that might be needed

snippet_do: used to do something specific here

    receives: operation, edi_action, vals, old_vals

This model can then be used by conf consumers.
Other methods:

edi_exec_snippet_before_do(self, record):
  exec before snippet, self=conf

edi_exec_snippet_do(self, record):
  exec snippet, self=conf

edi_get_conf(self, trigger, model_name=None, partners=None, backend=None):
  filter current recordset based on conditions

Backend / Exc. record

In `edi.backend._check_output_exchange_sync` move the loop on new_records to a new method `exchange_generate_send` whereas if the file has to be generated
2 jobs are chained (generate + send) if only send is needed, delay only one job.

Then add edi.exchange.record.action_exchange_generate_send and use that method from backend.
Consumer mixin

Specific fields for configuration (eg: edi_purchase_conf_ids) will be added by glue modules on res.partner.

Default conf

add generic conf for send_via_email

code: send_via_email
trigger: on_email_send
snippet: `record._edi_send_via_email()

add generic conf for send_via_edi

code: send_via_edi
trigger: none
snippet: `record._edi_send_via_edi(conf.type_id)

NOTE: sending emails is not really bound to edi
but in real life it's handy to have a default way to send EDI docs via email.
You could even generate an exchange record to keep track of that
but the choice will be up to the implementers.
The key is that w/ this features they can do whatever they want.

Views

add a specific menu item in edi settings to see all confs
make them searchable by model, active/inactive, partner, exc type, trigger

On edi_purchase_oca

add conf trigger on_button_confirm_purchase_order

add res.partner.edi_purchase_conf_ids
domain model=purchase.order, default_model=purchase.order, default_res_id=active_id

(document this approach in edi_oca readme section for edi.conf)

add generic conf for send_via_email_rfq

code: send_via_email_rfq
snippet: `record._edi_send_via_email(ir_action=record.action_rfq_send())

Example of specific listener implementation:

class EDIConfigPurchaseListener(Component):
    _name = "edi.config.consumer.listener.purchase.order"
    _inherit = "base.event.listener"

def on_button_confirm_purchase_order(self, record):
    trigger = "on_button_confirm_purchase_order"
    confs = record.edi_purchase_conf_ids.edi_get_conf(trigger)
    for conf in confs:
        conf.edi_exec_snippet_do(record)

EDIT: additional model edi.configuration.trigger to ease UI mgmt.

[OCA-git-bot]

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

[etobella]

More information would be awesome in order to understand why you did this.

[simahawk]

@etobella this origins from our discussion on OCA/edi-framework#39
@thienvh332 I'm adding the specs I gave you in the description feel free to adapt / add more things.
IMO we should split the purchase part when ready (let's say before switching from draft to real PR to ease the final review of both parts).

[simahawk]

@thienvh332 as it's draft, do you want us to wait for a review?

[nilshamerlinck]

hi @simahawk

• yes, please wait before reviewing, we need to finalize the internal review on our side
• now that you confirmed you want this in v14, we'll complete it asap

[thienvh332]

Hello @simahawk ,
This PR is ready for review. Could you please take a look at it?

[simahawk]

can you drop the pypdf fix? 15a994e

[thienvh332]

Hi @simahawk ,
I have updated the PR but I have 2 things I need your opinion on. Could you give me your views?

I don't get what's the need for this ... there's no action_send_email anywhere.

• We have a common config send_via_email. There we don't know what ir_action is used on each model. So I created it as a common path for other models. They can use _edi_send_via_email without passing ir_action parameter.
• Of course, if you feel it is inappropriate I will delete it.

type should be mandatory

• About type_id must be mandatory:
  • I'm confused about this. There is a requirement to create 2 common confs (send_via_email and send_via_edi). If type_id is required then we will:
    • Create data for edi_exchange_type and related models in edi_oca module.
    • Create those 2 common confs in another module to avoid creating unwanted data when installing the edi_oca module.

[simahawk]

Hi @simahawk , I have updated the PR but I have 2 things I need your opinion on. Could you give me your views?

I don't get what's the need for this ... there's no action_send_email anywhere.

* We have a common config **`send_via_email`**. There we don't know what **`ir_action`** is used on each model. So I created it as a common path for other models. They can use **`_edi_send_via_email`** without passing **`ir_action`** parameter.

* Of course, if you feel it is inappropriate I will delete it.

The idea is that everything should be explicit. You must explicitly declare which action you want to use.

type should be mandatory

* About **`type_id`** must be mandatory:
  
  * I'm confused about this. There is a requirement to create 2 common confs (**`send_via_email`** and **`send_via_edi`**). If **`type_id`** is required then we will:
    
    * Create data for **`edi_exchange_type`** and related models in **`edi_oca`** module.
    * Create those **`2 common confs`** in **`another module`** to avoid creating unwanted data when installing the **`edi_oca`** module.

Ok, you are right. Cannot be mandatory. Good point :)

[simahawk]

@etobella would you have time for a review?

[simahawk]

Here's a full real life example #1067
@thienvh332 pls have a look.

TODO here:

• drop the purchase part and move it to its own PR w/ adaptation based on the sale example

[simahawk]

@etobella would you have time for a review?

[simahawk]

@etobella good for you?

[simahawk]

/ocabot merge minor

[OCA-git-bot]

What a great day to merge this nice PR. Let's do it!
Prepared branch 14.0-ocabot-merge-pr-1035-by-simahawk-bump-minor, awaiting test results.

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

[OCA-git-bot]

Congratulations, your PR was merged at 28c6751. Thanks a lot for contributing to OCA. ❤️