“It worked on my database.”
Every Odoo developer has said it. I almost said it about an approval flow I was building, long before it reached a single real user.
The flow was straightforward: quotes above a certain discount needed a manager’s approval before they could be confirmed. Logged in as myself, it was flawless. Then I tested it the way a salesperson would actually use it, and it fell apart.
The code wasn’t the real problem. My assumptions were. Here are two I’ve stopped making.
Assumption 1: “If it works for me, it works for them”
I had tested everything as an administrator. Administrators see everything and can do almost anything, so of course it worked.
When I logged in as a test salesperson with normal access rights, the approval step tried to read a record that the user wasn’t allowed to see, and Odoo did exactly what it should: it blocked them. Then I set the database up with two companies, the way the business is organized, and a manager approving for one company couldn’t see quotes from the other.
The tricky part is that Odoo’s security is layered. Access rights decide which kinds of records a user can touch, and record rules decide which specific records they can see. An administrator skips most of that, which is exactly why admin testing feels so reassuring and proves so little.
Odoo security layers · salesperson vs administrator
Now I test every flow as each user who will run it: a salesperson, a manager, someone in each company. Odoo makes it easy to switch users, and ten minutes of testing that way shows what hours of admin testing hide.
Assumption 2: “Test data is real enough”
Once access was fixed, I ran into the next problem: with more data in the database, opening the quotes list became painfully slow.
My first test database had only a few dozen quotes. When I loaded a much larger set of test data, closer to what a real business builds up over the years, the cracks showed. A field I had added to show each quote’s approval status was being recalculated for every record, every time the list loaded. With 40 quotes, I never noticed. With thousands, it was impossible to miss.
The fix was simple once I saw it: store the status on the quote and update it only when the quote actually changes, instead of recalculating it every time someone looks. The list went back to opening instantly.
Small vs Realistic Test Data
Now I test with data at a realistic size, not just a handful of demo records. Some problems simply don’t exist until the data is big enough to reveal them.
The two assumptions at a glance
- “If it works for me, it works for them.” What testing revealed: as a salesperson, the flow hit access errors, and managers couldn’t see the other company’s quotes. What I do now: test every flow as each real user role, in each company.
- “Test data is real enough.” What testing revealed: the quotes list slowed down once I loaded a realistic amount of test data. What I do now: test with data at a realistic size, not just demo records.
The same lesson shows up everywhere I work
Access rights and data volume aren’t the only places this happens. Across my Odoo work in POS, CRM, cooperatives and websites, I keep seeing the same pattern: something that works in a quick setup needs another look before it’s ready for real conditions.
- POS: getting receipt printers and other hardware working with Odoo took more than switching on a setting. What helped: planning hardware as its own step, and testing on the actual devices before go-live.
- CRM: leads went to the wrong salesperson because the assignment rules didn’t match how the team really splits its work. What helped: checking the rules against realistic leads and how the team divides its customers.
- Cooperative: member shares and capital have to add up exactly, and small mistakes are hard to undo once members rely on the numbers. What helped: reconciling share totals against the source records before members see them.
Different modules, same lesson: the setup isn’t finished until it’s been tested against the real people, devices and data it’s built for.
What I do differently now
Testing as myself proves that a solution can work. Testing as each real role, with realistic data, shows whether it will. So now I test the people who will use it, with data as close to theirs as possible.
Odoo delivery process · before and after
The build and the go-live didn’t change at all. What changed is how I test before launch: who I test as, and what data I test with.
The approval flow now works for every role, in both companies, with a realistic amount of data, and it hasn’t met a single real user yet. That’s exactly when I want to find problems like these.
If you’re planning an Odoo rollout, or living with one that doesn’t quite fit how your team works, I’d be happy to talk it through.
What’s your “it worked on my database” story? I’d love to hear it in the comments.
It Worked on My Database: Two Odoo Assumptions I No Longer Make