Odoo to Power BI: the permission problem nobody mentions
TechnoVision
Publication date pending · 6 min read
Every Odoo-to-BI connector on the market works the same way: an API key belonging to an administrator, a set of tables, and a scheduled refresh. It works immediately, which is exactly why nobody examines it.
Then a sales manager builds a dashboard, publishes it, and it contains margin data they were never able to see in Odoo. Nobody did anything wrong. The connector read as an administrator, because that is the only account it had.
A dataset is a copy
This is the bit that makes BI different from a report screen. A refreshed dataset is a copy of your data, sitting in a different system, with a different sharing model and a different set of administrators.
Everything the connector pulls is now governed by Power BI’s permissions, not Odoo’s. If the pull was over-broad, no amount of care inside Power BI puts the data back.
The permission decision is made once, at the moment of extraction. Everything after that is damage control.
Bind the credential to a person
The fix is the same as everywhere else: the credential belongs to one user, and every row is read with that user’s access rights. A dataset refreshed with the sales manager’s token holds the sales manager’s rows.
Two people connecting their own credentials to the same table can legitimately get different data. That surprises people, and it is correct. It is also the only version that can be explained to an auditor in one sentence.
Where the credential goes
| Approach | Verdict |
|---|---|
| Key in the query string | No. A URL ends up in browser history, proxy logs, and the dataset settings screen where anybody with access to the workspace can read it. |
| HTTP Basic | Yes. It is what Power BI’s OData connector offers and what its scheduled refresh can store, and the password box does not leak into logs. |
| OAuth against your IdP | Better in a large estate, and considerably more to set up. Worth it when you already have the identity provider wired into everything else. |
Send it over HTTPS or not at all
Speak OData, not JSON
Power BI has an OData connector built in. Point it at a service document and you get a table picker, typed columns and paging without anybody writing Power Query. Return convenient JSON instead and every analyst who touches it writes their own transformation, differently.
Typed matters more than it sounds. Real EDM types mean dates arrive as dates and numbers as numbers; a feed that returns everything as text produces a dashboard where somebody has cast a column wrongly and nobody has noticed.
One more thing worth doing
Publish your saved reports rather than raw tables. A report already says which model, which filter, which columns and in what order - which is exactly what a BI table needs, and it means the dashboard and the Monday morning email cannot disagree about what "overdue" means.