Waarom Odoo debuggen anders voelt
Odoo-problemen zitten zelden op één plek. Een fout kan ontstaan uit Python-code, XML-views, access rights, record rules, server actions, automatische acties, contextwaarden, computed fields of data die historisch scheef staat.
Goed debuggen betekent daarom: eerst lokaliseren waar het probleem leeft, daarna pas code wijzigen.
Developer mode
Activeer developer mode om technische namen, view-structuur, velden, acties, menu-items en externe IDs zichtbaar te maken.
Gebruik dit om te weten welk model, welke view, welke action en welke context je voor je hebt.
Logs
Zoek naar de eerste relevante traceback, niet alleen naar de laatste regel. Let op AccessError, XML parse errors, psycopg2-fouten en externe API-timeouts.
Voeg functionele logging toe rond state transitions en connectoren, maar log nooit tokens of gevoelige data.
Odoo shell en breakpoints
Met Odoo shell test je domains, computed fields en modelmethodes gecontroleerd. Met breakpoints in PyCharm, pdb of debugpy volg je de echte flow.
Zet breakpoints gericht. Computed fields en write-methodes kunnen heel vaak geraakt worden.
Views en security
Controleer bij viewproblemen de gecompileerde view, niet alleen je eigen XML. Bij securityproblemen test je met de echte gebruiker en kijk je naar access rights én record rules.
Admin-tests bewijzen zelden dat de flow correct is voor eindgebruikers.
Praktische volgorde
- Reproduceer exact.
- Noteer model, record, gebruiker en actie.
- Lees logs.
- Controleer view/action/context.
- Test in shell.
- Zet pas daarna breakpoints of wijzig code.
Conclusie
Systematisch debuggen bespaart veel tijd. Odoo wordt begrijpbaar zodra je UI, ORM, security en data apart onderzoekt.