While developing a new module dependant on spreadsheet_oca I found there's no clean way to extend the spreadsheet Model that the editor builds, which forces other modules into fragile workarounds.
Describe the solution you'd like
When the editor opens, SpreadsheetRenderer.setup() builds the o-spreadsheet Model with a fixed configuration (spreadsheet_renderer.esm.js):
this.spreadsheet_model = new Model(
load(this.props.record.spreadsheet_raw),
{
custom: {env: this.env, orm: this.orm, odooDataProvider},
...
},
this.props.record.revisions
);
Everything is hardcoded and lives inside setup(), so there is no way for an extending module to hook into. I'd like the extension surface pulled out into small overridable methods that a module can override — most importantly a hook that feeds extra entries into custom (the object o-spreadsheet hands to every plugin's constructor), e.g.:
getExtraModelCustom() {
return {};
}
So we can do something like:
custom: {
env: this.env,
orm: this.orm,
odooDataProvider,
...this.getExtraModelCustom(),
},
With that in place, a module adds its data by simply patching getExtraModelCustom() — nothing else changes upstream.
Describe alternatives you've considered
- Patching the whole setup() / re-declaring the Model construction — I'd have to copy the entire config block into my patch and keep it in sync with every upstream change. Extremely brittle.
- Smuggling data through the env (patch the action to useSubEnv({...}), then read it back inside the plugin) — works, but it's an abuse of the env, indirect, and every consumer reinvents it.
Use case
A concrete, generic example of why this matters. Say a developer wants to add a custom button in the spreadsheet that triggers an Odoo action, e.g. a "Send to record" button whose plugin needs to know which record the spreadsheet belongs to and be able to call the ORM.
Right now, the plugin has no supported way to receive that record id, because custom is closed. So the developer patches the action to stash the id on the env, then reads it back in the plugin, in my opinion this is fragile plumbing just to pass one value.
While developing a new module dependant on spreadsheet_oca I found there's no clean way to extend the spreadsheet Model that the editor builds, which forces other modules into fragile workarounds.
Describe the solution you'd like
When the editor opens, SpreadsheetRenderer.setup() builds the o-spreadsheet Model with a fixed configuration (spreadsheet_renderer.esm.js):
Everything is hardcoded and lives inside setup(), so there is no way for an extending module to hook into. I'd like the extension surface pulled out into small overridable methods that a module can override — most importantly a hook that feeds extra entries into custom (the object o-spreadsheet hands to every plugin's constructor), e.g.:
So we can do something like:
With that in place, a module adds its data by simply patching getExtraModelCustom() — nothing else changes upstream.
Describe alternatives you've considered
Use case
A concrete, generic example of why this matters. Say a developer wants to add a custom button in the spreadsheet that triggers an Odoo action, e.g. a "Send to record" button whose plugin needs to know which record the spreadsheet belongs to and be able to call the ORM.
Right now, the plugin has no supported way to receive that record id, because custom is closed. So the developer patches the action to stash the id on the env, then reads it back in the plugin, in my opinion this is fragile plumbing just to pass one value.