rule: _sql_constraints is ignored from Odoo 19

odoo.sql-constraints-are-ignored-from-19, from OpenSPP 208d9758 (#394):
a _sql_constraints block on a 19.0 module, which Odoo 19 logs once and
never creates, so duplicates were saved silently. An AST pass over the
file plus the manifest's series, legacy_sql_constraints_on_19. Reported
on 19+; silent on 16 to 18, where it is the only spelling; silent when a
walked tree pins no series (odoo core, 174 files); advisory per finding
when nothing was walked at all.

Fires nowhere at HEAD on the three trees, as expected: OpenSPP had
migrated, OCA and core are 18.0. OpenSPP's history holds the evidence:
it catches all four fixed instances (three in ca44b5e3, one in 208d9758)
on the files before their fix and none after, and nexa check reports the
#394 file at the line the fix removed. Graded defect: on 19 the attribute
does nothing, so every finding is a constraint that does not exist.

Also corrects "models.Constraint arrived in Odoo 17": 18.0 core has none
and the 18.0 ORM reference has no Constraints section; the 19.0 one does.
The rule cites it. First rule declaring odoo_versions >=19.0, which
exercises the context layer's per-rule series check; tests pin it.

Retrieval, index rebuilt: 28/28 at TOP_K 6, 26/28 in the top 3.
Corpus 28 rules. 277 of 277 true positives still reported.
ARCHITECTURE 3.62.

ARCHITECTURE.md

@@ -3065,6 +3065,56 @@ with it: it was a comparison, the one shape that did not survive, and a checker
 its own wrong sample. The composed-in Python rules gain nothing and lose nothing in their
 classification: the verdicts are unchanged, only which of them are still reported.
 
+### 3.62 `_sql_constraints` is ignored from Odoo 19
+
+**Measured 2026-09-26.** The rule an incident asked for, and the first new rule since the
+corpus reached 27. OpenSPP's 208d9758 (#394) found `spp.cr.type.reason.document` declaring
+its `(cr_type_id, reason)` uniqueness in `_sql_constraints` on a 19.0 module. Odoo 19 logs
+one warning at load and creates nothing, so duplicate rules were saved from 19.0.3.0.0
+until the fix, and the fix added a lint of its own because nothing in CI had caught it.
+`odoo.sql-constraints-are-ignored-from-19` is an AST pass over the file plus the manifest's
+series, `legacy_sql_constraints_on_19`.
+
+**A version claim was wrong on the way in.** §3.45 and the `prefer-sql-constraint` rule said
+`models.Constraint` arrived in Odoo 17. Odoo 18.0 core at 3c3e3b3 has no `models.Constraint`
+anywhere and declares `_sql_constraints` in 174 files; the 18.0 ORM reference has no
+"Constraints and indexes" section and the 19.0 one does, declaring `Constraint`, `Index` and
+`UniqueIndex` and never naming `_sql_constraints`. So up to 18 the attribute is the only
+spelling, and from 19 it does nothing. The rule text, both correct samples that said "Odoo 16
+only", and the checker docstring that repeated it now say 16 to 18. §3.45 is left as it was
+written; this is its correction.
+
+**Which series decides everything, and there are three answers.** 19 or later: reported, at
+the assignment. 16 to 18: silent, because a finding would be advice that cannot be taken.
+Unknown: silent when a tree was walked and simply does not pin a series, which is odoo core,
+whose manifests carry versions like "1.0" and would otherwise yield 174 findings, every one
+wrong. Reported as advisory, `unproven` on the finding itself, when nothing was walked at
+all, because "nobody looked" and "looked and it does not say" are different answers, and
+silence on the first would hide the rule from a bare snippet and from `validate`'s own samples.
+It is the first rule to declare `odoo_versions` other than `>=16.0`, and that exercised the
+context layer's per-rule check for the first time: grounding a 17.0 module with it is now a
+finding, which is what that check was written to say. A test pins both sides.
+
+On the trees it fires nowhere, and that is the expected answer rather than a missing one.
+OpenSPP at the pinned commit already contains the fix and has 72 files of `models.Constraint`;
+OCA's 20 `_sql_constraints` are all in 18.0 modules; core is 18.0. So the evidence is
+OpenSPP's history. Five blocks were written on 19. Three were fixed together by `ca44b5e3`,
+*"migrate _sql_constraints to models.Constraint (Odoo 19)"*, one is #394, and one went with a
+reverted feature rather than a fix. The checker fires on all four fixed ones as the files stood
+before their fix and on none after, and `nexa check --no-model` on the #394 file inside its
+19.0 module reports it as high impact, likelihood defect, at the line the fix removed.
+
+It is graded **defect** on that, which is more than `noupdate` got for one incident in §3.55,
+and the difference is the construct rather than the count. A heuristic can be wrong about
+intent. This cannot: on 19 the attribute does nothing, so every finding is a constraint that
+does not exist. The one way to be wrong is a series misread, and that is why the unknown
+series is handled the way it is.
+
+Its probe, *"after upgrading to Odoo 19 my unique constraint is not enforced and duplicates
+are saved"*, brings it back inside the top 3. Re-measured 2026-09-27 with the index rebuilt:
+all 28 rules retrievable at `TOP_K` 6, and 26 of 28 in the top 3, where it had been 25 of 27.
+The two that miss at 3 are `commit-inside-a-loop` and `eval-and-pickle`, not this one.
+
 ## 4. Performance traps, all found by measurement
 
 Within four instrumented runs the report showed the 7B at ~10 tok/s against a
@@ -3136,12 +3186,12 @@ in a corpus; it does not close the reasoning gap.
 
 ### Checking is partial, and the layers say where
 
-- 1 of 27 rules has no automated check at all. It returns **no verdict**, never a
+- 1 of <!--fig:corpus.rules-->28<!--/fig--> rules has no automated check at all. It returns **no verdict**, never a
   false pass, and `nexa coverage` prints the reason.
 - <!--fig:corpus.by_pattern-->9<!--/fig--> of the
-  <!--fig:corpus.checkable-->26<!--/fig--> checked rules are decided by a **regex over
+  <!--fig:corpus.checkable-->27<!--/fig--> checked rules are decided by a **regex over
   generated code**. That catches textual signatures, not meaning. Code wrong in a way
-  no pattern describes passes silently. The other <!--fig:corpus.by_ast-->17<!--/fig-->
+  no pattern describes passes silently. The other <!--fig:corpus.by_ast-->18<!--/fig-->
   are decided by an AST pass (§3.12, §3.47, §3.54). The regexes
   no longer see docstrings, which are emptied before matching; they still see every
   other string literal, so a violation quoted inside a triple-quoted SQL string or a
@@ -3299,13 +3349,14 @@ unawares.
 
 ### Corpus provenance
 
-25 of 27 rules cite upstream documentation. The rest rest on general knowledge and
+<!--fig:corpus.sourced-->26<!--/fig--> of <!--fig:corpus.rules-->28<!--/fig--> rules cite upstream documentation. The rest rest on general knowledge and
 deserve more scepticism. Most of the rules were written by an assistant rather than
 harvested from production incidents, and rules drawn from real incidents are worth
-more. Three now are: `commit-inside-a-loop` and `sql-needs-query-parameters` came
+more. Four now are: `commit-inside-a-loop` and `sql-needs-query-parameters` came
 from an external ruleset disagreeing with this one (3.34), and
-`depends-must-not-name-unread-fields` from a fix commit in OpenSPP's history (3.35).
-Three of twenty-seven is not a change of method yet.
+`depends-must-not-name-unread-fields` from a fix commit in OpenSPP's history (3.35), and
+`sql-constraints-are-ignored-from-19` from an OpenSPP incident (3.62). Four of
+twenty-eight is not a change of method yet.
 
 This is the deepest unresolved problem in the design and no layer addresses it: the
 validator and the thing being validated are the same class of system. Provenance
@@ -3317,7 +3368,7 @@ tracks sources, versions and checker identities. It cannot establish that a rule
 Odoo, and nothing else (§3.46). Odoo rules were checked against 18.0 documentation and
 its source; behaviour differs across major versions.
 
-One stack, 27 rules: 19 about the ORM and 8 about the Python language, which apply
+One stack, <!--fig:corpus.rules-->28<!--/fig--> rules: 20 about the ORM and 8 about the Python language, which apply
 because an Odoo module is a Python module. Both halves carry field evidence from two
 ecosystems and a hand classification of every finding, and they are **not the same
 quality** — <!--fig:cls.openspp.precision-->85<!--/fig-->% on the two flagship ORM

README.md

@@ -135,7 +135,7 @@ publishing a classification.
 
 ## What it is not
 
-**Not a general linter.** 27 rules. It will not replace `pylint-odoo`, and after the
+**Not a general linter.** <!--fig:corpus.rules-->28<!--/fig--> rules. It will not replace `pylint-odoo`, and after the
 wrapper above it does not have to.
 
 **Not a bug finder.** Against real Odoo bugfixes the corpus catches
@@ -427,7 +427,7 @@ the same command.
 It prints **no verdict**, because nothing generated an answer to have a verdict
 about. A clean run says *no pattern fired* in those words, and exits 1 if one did.
 
-**A `.py` or `.xml` file is reviewed against all 27 rules. Anything else is refused
+**A `.py` or `.xml` file is reviewed against all <!--fig:corpus.rules-->28<!--/fig--> rules. Anything else is refused
 by name.**
 
 ```
@@ -583,10 +583,10 @@ Same principle as `z.infer<typeof Schema>`: one definition, derived artifacts, n
 
 | | |
 |---|---|
-| Rules | <!--fig:corpus.rules-->27<!--/fig--> — 19 Odoo ORM, 8 plain-Python, one stack |
+| Rules | <!--fig:corpus.rules-->28<!--/fig--> — 19 Odoo ORM, 8 plain-Python, one stack |
 | Critical | <!--fig:corpus.critical-->12<!--/fig--> |
-| Machine-checkable | <!--fig:corpus.checkable-->26<!--/fig--> (<!--fig:corpus.checkable.pct-->96<!--/fig-->%): <!--fig:corpus.by_pattern-->9<!--/fig--> by pattern, <!--fig:corpus.by_ast-->17<!--/fig--> by AST |
-| Traceable to upstream docs | <!--fig:corpus.sourced-->25<!--/fig--> (<!--fig:corpus.sourced.pct-->93<!--/fig-->%), each audited for topic fit |
+| Machine-checkable | <!--fig:corpus.checkable-->27<!--/fig--> (<!--fig:corpus.checkable.pct-->96<!--/fig-->%): <!--fig:corpus.by_pattern-->9<!--/fig--> by pattern, <!--fig:corpus.by_ast-->18<!--/fig--> by AST |
+| Traceable to upstream docs | <!--fig:corpus.sourced-->26<!--/fig--> (<!--fig:corpus.sourced.pct-->93<!--/fig-->%), each audited for topic fit |
 | Pattern false positives | 0 cross-hits across the corpus |
 | Recall under meaning-preserving rewrite | 79/79 |
 | Satisfied patterns bypassable by a comment | 0 of <!--fig:corpus.satisfied_patterns-->1<!--/fig--> |
@@ -609,7 +609,7 @@ Same principle as `z.infer<typeof Schema>`: one definition, derived artifacts, n
 | `nexa check` verdict stability | 4 of 5 files on one run, 3 of 5 on the next |
 | `nexa check --no-model` | 0.26s, identical output every run |
 
-26 of 27 rules carry an automated check. The one that does not —
+<!--fig:corpus.checkable-->27<!--/fig--> of <!--fig:corpus.rules-->28<!--/fig--> rules carry an automated check. The one that does not —
 `schema-change-needs-migration`, whose violation lives in the diff between two module
 versions — returns **no verdict** rather than a false pass, and `nexa coverage` names
 it and says why.
@@ -1253,11 +1253,12 @@ nexa eval --retrieval
 asks each rule its own probe and reports whether it comes back. No generation, so it
 needs only the embedding model and finishes in seconds.
 
-All 27 are retrievable at the operating `TOP_K` of 6, and 25 of them rank in the top
-3. That number got harder rather than easier when the corpus became one stack: with
-19 rules competing, `prefer-sql-constraint` came back first for *"stop anyone entering
-a negative quantity on a sale order line"*; with 27 it stopped coming back at all,
-because that is the generic validation question every constraint rule here answers.
+All 28 are retrievable at the operating `TOP_K` of 6, and 26 of them rank in the top
+3, re-measured on 2026-09-27 with the `_sql_constraints` rule added. That number got
+harder rather than easier when the corpus became one stack: with 19 rules competing,
+`prefer-sql-constraint` came back first for *"stop anyone entering a negative quantity
+on a sale order line"*; with 27 it stopped coming back at all, because that is the
+generic validation question every constraint rule here answers.
 Reworded to the question only it answers — *"should this check be a database
 constraint or an api.constrains method"* — and measured again. It is the third rule to
 fail this way, and all three failed identically: correctly worded, in the vocabulary of

bin/layers.py

@@ -1083,9 +1083,10 @@ def _version_applies(declared, series):
     comparators combine with AND, the rest with OR, and a series passes if it
     satisfies every bound or matches any alternative.
 
-    Nothing in the corpus exercises this yet -- all 19 versioned rules declare
-    the single clause '>=16.0'. It is settled here so the first bounded range
-    somebody writes means what they meant by it.
+    Every versioned rule declared the single clause '>=16.0' until
+    odoo.sql-constraints-are-ignored-from-19, which declares '>=19.0' because
+    18.0 has no models.Constraint. It is settled here so the first bounded
+    range somebody writes means what they meant by it.
     """
     try:
         target = float(series)

bin/semantics.py

@@ -648,11 +648,12 @@ def _owner_of(tree, fn):
 def _columns_already_constrained(tree, series=None):
     """{class node id: column names a SQL constraint on that class already covers}
 
-    Two spellings, and only one of them still works everywhere.
-    `_code_unique = models.Constraint("UNIQUE(code)", msg)` arrived in Odoo 17.
-    `_sql_constraints = [(name, "UNIQUE(code)", msg)]` is the classic one and is
-    IGNORED from 19: the registry logs a warning at load and the constraint is
-    never created.
+    Two spellings, and neither works everywhere.
+    `_code_unique = models.Constraint("UNIQUE(code)", msg)` is the 19 one: odoo
+    18.0 core has no models.Constraint at all and declares _sql_constraints in
+    174 files. `_sql_constraints = [(name, "UNIQUE(code)", msg)]` is the classic
+    one and is IGNORED from 19: the registry logs a warning at load and the
+    constraint is never created.
 
     So on a module that pins 19 or later, a _sql_constraints block is not a
     column being spoken for -- it is a column that nobody is watching and
@@ -694,6 +695,75 @@ def _assigns_name(statement, name):
     return any(isinstance(t, ast.Name) and t.id == name for t in statement.targets)
 
 
+def legacy_sql_constraints_on_19(code, facts=None):
+    """odoo.sql-constraints-are-ignored-from-19
+
+    A class-body `_sql_constraints` assignment that Odoo 19 will not read. From
+    19 the registry logs one warning at load and creates nothing, so every
+    UNIQUE and CHECK in the block is a constraint nobody is enforcing and
+    everybody thinks somebody is.
+
+    The incident is OpenSPP's 208d9758 (#394): spp.cr.type.reason.document
+    declared (cr_type_id, reason) this way, duplicates were saved from
+    19.0.3.0.0, and the fix re-declared it as models.Constraint and added a
+    lint of its own because nothing in CI had caught it. The rest of that tree
+    had already moved, 72 files of models.Constraint to this one holdout.
+
+    Which series, three answers:
+
+      19 or later   reported.
+      16 to 18      silent. _sql_constraints is the ONLY spelling there --
+                    odoo 18.0 core declares it in 174 files and has no
+                    models.Constraint -- so a finding would be advice that
+                    cannot be taken. OCA's twenty are all 18.0.
+      unknown       silent when a tree was walked and does not pin a series,
+                    which is odoo core itself: its manifests carry versions
+                    like "1.0", and 174 findings there would all be wrong.
+                    Reported, advisory, when NOTHING was walked -- a bare
+                    snippet, validate's own samples -- because "nobody looked"
+                    and "looked and it does not say" are different answers,
+                    and silence on the first would hide the rule entirely.
+
+    An empty list declares nothing and is not reported.
+    """
+    facts = facts or {}
+    series = facts.get("odoo_series")
+    if _series_at_least(series, 19.0):
+        grade = None
+    elif series is None and not facts.get("walked"):
+        grade = UNPROVEN
+    else:
+        return []
+    tree, _ = parse_python(code)
+    if tree is None:
+        return []
+    findings = []
+    for cls in ast.walk(tree):
+        if not isinstance(cls, ast.ClassDef):
+            continue
+        for statement in cls.body:
+            if isinstance(statement, ast.Assign):
+                targets, value = statement.targets, statement.value
+            elif isinstance(statement, ast.AnnAssign) and statement.value is not None:
+                targets, value = [statement.target], statement.value
+            else:
+                continue
+            if not any(isinstance(t, ast.Name) and t.id == "_sql_constraints"
+                       for t in targets):
+                continue
+            if isinstance(value, (ast.List, ast.Tuple)) and not value.elts:
+                continue
+            findings.append((
+                statement.lineno,
+                "{0} declares _sql_constraints, which Odoo 19 ignores{1}: the "
+                "registry logs a warning and creates no constraint, so nothing "
+                "enforces it -- declare each one as models.Constraint".format(
+                    cls.name, "" if grade is None else
+                    " (the series is unknown here; this holds from 19)"),
+                grade))
+    return findings
+
+
 def _series_at_least(series, floor):
     """Is this module pinned to `floor` or later? False when nothing said."""
     try:
@@ -3392,6 +3462,7 @@ CHECKS = {
     "parent_can_form_a_cycle": parent_can_form_a_cycle,
     "editable_record_without_noupdate": editable_record_without_noupdate,
     "naive_time_leaves_or_dates_a_day": naive_time_leaves_or_dates_a_day,
+    "legacy_sql_constraints_on_19": legacy_sql_constraints_on_19,
 }
 
 
@@ -3408,6 +3479,9 @@ CONTEXT_CHECKS = frozenset([
     # Reads odoo_series: whether a _sql_constraints block is a constraint at
     # all depends on which Odoo is going to load it.
     "prefer_sql_constraint_applies",
+    # Reads odoo_series, and whether a tree was walked at all: whether a
+    # _sql_constraints block exists in the database depends on the series.
+    "legacy_sql_constraints_on_19",
 ])
 
 # Checkers that can meet input they cannot decide about -- a decorator whose

corpus/build_corpus.py

@@ -56,7 +56,7 @@ def _onchange_qty(self):
         raise ValidationError('Quantity must be positive')""",
  "correct": """_qty_positive = models.Constraint("CHECK(qty > 0)", "Quantity must be positive.")
 
-# Odoo 16 only. From 19 this attribute is ignored and creates nothing:
+# Odoo 16 to 18 only. From 19 this attribute is ignored and creates nothing:
 # _sql_constraints = [('qty_positive', 'CHECK(qty > 0)', 'Quantity must be positive.')]""",
  "tags": ["onchange", "constraints", "bypass"],
  # onchange is allowed as UX garnish, but only alongside a real enforcement
@@ -167,7 +167,7 @@ def _check_deadline(self):
  "odoo_versions": ">=16.0",
  "severity": "high",
  "title": "Prefer a database constraint when the rule fits in SQL",
- "rule": "If a rule is expressible as UNIQUE or CHECK over columns of one table, declare it as models.Constraint rather than @api.constrains. models.Constraint arrived in Odoo 17 and is the only spelling that still works at 19: the legacy _sql_constraints attribute is ignored there, the registry logs a warning at load time, and the constraint is silently never created. On 16, _sql_constraints is the spelling. A bound on one column is the common case: a quantity that must not be negative, a price or discount that must be positive, a percentage confined to 0-100, a minimum or maximum on any numeric field. A comparison between two columns of the same row also fits, with one caveat: PostgreSQL treats a CHECK as satisfied when its expression is NULL, so CHECK(date_end >= date_start) enforces nothing while either date is empty.",
+ "rule": "If a rule is expressible as UNIQUE or CHECK over columns of one table, declare it as models.Constraint rather than @api.constrains. models.Constraint is the only spelling that works at 19: the legacy _sql_constraints attribute is ignored there, the registry logs a warning at load time, and the constraint is silently never created. On 16 to 18, _sql_constraints is the only spelling: 18.0 has no models.Constraint. A bound on one column is the common case: a quantity that must not be negative, a price or discount that must be positive, a percentage confined to 0-100, a minimum or maximum on any numeric field. A comparison between two columns of the same row also fits, with one caveat: PostgreSQL treats a CHECK as satisfied when its expression is NULL, so CHECK(date_end >= date_start) enforces nothing while either date is empty.",
  "why": "A database constraint cannot be bypassed by any client, ORM path, raw SQL, or a future module writing with sudo -- but only if it exists. A _sql_constraints block on Odoo 19 creates nothing and warns in a log nobody reads, which is the same failure as the Python check it replaced, wearing the word constraint. A Python search_count uniqueness check also races under concurrency and lets duplicates through. A sign or range check written as @api.constrains is not wrong, but it is enforced one layer too high: the same CHECK in the schema holds for every writer, forever, including the ones written after you leave.",
  "enforcement_layer": "database",
  "bypassed_by": [],
@@ -178,12 +178,35 @@ def _check_unique_code(self):
             raise ValidationError('Code must be unique')""",
  "correct": """_code_uniq = models.Constraint("UNIQUE(code)", "Code must be unique.")
 
-# Odoo 16 only. From 19 this attribute is ignored and creates nothing:
+# Odoo 16 to 18 only. From 19 this attribute is ignored and creates nothing:
 # _sql_constraints = [('code_uniq', 'UNIQUE(code)', 'Code must be unique.')]""",
  "tags": ["sql-constraints", "uniqueness", "race-condition", "check-constraint",
           "bounds", "range", "negative-value", "positive-value", "quantity",
           "minimum", "maximum"],
 },
+{
+ "id": "odoo.sql-constraints-are-ignored-from-19",
+ "odoo_versions": ">=19.0",
+ "odoo_versions_basis": "Measured on the trees, not read off a page. Odoo 18.0 core (3c3e3b3) declares _sql_constraints in 174 files and has no models.Constraint anywhere, so the attribute is the only spelling up to 18. OpenSPP on 19.0 declares models.Constraint in 72 files, and its 208d9758 (#394) records that 19 logs a warning and creates nothing for _sql_constraints. The ORM reference agrees: the 19.0 page declares Constraint, Index and UniqueIndex under 'Constraints and indexes' and never names _sql_constraints, and the 18.0 page has no such section. The corpus is checked against 18.0; this is the one rule whose subject starts after it.",
+ "severity": "high",
+ "title": "_sql_constraints is ignored from Odoo 19",
+ "rule": "On a module for Odoo 19 or later, declare every UNIQUE and CHECK as a models.Constraint class attribute. A _sql_constraints list is not read at 19: the registry logs one warning at load and creates nothing. When moving one over, remove the duplicates already stored first, because a constraint that fails to apply during an upgrade is downgraded to a schema warning and stays missing.",
+ "why": "The constraint everybody reads in the class does not exist in the database, so the duplicates or out-of-range values it was written to refuse are saved without a word. The only trace is a warning in a log at every registry load. OpenSPP shipped exactly this on spp.cr.type.reason.document from 19.0.3.0.0, duplicate rules accumulated, and nothing in CI caught it.",
+ "enforcement_layer": "database",
+ "bypassed_by": [],
+ "wrong": """class ReasonDocument(models.Model):
+    _name = 'spp.cr.type.reason.document'
+
+    _sql_constraints = [
+        ('reason_uniq', 'UNIQUE(cr_type_id, reason)', 'One rule per reason.'),
+    ]""",
+ "correct": """class ReasonDocument(models.Model):
+    _name = 'spp.cr.type.reason.document'
+
+    _reason_uniq = models.Constraint('UNIQUE(cr_type_id, reason)', 'One rule per reason.')""",
+ "tags": ["sql-constraints", "migration", "odoo-19", "uniqueness", "check-constraint",
+          "silent-failure"],
+},
 {
  "id": "odoo.check-constraint-cannot-cross-tables",
  "odoo_versions": ">=16.0",
@@ -613,6 +636,11 @@ def revoke(consent_id: str):
 # ignore is worse than no checker.
 
 ODOO_ORM = "https://www.odoo.com/documentation/18.0/developer/reference/backend/orm.html"
+# The one rule whose subject starts after the series the corpus is checked
+# against. The 19.0 page has a "Constraints and indexes" section declaring
+# Constraint, Index and UniqueIndex and never names _sql_constraints; the 18.0
+# page has no such section.
+ODOO_ORM_19 = "https://www.odoo.com/documentation/19.0/developer/reference/backend/orm.html"
 ODOO_DATA = "https://www.odoo.com/documentation/18.0/developer/reference/backend/data.html"
 ODOO_SECURITY = "https://www.odoo.com/documentation/18.0/developer/reference/backend/security.html"
 ODOO_EXTERNAL_API = "https://www.odoo.com/documentation/18.0/developer/reference/external_api.html"
@@ -710,6 +738,15 @@ ENRICH = {
         "semantic_check": "prefer_sql_constraint_applies",
         "source": ODOO_CONSTRAINTS,
     },
+    "odoo.sql-constraints-are-ignored-from-19": {
+        # From an incident, not from the harvest: OpenSPP 208d9758 (#394)
+        # shipped a _sql_constraints block on 19, duplicates accumulated, and
+        # the fix added a lint of its own because nothing had caught it. The
+        # question is one file plus the manifest's series, so it is an AST
+        # pass reading odoo_series; see semantics.legacy_sql_constraints_on_19.
+        "semantic_check": "legacy_sql_constraints_on_19",
+        "source": ODOO_ORM_19,
+    },
     "odoo.check-constraint-cannot-cross-tables": {
         "violation_pattern": r"CHECK\s*\([^)]*(?:SELECT|[a-z_]+_id\.[a-z_]+)",
         "source": PG_CREATE_TABLE,
@@ -1024,6 +1061,17 @@ LIKELIHOOD = {
     # was 3 of 33 and 0 of 15.
     "python.naive-and-aware-datetimes-do-not-compare": "defect",
 
+    # Nothing live on the three trees -- OpenSPP had migrated, OCA and core
+    # are 18.0 -- but OpenSPP's history holds every instance there was: five
+    # blocks written on 19, three fixed together by ca44b5e3 ("migrate
+    # _sql_constraints to models.Constraint"), one by 208d9758 (#394), one
+    # gone with a reverted feature. The checker fires on all four fixed ones
+    # as they were before the fix and on none after. And it cannot be wrong
+    # the way a heuristic can: on 19 the attribute does nothing, so every
+    # finding is a constraint that does not exist. A finding made without a
+    # known series carries `unproven` on its own and gates nothing (3.62).
+    "odoo.sql-constraints-are-ignored-from-19": "defect",
+
     # 1 on-target of 14, 3 in the right method describing something else, and
     # one commit caught. The same shape as ondelete's grade and a touch better
     # aimed: the rule recognises a company-crossing relation and is about the
@@ -1109,6 +1157,8 @@ PROBES = {
     # here is about a race.
     "odoo.prefer-sql-constraint":
         "should this check be a database constraint or an api.constrains method",
+    "odoo.sql-constraints-are-ignored-from-19":
+        "after upgrading to Odoo 19 my unique constraint is not enforced and duplicates are saved",
     "odoo.check-constraint-cannot-cross-tables":
         "my CHECK constraint will not install because it reads the product stock",
     "odoo.check-company-on-relations":

corpus/corpus_meta.json

@@ -1,12 +1,12 @@
 {
-  "built_utc": "2026-09-26T21:51:05.417360+00:00",
-  "rules": 27,
-  "machine_checkable": 26,
+  "built_utc": "2026-09-27T11:31:01.417630+00:00",
+  "rules": 28,
+  "machine_checkable": 27,
   "by_pattern": 9,
-  "by_semantic_check": 17,
+  "by_semantic_check": 18,
   "checked_against": {
     "odoo": "18.0",
     "python": "3.12"
   },
-  "corpus_sha256": "7a181b2b08454212bf80b533e5b5d5a7c1c229b9dac4e4a47b48a315fc7194bc"
+  "corpus_sha256": "3ccc62bb28e3c26eaa15e272668fae5b24d6c0465d2a7e19733109815a32edb3"
 }

corpus/rules/odoo.json

@@ -17,7 +17,7 @@
       "raw SQL"
     ],
     "wrong": "@api.onchange('qty')\ndef _onchange_qty(self):\n    if self.qty <= 0:\n        raise ValidationError('Quantity must be positive')",
-    "correct": "_qty_positive = models.Constraint(\"CHECK(qty > 0)\", \"Quantity must be positive.\")\n\n# Odoo 16 only. From 19 this attribute is ignored and creates nothing:\n# _sql_constraints = [('qty_positive', 'CHECK(qty > 0)', 'Quantity must be positive.')]",
+    "correct": "_qty_positive = models.Constraint(\"CHECK(qty > 0)\", \"Quantity must be positive.\")\n\n# Odoo 16 to 18 only. From 19 this attribute is ignored and creates nothing:\n# _sql_constraints = [('qty_positive', 'CHECK(qty > 0)', 'Quantity must be positive.')]",
     "tags": [
       "onchange",
       "constraints",
@@ -133,12 +133,12 @@
     "odoo_versions": ">=16.0",
     "severity": "high",
     "title": "Prefer a database constraint when the rule fits in SQL",
-    "rule": "If a rule is expressible as UNIQUE or CHECK over columns of one table, declare it as models.Constraint rather than @api.constrains. models.Constraint arrived in Odoo 17 and is the only spelling that still works at 19: the legacy _sql_constraints attribute is ignored there, the registry logs a warning at load time, and the constraint is silently never created. On 16, _sql_constraints is the spelling. A bound on one column is the common case: a quantity that must not be negative, a price or discount that must be positive, a percentage confined to 0-100, a minimum or maximum on any numeric field. A comparison between two columns of the same row also fits, with one caveat: PostgreSQL treats a CHECK as satisfied when its expression is NULL, so CHECK(date_end >= date_start) enforces nothing while either date is empty.",
+    "rule": "If a rule is expressible as UNIQUE or CHECK over columns of one table, declare it as models.Constraint rather than @api.constrains. models.Constraint is the only spelling that works at 19: the legacy _sql_constraints attribute is ignored there, the registry logs a warning at load time, and the constraint is silently never created. On 16 to 18, _sql_constraints is the only spelling: 18.0 has no models.Constraint. A bound on one column is the common case: a quantity that must not be negative, a price or discount that must be positive, a percentage confined to 0-100, a minimum or maximum on any numeric field. A comparison between two columns of the same row also fits, with one caveat: PostgreSQL treats a CHECK as satisfied when its expression is NULL, so CHECK(date_end >= date_start) enforces nothing while either date is empty.",
     "why": "A database constraint cannot be bypassed by any client, ORM path, raw SQL, or a future module writing with sudo -- but only if it exists. A _sql_constraints block on Odoo 19 creates nothing and warns in a log nobody reads, which is the same failure as the Python check it replaced, wearing the word constraint. A Python search_count uniqueness check also races under concurrency and lets duplicates through. A sign or range check written as @api.constrains is not wrong, but it is enforced one layer too high: the same CHECK in the schema holds for every writer, forever, including the ones written after you leave.",
     "enforcement_layer": "database",
     "bypassed_by": [],
     "wrong": "@api.constrains('code')\ndef _check_unique_code(self):\n    for rec in self:\n        if self.search_count([('code', '=', rec.code), ('id', '!=', rec.id)]):\n            raise ValidationError('Code must be unique')",
-    "correct": "_code_uniq = models.Constraint(\"UNIQUE(code)\", \"Code must be unique.\")\n\n# Odoo 16 only. From 19 this attribute is ignored and creates nothing:\n# _sql_constraints = [('code_uniq', 'UNIQUE(code)', 'Code must be unique.')]",
+    "correct": "_code_uniq = models.Constraint(\"UNIQUE(code)\", \"Code must be unique.\")\n\n# Odoo 16 to 18 only. From 19 this attribute is ignored and creates nothing:\n# _sql_constraints = [('code_uniq', 'UNIQUE(code)', 'Code must be unique.')]",
     "tags": [
       "sql-constraints",
       "uniqueness",
@@ -159,6 +159,33 @@
     "advisory": true,
     "probe": "should this check be a database constraint or an api.constrains method"
   },
+  {
+    "id": "odoo.sql-constraints-are-ignored-from-19",
+    "odoo_versions": ">=19.0",
+    "odoo_versions_basis": "Measured on the trees, not read off a page. Odoo 18.0 core (3c3e3b3) declares _sql_constraints in 174 files and has no models.Constraint anywhere, so the attribute is the only spelling up to 18. OpenSPP on 19.0 declares models.Constraint in 72 files, and its 208d9758 (#394) records that 19 logs a warning and creates nothing for _sql_constraints. The ORM reference agrees: the 19.0 page declares Constraint, Index and UniqueIndex under 'Constraints and indexes' and never names _sql_constraints, and the 18.0 page has no such section. The corpus is checked against 18.0; this is the one rule whose subject starts after it.",
+    "severity": "high",
+    "title": "_sql_constraints is ignored from Odoo 19",
+    "rule": "On a module for Odoo 19 or later, declare every UNIQUE and CHECK as a models.Constraint class attribute. A _sql_constraints list is not read at 19: the registry logs one warning at load and creates nothing. When moving one over, remove the duplicates already stored first, because a constraint that fails to apply during an upgrade is downgraded to a schema warning and stays missing.",
+    "why": "The constraint everybody reads in the class does not exist in the database, so the duplicates or out-of-range values it was written to refuse are saved without a word. The only trace is a warning in a log at every registry load. OpenSPP shipped exactly this on spp.cr.type.reason.document from 19.0.3.0.0, duplicate rules accumulated, and nothing in CI caught it.",
+    "enforcement_layer": "database",
+    "bypassed_by": [],
+    "wrong": "class ReasonDocument(models.Model):\n    _name = 'spp.cr.type.reason.document'\n\n    _sql_constraints = [\n        ('reason_uniq', 'UNIQUE(cr_type_id, reason)', 'One rule per reason.'),\n    ]",
+    "correct": "class ReasonDocument(models.Model):\n    _name = 'spp.cr.type.reason.document'\n\n    _reason_uniq = models.Constraint('UNIQUE(cr_type_id, reason)', 'One rule per reason.')",
+    "tags": [
+      "sql-constraints",
+      "migration",
+      "odoo-19",
+      "uniqueness",
+      "check-constraint",
+      "silent-failure"
+    ],
+    "stack": "odoo",
+    "semantic_check": "legacy_sql_constraints_on_19",
+    "source": "https://www.odoo.com/documentation/19.0/developer/reference/backend/orm.html",
+    "likelihood": "defect",
+    "advisory": false,
+    "probe": "after upgrading to Odoo 19 my unique constraint is not enforced and duplicates are saved"
+  },
   {
     "id": "odoo.check-constraint-cannot-cross-tables",
     "odoo_versions": ">=16.0",

fieldtest-oca-2026-09.json

@@ -1,5 +1,5 @@
 {
-  "generated_utc": "2026-09-26T21:44:44+00:00",
+  "generated_utc": "2026-09-26T21:57:36+00:00",
   "stack": "odoo",
   "roots": [
     "server-tools",
@@ -13,7 +13,7 @@
   "lines": 33960,
   "xml_files": 223,
   "xml_lines": 12853,
-  "checkers": 26,
+  "checkers": 27,
   "triggers": {
     "files": 879,
     "models_declared": 139,

fieldtest-odoo-core-2026-09.json

@@ -1,5 +1,5 @@
 {
-  "generated_utc": "2026-09-26T21:50:13+00:00",
+  "generated_utc": "2026-09-26T22:02:53+00:00",
   "stack": "odoo",
   "roots": [
     "odoo"
@@ -11,7 +11,7 @@
   "lines": 559663,
   "xml_files": 3119,
   "xml_lines": 322608,
-  "checkers": 26,
+  "checkers": 27,
   "triggers": {
     "files": 10252,
     "models_declared": 1269,

fieldtest-openspp-2026-09.json

@@ -1,5 +1,5 @@
 {
-  "generated_utc": "2026-09-26T21:46:57+00:00",
+  "generated_utc": "2026-09-26T21:59:50+00:00",
   "stack": "odoo",
   "roots": [
     "OpenSPP2-19.0"
@@ -11,7 +11,7 @@
   "lines": 226937,
   "xml_files": 793,
   "xml_lines": 118020,
-  "checkers": 26,
+  "checkers": 27,
   "triggers": {
     "files": 2265,
     "models_declared": 492,

modelfiles/gen-odoo.Modelfile

@@ -103,7 +103,7 @@ garnish on top of the real rule. Agreeing here ships bad data to production.
   Correct:
     _qty_positive = models.Constraint("CHECK(qty > 0)", "Quantity must be positive.")
     
-    # Odoo 16 only. From 19 this attribute is ignored and creates nothing:
+    # Odoo 16 to 18 only. From 19 this attribute is ignored and creates nothing:
     # _sql_constraints = [('qty_positive', 'CHECK(qty > 0)', 'Quantity must be positive.')]
 
 [odoo.schema-change-needs-migration] (critical) Schema changes need a migration script
@@ -290,7 +290,7 @@ garnish on top of the real rule. Agreeing here ships bad data to production.
             rec.label = rec.order_id.name
 
 [odoo.prefer-sql-constraint] (high) Prefer a database constraint when the rule fits in SQL
-  Rule: If a rule is expressible as UNIQUE or CHECK over columns of one table, declare it as models.Constraint rather than @api.constrains. models.Constraint arrived in Odoo 17 and is the only spelling that still works at 19: the legacy _sql_constraints attribute is ignored there, the registry logs a warning at load time, and the constraint is silently never created. On 16, _sql_constraints is the spelling. A bound on one column is the common case: a quantity that must not be negative, a price or discount that must be positive, a percentage confined to 0-100, a minimum or maximum on any numeric field. A comparison between two columns of the same row also fits, with one caveat: PostgreSQL treats a CHECK as satisfied when its expression is NULL, so CHECK(date_end >= date_start) enforces nothing while either date is empty.
+  Rule: If a rule is expressible as UNIQUE or CHECK over columns of one table, declare it as models.Constraint rather than @api.constrains. models.Constraint is the only spelling that works at 19: the legacy _sql_constraints attribute is ignored there, the registry logs a warning at load time, and the constraint is silently never created. On 16 to 18, _sql_constraints is the only spelling: 18.0 has no models.Constraint. A bound on one column is the common case: a quantity that must not be negative, a price or discount that must be positive, a percentage confined to 0-100, a minimum or maximum on any numeric field. A comparison between two columns of the same row also fits, with one caveat: PostgreSQL treats a CHECK as satisfied when its expression is NULL, so CHECK(date_end >= date_start) enforces nothing while either date is empty.
   Why: A database constraint cannot be bypassed by any client, ORM path, raw SQL, or a future module writing with sudo -- but only if it exists. A _sql_constraints block on Odoo 19 creates nothing and warns in a log nobody reads, which is the same failure as the Python check it replaced, wearing the word constraint. A Python search_count uniqueness check also races under concurrency and lets duplicates through. A sign or range check written as @api.constrains is not wrong, but it is enforced one layer too high: the same CHECK in the schema holds for every writer, forever, including the ones written after you leave.
   Wrong:
     @api.constrains('code')
@@ -301,7 +301,7 @@ garnish on top of the real rule. Agreeing here ships bad data to production.
   Correct:
     _code_uniq = models.Constraint("UNIQUE(code)", "Code must be unique.")
     
-    # Odoo 16 only. From 19 this attribute is ignored and creates nothing:
+    # Odoo 16 to 18 only. From 19 this attribute is ignored and creates nothing:
     # _sql_constraints = [('code_uniq', 'UNIQUE(code)', 'Code must be unique.')]
 
 [odoo.recursion-check-on-hierarchy] (high) parent_id hierarchies need a recursion check
@@ -317,6 +317,22 @@ garnish on top of the real rule. Agreeing here ships bad data to production.
         if self._has_cycle():
             raise ValidationError('You cannot create recursive hierarchies.')
 
+[odoo.sql-constraints-are-ignored-from-19] (high) _sql_constraints is ignored from Odoo 19
+  Rule: On a module for Odoo 19 or later, declare every UNIQUE and CHECK as a models.Constraint class attribute. A _sql_constraints list is not read at 19: the registry logs one warning at load and creates nothing. When moving one over, remove the duplicates already stored first, because a constraint that fails to apply during an upgrade is downgraded to a schema warning and stays missing.
+  Why: The constraint everybody reads in the class does not exist in the database, so the duplicates or out-of-range values it was written to refuse are saved without a word. The only trace is a warning in a log at every registry load. OpenSPP shipped exactly this on spp.cr.type.reason.document from 19.0.3.0.0, duplicate rules accumulated, and nothing in CI caught it.
+  Wrong:
+    class ReasonDocument(models.Model):
+        _name = 'spp.cr.type.reason.document'
+    
+        _sql_constraints = [
+            ('reason_uniq', 'UNIQUE(cr_type_id, reason)', 'One rule per reason.'),
+        ]
+  Correct:
+    class ReasonDocument(models.Model):
+        _name = 'spp.cr.type.reason.document'
+    
+        _reason_uniq = models.Constraint('UNIQUE(cr_type_id, reason)', 'One rule per reason.')
+
 [python.bare-except-catches-the-exit] (high) A bare except swallows Ctrl-C and sys.exit too
   Rule: Catch the exceptions you can actually handle. Never write a bare except, and use except Exception only at a boundary that logs and re-raises.
   Why: A bare except catches KeyboardInterrupt and SystemExit as well, so Ctrl-C stops working and sys.exit() is ignored. It also hides a typo exactly as readily as the error it was written for, and the failure then surfaces much later as wrong data rather than as a traceback pointing at its cause.
@@ -410,13 +426,25 @@ garnish on top of the real rule. Agreeing here ships bad data to production.
   Rule: Inside the ORM, datetimes are naive UTC: Odoo pins the server process to UTC, so datetime.now() and fields.Datetime.now() are the same value, and an aware datetime written to a Datetime field raises ValueError. The defects are at the edges. A timestamp leaving the system -- an API response, a token, a file for another system -- carries its offset: datetime.now(timezone.utc). A value parsed with an offset is converted to naive UTC before it meets the ORM or a naive value. And a date meant as a user's or company's calendar day comes from fields.Date.context_today, not the server's UTC date.
   Why: Comparing a naive datetime with an aware one raises TypeError, so the two meet for the first time in whichever branch is exercised least -- usually expiry, usually in production. A naive timestamp handed to another system cannot say which zone it is in. And the server's date is UTC's date: for a company ahead of UTC, anything dated 'today' in its early hours is dated yesterday, which at month end is the previous period.
   Wrong:
-    if expires_at < datetime.datetime.now():
-        raise ValueError('token expired')
+    from datetime import datetime
+    from fastapi import APIRouter
+    
+    router = APIRouter()
+    
+    
+    @router.delete("/consent/{consent_id}")
+    def revoke(consent_id: str):
+        return {"consent_id": consent_id, "revoked_at": datetime.utcnow().isoformat()}
   Correct:
     from datetime import datetime, timezone
+    from fastapi import APIRouter
+    
+    router = APIRouter()
+    
     
-    if expires_at < datetime.now(timezone.utc):
-        raise ValueError('token expired')
+    @router.delete("/consent/{consent_id}")
+    def revoke(consent_id: str):
+        return {"consent_id": consent_id, "revoked_at": datetime.now(timezone.utc).isoformat()}
 
 
 === HOW TO ANSWER ===

tests/test_layers.py

@@ -131,13 +131,27 @@ def test_context_mismatched_series_is_a_gap_and_not_a_finding(odoo_rules):
     rules carries an odoo_versions field, so the blanket warning was standing in
     for per-rule data that does not exist yet.
     """
-    result = layers.layer_context(odoo_rules, _ctx(odoo_series="17.0",
-                                                   manifest="__manifest__.py"))
+    applying = [r for r in odoo_rules
+                if layers._version_applies(r.get("odoo_versions") or ">=16.0", "17.0")]
+    result = layers.layer_context(applying, _ctx(odoo_series="17.0",
+                                                 manifest="__manifest__.py"))
     assert result.findings == []
     assert any("17.0" in why and "18.0" in why for _, why in result.not_checked)
     # And it is not UNKNOWN either, because every rule now declares the series it
     # holds for, so there is a question here this layer can actually answer.
     assert result.verdict == layers.PASS
+
+
+def test_a_retrieved_rule_for_a_later_series_is_a_finding(odoo_rules):
+    """The per-rule check, exercised by a real rule for the first time: the
+    _sql_constraints rule holds from 19, and grounding a 17.0 module with it
+    would tell the model to use a spelling 17.0 does not have."""
+    later = [r for r in odoo_rules if r["id"] == "odoo.sql-constraints-are-ignored-from-19"]
+    result = layers.layer_context(later, _ctx(odoo_series="17.0",
+                                              manifest="__manifest__.py"))
+    assert [f.rule for f in result.findings] == ["odoo.sql-constraints-are-ignored-from-19"]
+    assert layers.layer_context(later, _ctx(odoo_series="19.0",
+                                            manifest="__manifest__.py")).findings == []
     assert any("odoo_versions" in c for c in result.checked)
 
 

tests/test_semantics.py

@@ -1659,3 +1659,48 @@ def test_datetime_reports_the_two_shapes_that_survived(why, body):
 ])
 def test_datetime_leaves_the_shapes_that_did_not(why, body):
     assert semantics.run_check("naive_time_leaves_or_dates_a_day", body) == [], why
+
+
+_LEGACY = ("from odoo import models\n\n\n"
+           "class ReasonDocument(models.Model):\n"
+           "    _name = 'spp.cr.type.reason.document'\n\n"
+           "    _sql_constraints = [\n"
+           "        ('reason_uniq', 'UNIQUE(cr_type_id, reason)', 'One rule per reason.'),\n"
+           "    ]\n")
+
+
+def test_sql_constraints_on_19_are_a_constraint_that_does_not_exist():
+    """OpenSPP's 208d9758: the block sat on a 19.0 module and created nothing."""
+    found = semantics.run_check("legacy_sql_constraints_on_19", _LEGACY,
+                                facts={"walked": True, "odoo_series": "19.0"})
+    assert [(line, grade) for line, _, grade in found] == [(7, None)]
+
+
+def test_sql_constraints_before_19_are_the_only_spelling():
+    """18.0 core declares the attribute in 174 files and has no
+    models.Constraint, so a finding there is advice that cannot be taken."""
+    for series in ("16.0", "17.0", "18.0"):
+        assert semantics.run_check("legacy_sql_constraints_on_19", _LEGACY,
+                                   facts={"walked": True, "odoo_series": series}) == []
+
+
+def test_sql_constraints_series_unknown_after_a_walk_is_silent():
+    """odoo core's own manifests pin no series; 174 findings there would all
+    be wrong."""
+    assert semantics.run_check("legacy_sql_constraints_on_19", _LEGACY,
+                               facts={"walked": True, "odoo_series": None}) == []
+
+
+def test_sql_constraints_with_nothing_walked_is_advisory():
+    """Nobody looked is not the same answer as looked and it does not say."""
+    found = semantics.run_check("legacy_sql_constraints_on_19", _LEGACY)
+    assert [grade for _, _, grade in found] == [semantics.UNPROVEN]
+
+
+def test_an_empty_sql_constraints_list_declares_nothing():
+    body = ("from odoo import models\n\n\n"
+            "class Thing(models.Model):\n"
+            "    _name = 'my.thing'\n"
+            "    _sql_constraints = []\n")
+    assert semantics.run_check("legacy_sql_constraints_on_19", body,
+                               facts={"walked": True, "odoo_series": "19.0"}) == []