Name: [FIX] ai17: Vietnamese catalogues, the locale regressions they caused, and the defects that surfaced

State: Killed

PR State: merged

PR Author: David Tran

PR Author Email:

PR: #103

Committer: David Tran

Committer Email: davidtran.hp@gmail.com

Commit: 7c79fdb1687d0cd9389fa69ae082f44a9c9673e6

Description:

                                            [FIX] viin_ai_approval: the AI advisory survives an upgrade on all three bridges

This PR fixed install-only wiring for the nine Brain sidebar carriers and left
the same defect standing in the three approval bridges. Half a class is worse
than none - it reads as cleaned up.

It was not theoretical. On a database built from this source, all three account
approval types carried NO wiring at all, so the AI risk advisory was silently not
installed on any of them, and no upgrade could repair it.

The root cause is measurable, not inferred. viin_ai_approval_account finished
installing at 11:02:21.228; the three account types were created at 11:02:27.327,
the instant the chart of accounts landed - because the upstream generator skips a
company with no chart_template. The install-only hook ran six seconds before the
records it was meant to wire existed. The purchase bridge escaped by luck alone:
its type was created at 11:02:22.757, before the bridge installed at 11:02:25.259.
That ordering accident IS the defect class.

Wiring now lives in one shared method on approval.request.type, called from a
per-bridge data-file <function> - the pattern the Brain carriers proved, which
Odoo runs on install AND on every upgrade. One detail is load-bearing: the
<function> could NOT go in the existing seed file, because _tag_function returns
early inside a noupdate block, which would have re-created the bug in silence.
Each bridge gets a second, update-loaded file instead.

The non-clobber guard is untouched - same has_executable_code, same two
conditions, so a customer's own hook is still never overwritten. Only the caller
moved. Idempotent by construction: once wired, the body IS executable code and
the agent IS set, so a second pass writes nothing. Measured over three upgrade
passes: the fragment appears exactly once.

Guarded in both directions. Removing the mechanism reds five tests and leaves the
database untouched, which is the defect reproduced. Dropping the file from the
manifest while leaving it on disk reds the manifest assertion - and note the
wiring test stays GREEN there, because convert_file drives the file regardless of
the manifest. Without that assertion the bug would return with a green suite.

test_advisory_account was not weakened to pass; its assertions are byte-identical.
It is green because the three types now read wired after an upgrade, where they
read unwired before.

One gap deliberately left, so it is a decision rather than an oversight: a company
created AFTER install gets fresh approval types with no advisory until the next
upgrade. Same family, different trigger, and closing it needs a cross-bridge
registry of which bridge owns which codes - the Brain cluster needed its own ADR
for the equivalent.
                                            

Branch: 17.0

Instance ID: 0

Age:

Up-time: Not finished