NationwideLegal.

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. Geverifieerd met het account van een verkoper.

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 loopt via de authenticatielaag: SMTP-authenticatie aan en het verzendaccount ingesteld, zodat elk transactioneel bericht vanuit het CRM vertrekt.

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 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 werkt met één eenvoudige regel: scope en prioriteit worden afgesproken voordat iets op de lijst komt, en Polargate levert het wekelijkse referentiedocument.