NationwideLegal.

The context

The client is NationwideLegal in the United States. Its commercial operation runs on a CRM: opportunities, the firms they belong to, the contacts inside each firm and the addresses behind them. Polargate built that CRM on Odoo 18 Enterprise and has held its technical direction since.

Everything custom lives in a single module. It depends on nothing beyond Community modules, so no third party addon sits in the critical path. The module adds five new models, each with its complete access rights file and no gaps, and extends the native models for opportunities, contacts, activities and stages.

The delivery chain is deliberately boring: a private repository, a managed Odoo project, and NationwideLegal production pointing at the same environment. The platform runs the test suite on every development and staging build. Promotion to production is never automatic, a person triggers it by hand. From merge to the live version in production takes ten to fifteen minutes.

Permissions built around how the team actually sells

The access model was rebuilt around how the sales team really works, with four separate per-user controls instead of one monolithic role. A user can be granted one and not the others, which is what a sales floor needs and what a single role cannot express.

The calendar

Sales users see their own activities. The administrator sees and manages all of them. Getting there was not a record rule. In Odoo, reading activities is not governed by record rules, because that model carries its own native search and access check, so it had to be solved another way. It was verified with the account of a sales user.

Creating users without being an administrator

Odoo has no intermediate role that can create users without being an administrator. We verified that in a local environment: the only native group with the permission escalates itself to administrator in a single write. So we built our own group, with its own access control list and a barrier inside the model. It cannot leave anyone holding administrator groups, it cannot modify a user who already is one, and it cannot write another user password. Verified in the browser with an account that holds nothing but that permission.

Data entry that matches the tool the team came from

Company, address and contact go in on a single page, the way it worked in the tool the team used before. Duplicate detection runs on an indexed normalised name that ignores punctuation and legal suffixes, warns, and offers to attach the record to the one that already exists instead of creating a second. The suffix list needed pruning: some of the words in it were collapsing two genuinely different firms into one.

Transactional email

Mail goes out through the authentication layer: SMTP authentication enabled and the sending account configured, so every transactional message leaves from the CRM.

Upgrades that can be undone

We did not take the risk classification of a migration on trust, we rehearsed it in a container, reproducibly. The finding: when a field is removed from the model, the platform does not drop the table or the columns, it leaves them orphaned with the data still inside. Seeded rows survived the upgrade and the rollback returned both the code and the access to the data, 132 rows and 56 relations across 200 records. The migration is reversible, and it is reversible because it was tested, not because the documentation says so.

Verification against production, after every deploy

There is a written recipe and it runs after every deploy. Read the live version of the module. Check the view against the combined definition, not the inherited one. Confirm the new fields exist. Time reading them over real records: 400 opportunities came back in 313 ms, which is the check that no loop and no heavy query slipped in. Download the assets bundle and validate it, because a broken bundle is invisible until a user opens the page. The discipline is hard and simple: in production you look, you do not touch.

Audits work the same way. The first phase is running the scenario against a real environment, impersonating the affected user, recording the state before and after every write. Validating a permission with an administrator account proves nothing, because the bypass exempts it. A test that only asserts the text of an attribute proves nothing either. One of these audits ran across 41 agents and 2.3 million tokens, with two independent skeptics challenging every finding before it was accepted.

Continued technology direction

Fifteen deliverables were completed in five weeks and consolidated into a handover document. The module went from no tests of its own to 99 green, with the negative cases verified too, because a permission test that passes when it should fail is worse than no test at all.

The engagement runs on a simple rule: scope and priority are agreed before an item goes on the list, and Polargate issues the weekly reference document.