[19.0] [IMP] edi_core_oca: scheduled edi.configuration triggers - #333
ivantodorovich 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.
|
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 |
SilvioC2C
left a comment
SilvioC2C
left a comment
There was a problem hiding this comment.
One minor doubt, else LGTM!
| """ | ||
| self.ensure_one() | ||
| return model.search( | ||
| Domain.OR( |
There was a problem hiding this comment.
@ivantodorovich getting back to this in the scope of backporting to v18: do we really need to use Domain?
There was a problem hiding this comment.
I wouldn't do any different in 19.0+, as Domain is the best idiomatic way to define them
But no, in previous versions it can be expressions.OR with list-defined domains
There was a problem hiding this comment.
My point is that this domain is very simple and I doubt there's anything to be optimized and we could make this compatible w/ both versions and ease back/fwd porting.
We could have:
try:
from odoo.fields import Domain
OR = Domain.OR
except ImportError:
from odoo.osv import expression
OR = expression.OR
[...]
OR([fname, "in", self.ids])
WDYT?
There was a problem hiding this comment.
I'd say version-specific code lives in the version-specific branch
I wouldn't be afraid of a backport/forwardport that requires a code change
5 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.