Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

edi_oca: exchange dependency #782

Closed
petrus-v opened this issue Jun 8, 2023 · 3 comments
Closed

edi_oca: exchange dependency #782

petrus-v opened this issue Jun 8, 2023 · 3 comments
Labels
enhancement stale PR/Issue without recent activity, it'll be soon closed automatically.

Comments

@petrus-v
Copy link
Contributor

petrus-v commented Jun 8, 2023

Is your feature request related to a problem?

Using edi_oca, I'd like to generate an exchange once one or multiple other are completely processed. For instance in an invoice followup I've to send invoice that depends on customer, payment would depends on customer too and reconcile would depends on both payment and invoice, We could get such DAG:


               Customer Exchange

                   /\
                  /  \
                 /    \
            
            Invoice   payment

                /\    /
               /  \  / 
              /    \/  
    
            PDF  reconcile

Describe the solution you'd like

I'd like the generate queue job task (the task that create data linked the exchange record) to wait until depends exchange are fully treat.

We could add a many 2 many dependent_exchange_ids on edi.exchange.record and raise RetryableJobError error before generating related data.

Describe alternatives you've considered

We probably could manage those dependencies using queue job framework but not sure how to properly manage them from edi_framework ?

An other way could probably to move job task in different chanels according the record type ?

I like the way to display record dependency in odoo and parent_id/reatated_exchanges_ids was to restrictive and is used to something slightly different as far I understood .

@simahawk do you any hint or ways you would like to handle such case ? Does it gives any values to share this in edi_oca module ?

@petrus-v
Copy link
Contributor Author

petrus-v commented Jun 24, 2023

as today before generating payload I'm calling a method such

    def _wait_related_exchange_to_be_sent_and_processed(self):
        if not all(
            self.exchange_record.dependent_exchange_ids.mapped(
                lambda rel_exch: rel_exch.edi_exchange_state
                == "output_sent_and_processed"
            )
        ):
            raise RetryableJobError(
                "Waiting related exchanges to be done before generate...",
            )

@simahawk
Copy link
Contributor

Hi @petrus-v ,

Regarding job dependencies between actions (eg: generate/send) I've recently drafted this #796

As for dependencies between exchanges, we could have a method that accepts a list of records and chains its jobs.
By default this could come from a field as you mentioned. The issue is: the fact that a job is done does not represent the fact that exchange is done. And what if you set the job as done manually? This will likely trigger the next job in the chain.
Hence, I think you cannot avoid checking the state of the former record in the chain in any case.

As of today, I think it's better to leverage events. You can already use them now.
When a record is successfully transitioned to another state you generate the next one. Easy and clear.

Another approach that I drafted is to automate exchange generation based on some rules.
It depends on #797 and OCA/edi-framework#4.
In my case, for instance, I'm able to generate an order response as an ack to the original exchange record that created a SO when the order gets confirmed.
In your case, you can handle what happens on the invoice and on its related record.

Another point is - and this is something I wanted to do since a long time - we should reflect the state of last related job on the exchange record.

Copy link

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.

@github-actions github-actions bot added the stale PR/Issue without recent activity, it'll be soon closed automatically. label May 12, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement stale PR/Issue without recent activity, it'll be soon closed automatically.
Projects
None yet
Development

No branches or pull requests

2 participants