Odoo upgrade error

res_partner_check_name: Contacts require a name

Last updated: November 2026

A partner without a name is about to become a contact. Most often it is an Odoo 16 private address that Odoo 17 turns into an ordinary contact.

This page is part of our guide on how to upgrade Odoo Community Edition. It explains what triggers the error, how to fix it by hand, and what an automated migration does about it.

The error

psycopg2.errors.CheckViolation: new row for relation "res_partner" violates check constraint "res_partner_check_name"

The DETAIL line shows the full row. When the ORM raises it instead of PostgreSQL, the message is "Contacts require a name".

Constraint
CHECK((type='contact' AND name IS NOT NULL) OR (type!='contact')), in every version from 15 to 20
Upgrade hops
Mostly 16→17
Seen when
A migration step changes the address type of partners to contact

When you see it

The constraint only applies to partners whose Address Type is Contact. Invoice, delivery and other addresses may have no name, and so could Private Address partners in Odoo 16. The error appears when a step of the upgrade sets the type of such a nameless partner to contact.

Root cause

Odoo 17 removed the Private Address type. Its Address Type selection only has Contact, Invoice Address, Delivery Address and Other Address, and the employee home address moved into fields on the employee. Every Odoo 16 partner of type private therefore has to become something else, and the usual choice (OpenUpgrade's and ours) is contact. A private address created without a name, which Odoo 16 allowed, then breaks the constraint as soon as its type changes.

The same happens with any custom script or module that switches nameless addresses to contacts.

How to fix it

Find the partners that would fail, before you start the upgrade:

SELECT id, type, email, parent_id, active
FROM res_partner
WHERE name IS NULL
  AND type IN ('contact', 'private');

Before you change anything: Back up the database before running any UPDATE or INSERT below, and try it on a copy first. These statements change data directly, outside the Odoo ORM.

Give each one a name. For employee home addresses the employee's name is the natural choice; otherwise use the email address, or a placeholder you can search for later:

-- Odoo 16: name home addresses after their employee
-- (the oldest employee wins when several share one address)
UPDATE res_partner p
SET name = e.name
FROM (SELECT DISTINCT ON (address_home_id) address_home_id, name
      FROM hr_employee
      WHERE address_home_id IS NOT NULL AND name IS NOT NULL
      ORDER BY address_home_id, id) e
WHERE e.address_home_id = p.id
  AND p.name IS NULL;

-- everything else: the part of the email before @, or a placeholder
UPDATE res_partner
SET name = COALESCE(NULLIF(split_part(email, '@', 1), ''), 'Private Address')
WHERE name IS NULL
  AND type IN ('contact', 'private');

Run the SELECT again; it should return nothing. Then restart the upgrade.

How OCU handles it

On the 16→17 step OCU names nameless private addresses before converting them to contacts: first with the name of the employee whose home address it is, then with the part of the email before the @, and otherwise with "Private Address". Unlike OpenUpgrade, OCU does not clear the street, phone, email or VAT of these partners. It also copies an employee's home address data into the employee's new private address fields in Odoo 17.

A free test migration shows whether your database runs into this or any other upgrade error before you change anything on your production server.

Frequently asked questions

Can I just delete the nameless partners?
Not safely. Private addresses are linked to employees, and other partners can be linked to invoices, orders or payments. Naming them keeps every reference intact.
Why does Odoo 16 allow a private address without a name?
The constraint only covers partners of type contact. In Odoo 16 a private address is a different type, so the database accepts it without a name. Odoo 17 drops that type, and the converted rows fall under the constraint.

Related

Find upgrade errors before your production run

Upload a backup and run a free test migration. You get the upgraded database, the full log and every warning, with no change to your live system.

Start your free test migration