Het CRM van NationwideLegal, op Odoo 18

De context

De klant is NationwideLegal. De commerciële operatie draait op een CRM: verkoopkansen, de firma's waar ze bij horen, de contactpersonen binnen elke firma en de adressen daarachter. Polargate bouwde dat CRM op Odoo 18 Enterprise en voert sindsdien de technische regie.

Alles wat op maat is gemaakt, zit in één eigen module. Die is nergens van afhankelijk buiten Community-modules, dus er staat geen addon van derden in het kritieke pad. De module voegt vijf nieuwe modellen toe, elk met een volledig rechtenbestand zonder gaten, en breidt de standaardmodellen voor verkoopkansen, contactpersonen, activiteiten en fasen uit.

De deliveryketen is bewust saai: een private repository, een beheerd Odoo-project en de productieomgeving van de klant die naar diezelfde omgeving wijst. Het platform draait de testsuite bij elke development- en staging-build. Naar productie gaat het nooit vanzelf, een mens zet die stap met de hand. Van merge tot de live versie in productie duurt tien tot vijftien minuten.

Rechten gebouwd rond hoe het team echt verkoopt

We hebben het rechtenmodel opnieuw opgebouwd rond de manier waarop de verkopers echt werken, met vier losse instellingen per gebruiker in plaats van één monolithische rol. Een gebruiker kan de ene wel krijgen en de andere niet, en dat is precies wat een verkoopteam nodig heeft en wat één rol niet kan uitdrukken.

De agenda

Elke verkoper ziet de eigen activiteiten, de beheerder ziet en beheert ze allemaal. Daar kwamen we niet met een recordregel. In Odoo wordt het lezen van activiteiten niet door recordregels bepaald, omdat dat model een eigen native zoek- en toegangscontrole meebrengt, dus het moest anders. De eerste versie leunde op een contextvlag en lekte. Toen de klant het meldde, hebben we het meteen hersteld en opnieuw getest met het account van de betrokken gebruiker.

Gebruikers aanmaken zonder beheerder te zijn

Odoo kent standaard geen tussenrol die gebruikers kan aanmaken zonder beheerder te zijn. Dat hebben we in een lokale omgeving geverifieerd: de enige standaardgroep met dat recht tilt zichzelf in één schrijfactie op tot beheerder. Daarom bouwden we een eigen groep, met een eigen toegangslijst en een barrière in het model zelf. Die kan niemand met beheerdersgroepen achterlaten, kan een gebruiker die dat al is niet wijzigen en kan het wachtwoord van een ander niet schrijven. Geverifieerd in de browser met een account dat alleen dat recht heeft.

Invoer die lijkt op het gereedschap waar het team vandaan kwam

Bedrijf, adres en contactpersoon gaan er op één pagina in, zoals in de tool die het team eerder gebruikte. De duplicaatdetectie draait op een genormaliseerde, geïndexeerde naam die leestekens en juridische achtervoegsels negeert: hij waarschuwt en biedt aan het record aan het bestaande te koppelen in plaats van een tweede aan te maken. De lijst met achtervoegsels moest gesnoeid worden, want een paar woorden erin trokken twee echt verschillende firma's samen tot één.

Transactionele e-mail

De e-mail faalde, en niet in het ERP maar in de authenticatielaag. Met SMTP-authenticatie aan en het juiste account ingesteld was de fout weg.

Upgrades die je ongedaan kunt maken

We namen de risico-inschatting van een migratie niet op gezag aan, we repeteerden hem reproduceerbaar in een container. De bevinding: als een veld uit het model verdwijnt, verwijdert het platform de tabel en de kolommen niet, het laat ze verweesd achter met de data er nog in. De geplante rijen overleefden de upgrade en de rollback gaf zowel de code als de toegang tot de data terug, 132 rijen en 56 relaties over 200 records. De migratie is omkeerbaar, en dat is ze omdat het getest is, niet omdat de documentatie het zegt.

Verificatie tegen productie, na elke deploy

Er is een geschreven recept en het draait na elke deploy. Lees de live versie van de module. Controleer de weergave tegen de gecombineerde definitie, niet tegen de overerving. Bevestig dat de nieuwe velden bestaan. Klok het lezen ervan over echte records: 400 verkoopkansen kwamen terug in 313 ms, en dat is de controle dat er geen lus en geen zware query is binnengeslopen. Download de assetsbundel en valideer die, want een kapotte bundel zie je pas als een gebruiker de pagina opent. De discipline is hard en simpel: in productie kijk je, je raakt niets aan.

Audits werken net zo. De eerste fase is geen code lezen, maar het scenario draaien tegen een echte omgeving in de huid van de betrokken gebruiker, met de staat voor en na elke schrijfactie erbij. Een recht valideren met een beheerdersaccount bewijst niets, want de bypass stelt dat account vrij. Een test die alleen de tekst van een attribuut controleert bewijst evenmin iets. Eén van die audits liep over 41 agenten en 2,3 miljoen tokens, met twee onafhankelijke sceptici die elke bevinding aanvochten voordat die meetelde.

Doorlopende technische regie

Vijftien deliverables afgerond in vijf weken, samengebracht in een overdrachtsdocument. De module ging van geen eigen tests naar 99 groene, met ook de negatieve gevallen geverifieerd, want een rechtentest die slaagt terwijl hij zou moeten falen is erger dan geen test.

De samenwerking rust op één regel die haar gezond houdt: scope en prioriteit worden afgesproken voordat iets op de lijst komt, niet erna, en het wekelijkse referentiedocument komt van Polargate.