Het verschil in één zin
Computed fields berekenen waarden, onchange-methodes helpen de gebruiker tijdens invoer, constraints bewaken de geldigheid van data. Wie die drie door elkaar haalt, krijgt bugs die moeilijk te vinden zijn.
Computed fields: afgeleide waarheid
Gebruik computed fields wanneer een waarde logisch afgeleid wordt uit andere data: marge, totaalgewicht, resterend saldo, statusindicatoren. Met store=True wordt de waarde opgeslagen en doorzoekbaar, maar dan moet je dependencies correct definiëren met @api.depends.
Een computed field mag geen verborgen workflowmotor worden. Als de berekening bijwerkingen heeft zoals records aanmaken of statussen wijzigen, hoort die logica meestal ergens anders.
Onchange: comfort in het formulier
@api.onchange draait in de gebruikersinterface wanneer iemand een veld wijzigt. Het is ideaal om standaardwaarden voor te stellen, waarschuwingen te tonen of velden tijdelijk aan te passen vóór bewaren.
Maar onchange is geen beveiliging en geen databescherming. Imports, RPC-calls en batchprocessen volgen dezelfde UI-flow niet noodzakelijk. Alles wat altijd waar moet zijn, hoort niet alleen in onchange.
Constraints: de laatste verdedigingslijn
Constraints bewaken regels die nooit geschonden mogen worden: een einddatum na een startdatum, een uniek extern referentienummer, een verplicht veld in een bepaalde state.
Gebruik @api.constrains voor businessregels en SQL constraints voor eenvoudige, harde databasegaranties zoals unieke combinaties. Denk wel na over foutmeldingen: een goede validatiefout vertelt de gebruiker wat fout is en hoe hij het oplost.
Een herkenbaar voorbeeld
Stel: een servicecontract heeft een startdatum, einddatum en duur in maanden. De duur kan computed zijn. Een onchange kan bij startdatum + duur automatisch een einddatum voorstellen. Een constraint moet verhinderen dat einddatum vóór startdatum ligt.
Zo krijgt de gebruiker hulp, maar blijft de data ook correct wanneer ze via import of API binnenkomt.
Veelgemaakte fouten
- Businessregels uitsluitend in onchange plaatsen.
- Computed fields gebruiken voor acties met side effects.
- store=True gebruiken zonder volledige @api.depends.
- Constraints vergeten bij imports en integraties.
- Te generieke foutmeldingen zoals “Invalid value”.
Conclusie
De juiste keuze maakt Odoo voorspelbaar. Onchange verbetert de invoerervaring, computed fields houden afgeleide waarden consistent, en constraints beschermen de waarheid van je systeem.