[19.0] [IMP] edi_core_oca: scheduled edi.configuration triggers - #333
[19.0] [IMP] edi_core_oca: scheduled edi.configuration triggers#333ivantodorovich wants to merge 1 commit into
Conversation
ivantodorovich
changed the title
simahawk
left a comment
simahawk
left a comment
There was a problem hiding this comment.
Nice addition. Very handy to export batches or reports with a given cadence.
Can you please document it in CONFIGURE.md?
Questions:
- no idempotency: if someone runs the cron again, the configs will be executed again -> wouldn't be worth to mention it in an info box?
- despite there's no dependency addition I wonder if we want to host this feature in core. In particular I wonder if we shouldn't simply supply the cron method and leave implementers the freedom to create specific triggers and crons. All in all what makes it work is the trigger code, no matter what it is.
|
|
||
| self.edi_configuration._cron_run_by_trigger("on_cron_hourly") | ||
|
|
||
| self.assertEqual( |
There was a problem hiding this comment.
I would use RecordCapturer. Not a blocker.
|
Thanks @simahawk !
Sure thing, I'll update asap
An info box in the edi.configuration page?
Yes that's the idea, implementers have the freedom to create new triggers and crons, but I figured we can already supply an hourly and daily cron triggers to serve as implementation example whilst covering the most common usage |
1c59c76 to
90558e1
Compare
|
it's ready |
90558e1 to
15eef6d
Compare
Add on_cron_hourly and on_cron_daily triggers, fired by scheduled actions of the same period. They carry no originating record, so each configuration resolves its own targets: a global one runs once, any other runs against the records linked to it through a many2many on its model. That lookup is now shared with action_view_partners, which went through the relation tables directly and assumed every many2many linking res.partner to edi.configuration named its columns partner_id and conf_id.
15eef6d to
e0715cd
Compare
|
@simahawk changed again: crons and triggers are demo data only, not shipped directly |
3 participants
Add
on_cron_hourlyandon_cron_dailytriggers, fired by scheduled actions. They carry no originating record, so each configuration resolves its own targets: a global one runs once, any other runs against the records linked to it through a many2many on its model.