[UPD] changelog : les 32 commits du merge migration et de la branche
Le journal s'arrêtait à la fusion précédente : trente-deux commits n'y figuraient pas, l'outillage de migration d'un côté, la convention d'écriture et ses garde-fous de l'autre. Dix-sept entrées les couvrent, en Ajouté, Modifié, Corrigé et Retiré. Le `.base.md` est édité et mmg régénère les deux fichiers dérivés, qui ne se modifient jamais à la main. Vérifié : autant de puces en français qu'en anglais dans chaque section, et aucune donnée identifiante. `[Unreleased]` porte deux sections Modifié et deux Corrigé, défaut antérieur ; les entrées vont dans les premières. --- EN --- The changelog stopped at the previous merge: thirty-two commits were missing from it, the migration tooling on one side, the writing convention and its guard rails on the other. Seventeen entries cover them, across Added, Changed, Fixed and Removed. The `.base.md` is edited and mmg regenerates the two derived files, which are never edited by hand. Checked: as many French bullets as English ones in every section, and no identifying data. `[Unreleased]` carries two Changed and two Fixed sections, a pre-existing defect; the entries go into the first of each. Assisted-by: Claude Opus 5
This commit is contained in:
parent
4701660203
commit
01a3ba25ca
3 changed files with 68 additions and 0 deletions
|
|
@ -41,6 +41,14 @@ Recréer l'environnement virtuel, utiliser le guide d'installation depuis l'outi
|
|||
## Ajouté
|
||||
<!-- [en] -->
|
||||
|
||||
- A `pre-commit` hook lists the comments worth re-reading in the files being staged, and never blocks: over the repository's own sources, 373 files yield 463 signals, and a blocking check at that scale gets uninstalled the following week. The tool behind it, `script/analyse/check_comment_hygiene.py`, reports two families of unequal certainty — identifying data, an address, an e-mail or an account path, which is a finding; and narrative, a witness marker, an absolute date or the first person, which is a signal to RE-READ, since it cannot know whether the sentence states a durable fact. It reads comments and docstrings, `#` lines and shell trailing comments alike, skips vendored code, and falls back on a line scan when a source will not parse, an empty report otherwise declaring clean a file it never read. Exit codes follow the repository convention: 0 nothing to report, 1 findings, 2 the tool failed
|
||||
- The TODO menu shows the context an assistant is given, scattered as it is over six sources: instructions, rules, skills, deployed commands, git hooks and memory. Each deployed command is compared against its repository template, ignoring the git identity lines the deployment substitutes, so a stale copy shows up where a strict equality would declare them all stale. Nothing from `private/` is reported, not even a count: naming a file whose purpose is to hold what must not go out amounts to pointing at it
|
||||
- Duplicating a database and neutralising it for good: duplication goes through Odoo's `exp_duplicate_database` rather than `CREATE DATABASE … TEMPLATE`, which copies the tables and nothing else. Only Odoo drops the source's open connections — one Odoo shell left open is enough for PostgreSQL to refuse — regenerates `database.uuid`, copies the filestore, and runs the `neutralize.sql` files of the installed modules. The repository's in-house modules obtained none of the four, and one of them opened a door: deleting every `ir.mail_server` makes Odoo fall back on the configuration file's `smtp_server`, where Odoo's own placeholder server exists precisely to plug that hole. Odoo's neutralisation begins at 16; from 12 to 15 the copy falls back on the repository's long-standing `update_prod_to_dev.sh`, which sets no `is_neutralized`, disables no cron and leaves the payment keys, but does remove the mail servers and lay down a development account. The route taken is ANNOUNCED at run time, a copy whose route is unknown being unjudgeable, and a missing script fails the copy rather than letting it come out raw while announcing itself neutralised
|
||||
- The migration quality screen says whether a run succeeded, where it only compared the tiers: every verdict shows, 12 through 18 — the only way to see that a failure at one tier was recovered higher up — read from the progression file and tied to the ODOO tier, not to the driver's counter, which is off by one. It names where the traces live, config.conf leaving logfile= empty and Odoo's output dying with the terminal; it shows the step-log passage around each command, keeps by tee what it launches itself and re-reads that without rerunning; and it runs six review steps from « r », asking before it switches the checkout, since replaying a test from another tier opened the database with the wrong version, which writes before it fails. A status is read the way the tools write it — 0 nothing to report, 1 findings, 2 the tool failed — so nothing is painted red where nothing failed. Output is captured through a pseudo-terminal, never a pipe: smoke_public_url requires stdin AND stdout to be terminals and, behind a pipe, silently stops offering the COW view repair; nine runs go through it, two stay out, pty.spawn being born 0×0 where a full-screen tool would lay out on nothing
|
||||
- Three checks join the migration review, each for what a tier destroys without reporting a single failure. The manifest holes: an addons repository absent from one tier's manifest does not exist on disk during that step, so Odoo declares its modules missing, the driver offers to delete them, and the feature leaves with them — only the hole counts, present before and after, absent in between, which turns 35 candidates into 19 real omissions instead of 46% noise. The tree view type, removed in Odoo 18 with no shim, is read in the SOURCES, where every other review tool reads the database and a module that never installed leaves nothing; the word is still a valid identifier, so of 465 occurrences only 80 break, and lxml and ast decide by the literal's position, never a regex. The chart drift: a bump reloads the localisation template in silence — three of the core l10n scripts call try_loading() without force_create=False, so every account the template cannot match by code is CREATED, and the groups thus added reclassify the existing chart. An absolute count says nothing there, only the GAP between two tiers of one migration can be judged, and the tool prescribes replaying the tier rather than repairing: its natural deletion key also catches accounts re-matched by code
|
||||
- run.sh warms the registry over HTTP while the server starts. Odoo loads a database's registry only on the FIRST request that concerns it, and on a migrated database whoever opens the page waits tens of seconds; the probe takes that time instead and stops at the first answer, a 303, a 404 or a 500 all proving the registry is loaded. It cannot get in the way: it ALWAYS returns 0, dies with run.sh through a trap, gives up after two minutes, and takes the port from the command line, then config.conf, then the log, exact even when the requested port was taken — an empty or wildcard listen interface is probed on the loopback. `--erplibre-disable-warmup-http` turns it off and is the only flag STRIPPED before odoo_bin.sh, which Odoo rejects; `--no-http` and `--stop-after-init` turn it off too and go through, there being nothing to wake when no one listens
|
||||
- A writing convention for what stays in git. A commit subject read alone, with no diff and no body, must say which part of the system changes and what is now different there — the symptom, the quoted error and the metaphor are EVIDENCE, and evidence belongs in the body. A comment has the CODE for subject, in the present of what it does, so a sentence whose subject is an incident, a machine, a date or a person goes to the unversioned `tasks/`, while the failure mode the code prevents stays. Nothing identifying outside `private/` — no customer, real database, host, address, e-mail or account path — and an example illustrating that ban is invented rather than borrowed, a test freezing forever what it holds. A measurement that establishes a durable fact stays, stripped of its date and its operator; the reading of what answered that day goes
|
||||
- A `commit-msg` hook refuses the mechanical part of that writing convention and nothing more: no tag, a subject over 72 characters, a subject opening on a quotation, a body over 10 lines for one language, an IP address, an e-mail, an account path, or a term from a forbidden-names list that lives outside git since the list is what it protects — absent, that last check stays silent. It counts characters, not bytes, or a 72-character French subject would fall on its accents; it excludes the trailers and the `--cleanup=scissors` diff; and its refusal names `git commit --no-verify`, a guard rail that refuses too much getting uninstalled. Whether the subject says what the code is about stays a judgement no hook makes. The predicate telling a fleet address from an Odoo manifest version, a loopback, a mask, a network address or an RFC 5737 documentation block is shared with the comment check, two predicates for one question drifting apart. Its 40 tests weigh the acceptances — a « Merge branch », a rebase fixup — as much as the refusals
|
||||
- `long_test/` — tests that create real machines and take hours, kept out of `test/` so the unit runner stays runnable in seconds. `deep_proxmox.py` stacks Proxmox in Proxmox, `deep_qemu.py` stacks QEMU in QEMU, and they share one engine. Measured on 28 cores: three levels cost 34 minutes, the fourth 4 h 20 of boot plus 7 h 18 of install — everything there is 15 to 30 times slower, and that is where the vendors stop documenting nesting. The depth is a parameter and defaults to three, because three works
|
||||
- deep_qemu proves KVM at every level instead of assuming it: `deploy_qemu.py` never passes `--cpu host-passthrough` and, when /dev/kvm is missing, it does not fail — it sets `--virt-type qemu` and creates a fully EMULATED VM, seven and a half minutes to boot, with no exit code to say so. Unguarded, the descent would measure stacked TCG while believing it measured nesting. Each level must show `/dev/kvm`, `nested=Y` and a child domain in `type='kvm'`; what was not read counts as NO
|
||||
- Both long tests take `--hote` to start from a machine you already own, rather than creating a head VM to host a hypervisor you have on hand — that costs five minutes AND one level of nesting. The plan is then sized on the ROOT, read over ssh; the delays count ABSOLUTE depth; and the root is never a level reached, never destroyed, and its ~/.ssh/config entry is never removed
|
||||
|
|
@ -125,6 +133,14 @@ Recréer l'environnement virtuel, utiliser le guide d'installation depuis l'outi
|
|||
|
||||
<!-- [fr] -->
|
||||
|
||||
- Un hook `pre-commit` liste les commentaires à relire dans les fichiers qu'on indexe, et ne bloque jamais : sur les sources du dépôt, 373 fichiers rendent 463 signaux, et un contrôle bloquant à cette échelle se fait désinstaller la semaine suivante. L'outil qui le sert, `script/analyse/check_comment_hygiene.py`, rapporte deux familles de sûreté inégale — la donnée identifiante, adresse, courriel ou chemin de compte, qui est une trouvaille ; et le récit, marqueur de témoignage, date absolue ou première personne, qui est un signal à RELIRE, l'outil ne pouvant savoir si la phrase énonce un fait durable. Il lit les commentaires et les docstrings, les lignes `#` comme les commentaires shell de fin de ligne, écarte le code tiers, et se replie sur un balayage ligne à ligne quand un source ne se parse pas, un rapport vide déclarant sinon propre un fichier qu'il n'a jamais lu. Les codes de sortie suivent la convention du dépôt : 0 rien à signaler, 1 des trouvailles, 2 l'outil a échoué
|
||||
- Le menu TODO montre le contexte fourni à un assistant, éparpillé sur six sources : instructions, règles, skills, commandes déployées, hooks git et mémoire. Chaque commande déployée est comparée à son gabarit du dépôt en ignorant les lignes d'identité git que le déploiement substitue, si bien qu'une copie périmée se voit là où une égalité stricte les déclarerait toutes périmées. Rien de `private/` n'est relevé, pas même un compte : nommer un fichier dont l'objet est de retenir ce qui ne doit pas sortir revient à le désigner
|
||||
- Dupliquer une base et la neutraliser pour de bon : la duplication passe par `exp_duplicate_database` d'Odoo plutôt que par `CREATE DATABASE … TEMPLATE`, qui copie les tables et rien d'autre. Odoo seul coupe les connexions ouvertes sur la source — un shell Odoo laissé ouvert suffit à faire refuser PostgreSQL —, régénère `database.uuid`, copie le filestore et exécute les fichiers `neutralize.sql` des modules installés. Les modules maison du dépôt n'obtenaient aucun des quatre, et l'un d'eux ouvrait une porte : supprimer tous les `ir.mail_server` fait retomber Odoo sur le `smtp_server` du fichier de configuration, là où le serveur bouchon d'Odoo existe précisément pour boucher ce trou. La neutralisation d'Odoo commence à la 16 ; de 12 à 15 la copie retombe sur la technique de longue date du dépôt, `update_prod_to_dev.sh`, qui ne pose pas `is_neutralized`, ne désactive aucun cron et laisse les clés de paiement, mais supprime les serveurs de courriel et pose un compte de développement. Le chemin suivi est ANNONCÉ à l'exécution, une copie dont on ignore par quel chemin elle est passée ne se jugeant pas, et un script introuvable fait échouer la copie plutôt que de la laisser sortir brute en s'annonçant neutralisée
|
||||
- L'écran de qualité de migration dit si une migration a réussi, là où il comparait seulement les paliers : tous les verdicts s'affichent, de la 12 à la 18 — seule façon de voir qu'un échec a été rattrapé à un palier plus haut — lus dans le journal de progression et rattachés au palier ODOO, non au compteur du pilote, décalé d'un rang. Il dit où vivent les traces, config.conf laissant logfile= vide et la sortie d'Odoo mourant avec le terminal ; il montre le passage du journal d'étape qui entoure chaque commande, garde par tee ce qu'il lance lui-même et le relit sans relancer ; et il lance six étapes de revue par « r », en demandant avant de basculer le checkout, car rejouer un test d'un autre palier ouvrait la base avec la mauvaise version, qui y écrit avant d'échouer. Un statut se lit comme les outils l'écrivent — 0 rien à signaler, 1 des trouvailles, 2 l'outil a échoué — si bien que plus rien n'est peint en rouge là où rien n'a échoué. La sortie est capturée par pseudo-terminal, jamais par un tube : smoke_public_url exige stdin ET stdout sur un terminal et, derrière un tube, cesse en silence d'offrir la réparation des vues COW ; neuf exécutions y passent, deux restent dehors, pty.spawn naissant en 0×0 où un plein écran se perdrait
|
||||
- Trois contrôles rejoignent la revue de migration, chacun pour ce qu'un palier détruit sans signaler le moindre échec. Les trous de manifeste : un dépôt d'addons absent du manifeste d'un palier n'existe pas sur disque pendant cette étape, Odoo déclare donc ses modules introuvables, le pilote propose de les effacer, et la fonctionnalité part avec eux — seul le trou compte, présent avant et après, absent au milieu, ce qui ramène 35 candidats à 19 vraies omissions au lieu de 46 % de bruit. Le type de vue tree, supprimé en Odoo 18 sans conversion, se lit dans les SOURCES, là où tous les autres outils de la revue lisent la base et où un module jamais installé ne laisse rien ; le mot reste un identifiant valide, si bien que sur 465 occurrences 80 seulement cassent, et lxml et ast décident par la position du littéral, jamais une regex. La dérive du plan comptable : une montée de version recharge le gabarit de localisation en silence — trois des scripts l10n du noyau appellent try_loading() sans force_create=False, donc tout compte que le gabarit n'apparie pas par code est CRÉÉ, et les groupes ainsi ajoutés reclassent le plan existant. Un compte absolu n'y dit rien, seul l'ÉCART entre deux paliers d'une même migration se juge, et l'outil prescrit de rejouer le palier plutôt que de réparer : sa clé naturelle de suppression attrape aussi des comptes réappariés par code
|
||||
- run.sh réveille le registre par HTTP pendant que le serveur démarre. Odoo ne charge le registre d'une base qu'à la PREMIÈRE requête qui la concerne, et sur une base migrée la personne qui ouvre la page attend des dizaines de secondes ; la sonde prend ce temps à sa place et s'arrête à la première réponse, un 303, un 404 ou un 500 prouvant tous que le registre est chargé. Elle ne peut pas nuire : elle rend TOUJOURS 0, meurt avec run.sh par un trap, abandonne après deux minutes, et prend le port sur la ligne de commande, puis dans config.conf, puis dans le journal, exact même quand le port demandé était pris — l'écoute sur une interface vide ou générale est sondée par le bouclage. `--erplibre-disable-warmup-http` la coupe et est le seul drapeau RETIRÉ avant odoo_bin.sh, qu'Odoo refuse ; `--no-http` et `--stop-after-init` la coupent aussi et passent, puisqu'il n'y a rien à réveiller quand personne n'écoute
|
||||
- Une convention d'écriture pour ce qui reste dans git. Un sujet de commit lu seul, sans diff ni corps, doit dire quelle partie du système change et ce qui y est désormais différent — le symptôme, l'erreur citée et la métaphore sont des PREUVES, et une preuve va dans le corps. Un commentaire a le CODE pour sujet, au présent de ce qu'il fait : une phrase dont le sujet est un incident, une machine, une date ou une personne part vers `tasks/`, non versionné, tandis que le mode de défaillance que le code empêche reste. Rien d'identifiant hors de `private/` — ni client, ni base réelle, ni hôte, ni adresse, ni courriel, ni chemin de compte — et l'exemple qui illustre cet interdit s'invente au lieu de s'emprunter, un test figeant pour toujours ce qu'il contient. Une mesure qui établit un fait durable reste, dépouillée de sa date et de son opérateur ; le relevé de ce qui répondait ce jour-là part
|
||||
- Un hook `commit-msg` refuse la part mécanique de cette convention d'écriture, et rien de plus : tag absent, sujet de plus de 72 caractères, sujet ouvrant sur une citation, corps de plus de 10 lignes pour une langue, adresse IP, courriel, chemin de compte, terme d'une liste de noms interdits qui vit hors de git puisque c'est elle qu'elle protège — absente, ce dernier contrôle se tait. Il compte des caractères et non des octets, sans quoi un sujet français de 72 caractères tomberait sur ses accents ; il exclut les trailers et le diff de `--cleanup=scissors` ; et son refus nomme `git commit --no-verify`, un garde-fou qui refuse trop étant désinstallé. Dire sur quoi porte le code reste un jugement qu'aucun hook ne rend. Le prédicat qui distingue une adresse du parc d'une version de manifeste Odoo, d'une boucle locale, d'un masque, d'une adresse de réseau ou d'un bloc de documentation RFC 5737 est partagé avec le contrôle des commentaires, deux prédicats pour une même question finissant par diverger. Ses 40 tests pèsent les acceptations — un « Merge branch », un fixup de rebase — autant que les refus
|
||||
- `long_test/` — des tests qui créent de vraies machines et durent des heures, tenus hors de `test/` pour que le lanceur unitaire reste lançable en quelques secondes. `deep_proxmox.py` empile des Proxmox dans des Proxmox, `deep_qemu.py` des QEMU dans des QEMU, et les deux partagent un moteur. Mesuré sur 28 cœurs : trois étages coûtent 34 minutes, le quatrième 4 h 20 d'amorçage plus 7 h 18 d'installation — tout y est 15 à 30 fois plus lent, et c'est là que les fabricants cessent de documenter l'imbrication. La profondeur est un paramètre et vaut trois par défaut, parce que trois marche
|
||||
- deep_qemu PROUVE KVM à chaque étage au lieu de le supposer : `deploy_qemu.py` ne passe jamais `--cpu host-passthrough` et, quand /dev/kvm manque, il n'échoue pas — il pose `--virt-type qemu` et crée une VM entièrement ÉMULÉE, sept minutes et demie de démarrage, sans qu'aucun code de retour ne le dise. Sans garde, la descente mesurerait de la TCG empilée en croyant mesurer de l'imbrication. Chaque étage doit montrer `/dev/kvm`, `nested=Y` et un domaine enfant en `type='kvm'` ; ce qui n'a pas été lu vaut NON
|
||||
- Les deux tests longs acceptent `--hote` pour partir d'une machine qu'on possède déjà, au lieu de créer une VM de tête pour héberger un hyperviseur qu'on a sous la main — cela coûte cinq minutes ET un étage d'imbrication. Le plan se dimensionne alors sur la RACINE, lue par ssh ; les délais comptent la profondeur ABSOLUE ; et la racine n'est jamais un étage atteint, jamais détruite, et son entrée ~/.ssh/config n'est jamais retirée
|
||||
|
|
@ -215,12 +231,16 @@ Recréer l'environnement virtuel, utiliser le guide d'installation depuis l'outi
|
|||
## Modifié
|
||||
<!-- [en] -->
|
||||
|
||||
- Staging names the files, never `git add -A`. The sweep stages everything untracked, and this repository keeps two directories untracked ON PURPOSE: `private/`, the only place allowed to hold customer data, and `tasks/`, where the convention sends the investigation precisely because it is not versioned. It also swallows whatever else is in flight in the checkout, under a subject that does not cover it; `git add -p` stages the hunks when one file carries two subjects
|
||||
- A countdown prompt gives 15 seconds to decide, where five were not enough to READ the question: the countdown exists so a run can be left unattended, not to go fast, and too short it does the opposite — the answer comes by reflex, or a default no one read is taken. A restored database is named after the backup file, which already carries a telling name, rather than « test », under which successive migrations all landed on one name. The name is sanitised, since it ends up in a createdb, and capped at 41 characters: the driver appends « _neutralize_upgrade_18 » and PostgreSQL truncates at 63, which would put two tiers on the same name. A remote download keeps the name the server gave
|
||||
- todo.py split into nine files, one per subject, with a shared base per form. It carried 9 500 lines more than a file should and every subject went through it; the deployment forms repeated the same field-and-validation machinery, so a fix in one never reached the others. No behaviour changes
|
||||
- Branch, profile and type are chosen per VM. They were global, which meant switching everything to deploy a single machine differently
|
||||
- One shared base describes the guest system, where each form used to describe it again
|
||||
|
||||
<!-- [fr] -->
|
||||
|
||||
- L'indexation nomme les fichiers, jamais `git add -A`. Le ratissage indexe tout ce qui n'est pas suivi, et le dépôt garde deux répertoires non suivis EXPRÈS : `private/`, seul endroit autorisé à porter une donnée de client, et `tasks/`, où la convention envoie l'enquête précisément parce qu'il n'est pas versionné. Il emporte aussi ce qui est en cours ailleurs dans le checkout, sous un sujet qui ne le couvre pas ; `git add -p` indexe les hunks quand un fichier porte deux sujets
|
||||
- Une invite à compte à rebours laisse 15 secondes pour décider, là où cinq ne suffisaient pas à LIRE la question : le compte à rebours n'existe pas pour aller vite mais pour qu'une exécution puisse être laissée sans surveillance, et trop court il fait l'inverse — la réponse vient par réflexe, ou un défaut que personne n'a lu s'applique. Une base restaurée porte le nom du fichier de sauvegarde, qui en porte déjà un parlant, plutôt que « test », sous lequel des migrations successives finissaient toutes sur un même nom. Le nom est assaini, puisqu'il finit dans un createdb, et borné à 41 caractères : le pilote ajoute « _neutralize_upgrade_18 » et PostgreSQL tronque à 63, ce qui ferait finir deux paliers sur le même nom. Un téléchargement distant garde celui que le serveur a donné
|
||||
- todo.py éclaté en neuf fichiers, un par sujet, avec un socle commun par formulaire. Il portait 9 500 lignes de plus qu'un fichier ne devrait et tous les sujets y passaient ; les formulaires de déploiement répétaient la même mécanique de champs et de validation, si bien qu'une correction dans l'un ne gagnait jamais les autres. Aucun changement de comportement
|
||||
- La branche, le profil et le type se choisissent par VM. Ils étaient globaux, ce qui obligeait à tout basculer pour déployer une seule machine autrement
|
||||
- Un socle commun décrit le système invité, là où chaque formulaire le redécrivait
|
||||
|
|
@ -231,6 +251,12 @@ Recréer l'environnement virtuel, utiliser le guide d'installation depuis l'outi
|
|||
## Corrigé
|
||||
<!-- [en] -->
|
||||
|
||||
- `odoo_bin.sh db --drop` failed with AccessDenied at every migration tier, and the clone then hit « database already exists »: db_restore.py reads the repository's config.conf, sees admin_passwd = admin and therefore sends no master password, while odoo_bin.sh passed no « -c », so Odoo read ~/.odoorc and its hashed one. ODOO_RC closes that seam in one place instead of twenty call sites, versions 12 to 18 reading it after « -c » and before ~/.odoorc, so an explicit choice still wins
|
||||
- The account.root SQL view Odoo 17 creates is dropped before the load into 18, where the model carries _auto = False and _table_query = '0', so its name enters no query and the missing-table check skips it. The view is not merely dead but WRONG, built on the code column the 18 ORM no longer writes, and it is the sole pin holding the two legacy columns database_cleanup fails on — no DROP COLUMN, OpenUpgrade still reading them afterwards
|
||||
- The migration repair created pricelists that should not exist, in two ways. It asked `env.user.has_group()`, which says yes as soon as the caller belongs to the group — and the migration adds it along the way — where the settings checkbox reads something else entirely: what `base.group_user` IMPLIES. Deciding on the caller built a pricelist in a database whose feature is off, and Odoo then warned on every opening of the settings that it would archive it. And a pricelist shared across companies, with an empty `company_id`, did not count as belonging to the company: the repair saw a company without a list and made an empty duplicate beside the existing one, on a database that had lost nothing. Both now read the group implication and the tool's own `pricelist_missing` detector, which already tells the two cases apart; the migration-residue check asked the same wrong question and was corrected with them
|
||||
- The anonymisation blacklist handed its SQL to psql as a single argument, and Linux caps one argument at 131 072 bytes: the mode that covers the most tables was exactly the one that broke, on « OSError: [Errno 7] Argument list too long ». The SQL now travels through a file with `-f`, which keeps the `--single-transaction` that standard input would have silently dropped. Text columns with a declared length are truncated by `left(…, n)`, the id FIRST so a unique column stays unique, and every identifier is quoted — Odoo allows a field named user or order. Skipping every column under a CHECK constraint had left the partner name untouched: on text, only FORM constraints are out of reach, and an UPDATE that fails writes nothing
|
||||
- Anonymisation respects what a value MEANS, where the SQL type says only what it IS. Odoo declares `parent_path` as `char` but stores an id path in it — 1/7/12/ — parsed straight back with `int()`, so a name written there breaks the first page load; every `_parent_store` model carries one, and `account_payment_term.days_next_month` goes to `int()` the same way. The two known names are skipped, then the content itself is probed: a column whose every value is a path is left alone, even in an in-house module, and the slashes are required, so a value of pure digits does not escape anonymisation by passing for an id. Numbers were drawn uniformly over 0 to 1000, which is wrong for every number bounded by its usage — hours, percentages, rates: a float holding an hour of day, drawn outside 0..23, makes displaying the record raise « ValueError: hour must be in 0..23 », a bound that lives in Odoo's Python where no PostgreSQL constraint declares it. The draw now respects the only bound the DATA declares, its own range, min and max measured per table; 0 to 1000 remains solely for a column that is empty or cannot be probed
|
||||
- The unit runner took seven filename prefixes, « the rest needing a database », and ran 1131 tests where all 3703 in the directory pass with PostgreSQL unreachable; it globs test/test_*.py. Two shapes make a file silent without an error — unittest.main() placed mid-file, which exits before the second half is even defined (four files, 87 tests), and no __main__ block at all, which counts zero (eight files, 174 tests) — and a guard now refuses both, along with any return to a list of prefixes
|
||||
- The mobile bundle check accepted only the pack layout, when a real build ships one tar.gz per repository. It failed on `<slug> : index.json absent` and stopped `compile_and_run.sh` before the APK — since 2026-08-20, for anyone on the current mobile main. It now accepts both layouts, and proves the presence of EVERY promised file rather than a sample of twenty: streaming all 139 archives costs 6 s, and 124 350 files are accounted for
|
||||
- The bundle test guarded the ZIP entry limit by demanding a `chunk` field on every file, which is the pack layout rather than the limit itself. It now counts the entries the APK will carry — 278 against a ceiling of 65 535 — so either layout passes and a return to file-per-source still fails
|
||||
|
||||
|
|
@ -245,6 +271,12 @@ Recréer l'environnement virtuel, utiliser le guide d'installation depuis l'outi
|
|||
- The NAT bridge was written before knowing whether NAT exists. Six lines of iptables and "return code 1" came after the stanza had already gone into /etc/network/interfaces, and nothing in that noise said a reboot was needed: the host was running Debian's cloud kernel, stripped of netfilter. Our own install_proxmox.sh produces that state, so a freshly installed nested Proxmox is ALWAYS in it — the guard now sits where the consequence is, not at host confirmation
|
||||
<!-- [fr] -->
|
||||
|
||||
- « odoo_bin.sh db --drop » échouait par AccessDenied à chaque palier de migration, et le clone butait ensuite sur « database already exists » : db_restore.py lit le config.conf du dépôt, y voit admin_passwd = admin et n'envoie donc aucun mot de passe maître, quand odoo_bin.sh ne passait pas de « -c », si bien qu'Odoo lisait ~/.odoorc et son mot de passe haché. ODOO_RC ferme cette couture en un point plutôt qu'à vingt sites d'appel, les versions 12 à 18 le lisant après « -c » et avant ~/.odoorc, donc un choix explicite l'emporte toujours
|
||||
- La vue SQL account.root que crée Odoo 17 est retirée avant le chargement en 18, où le modèle porte _auto = False et _table_query = '0', si bien que son nom n'entre plus dans aucune requête et que le contrôle des tables manquantes l'ignore. La vue n'est pas seulement morte mais FAUSSE, bâtie sur la colonne code que l'ORM 18 n'écrit plus, et elle est l'unique épingle des deux colonnes héritées où database_cleanup échoue — aucun DROP COLUMN, OpenUpgrade les lisant encore ensuite
|
||||
- La réparation de migration créait des listes de prix qui n'avaient pas lieu d'être, de deux façons. Elle interrogeait `env.user.has_group()`, qui répond oui dès que l'exécutant est membre du groupe — et la migration l'y ajoute en cours de route —, là où la case des réglages lit tout autre chose : ce que `base.group_user` IMPLIQUE. Décider sur l'exécutant créait une liste de prix dans une base dont la fonctionnalité est éteinte, et Odoo prévenait alors à chaque ouverture des réglages qu'il allait l'archiver. Et une liste de prix partagée entre sociétés, au `company_id` vide, ne comptait pas comme appartenant à la société : la réparation voyait une société sans liste et fabriquait un doublon vide à côté de l'existante, sur une base qui n'avait pourtant rien perdu. Les deux lisent désormais l'implication du groupe et le détecteur `pricelist_missing` du même outil, qui distingue déjà les deux cas ; le contrôle « restant de migration » posait la même mauvaise question et a été corrigé avec elles
|
||||
- La liste noire de l'anonymisation passait son SQL à psql en UN seul argument, et Linux plafonne un argument à 131 072 octets : le mode qui couvre le plus de tables était justement celui qui cassait, sur « OSError: [Errno 7] Argument list too long ». Le SQL passe désormais par un fichier avec `-f`, qui garde le `--single-transaction` que l'entrée standard aurait perdu en silence. Les colonnes texte à longueur déclarée sont tronquées par `left(…, n)`, l'identifiant en TÊTE pour qu'une colonne unique le reste, et tous les identifiants sont cités — Odoo laisse nommer un champ user ou order. Écarter toute colonne sous contrainte CHECK laissait le nom du partenaire intact : sur du texte, seules les contraintes de FORME sont hors de portée, et un UPDATE qui échoue n'écrit rien
|
||||
- L'anonymisation respecte ce qu'une valeur SIGNIFIE, là où le type SQL dit seulement ce qu'elle EST. Odoo déclare `parent_path` en `char` mais y range un chemin d'identifiants — 1/7/12/ — reparsé aussitôt par `int()` : un nom écrit là casse le premier chargement de page ; tout modèle `_parent_store` en porte un, et `account_payment_term.days_next_month` passe de même à `int()`. Les deux noms connus sont écartés, puis le contenu lui-même est sondé : une colonne dont chaque valeur est un chemin reste intacte, même dans un module maison, et les barres obliques sont exigées, si bien qu'une valeur tout en chiffres n'échappe pas à l'anonymisation en passant pour un identifiant. Les nombres étaient tirés uniformément sur 0 à 1000, ce qui est faux pour tout nombre borné par son usage — heures, pourcentages, taux : un `float` qui porte une heure de la journée, tiré hors de 0..23, fait lever « ValueError: hour must be in 0..23 » à l'affichage de la fiche, borne qui vit dans le Python d'Odoo là où aucune contrainte PostgreSQL ne la déclare. Le tirage respecte désormais la seule borne que les DONNÉES déclarent, leur propre étendue, min et max mesurés par table ; 0 à 1000 ne reste que pour une colonne vide ou impossible à sonder
|
||||
- Le lanceur unitaire ne prenait que sept préfixes de noms, « le reste demandant une base de données », et exécutait 1131 tests là où les 3703 du répertoire passent avec PostgreSQL injoignable ; il balaie test/test_*.py. Deux formes rendent un fichier muet sans erreur — unittest.main() posé en plein milieu, qui sort avant même que la seconde moitié soit définie (quatre fichiers, 87 tests), et l'absence de bloc __main__, qui compte zéro (huit fichiers, 174 tests) — et une garde refuse désormais les deux, ainsi que tout retour à une liste de préfixes
|
||||
- Le vérificateur du transfert mobile n'acceptait que la disposition en packs, quand une compilation réelle livre un tar.gz par dépôt. Il échouait sur `<slug> : index.json absent` et arrêtait `compile_and_run.sh` avant l'APK — depuis le 2026-08-20, pour quiconque est sur le main mobile actuel. Il accepte désormais les deux dispositions, et prouve la présence de CHAQUE fichier promis plutôt qu'un échantillon de vingt : traverser les 139 archives coûte 6 s, et 124 350 fichiers sont comptés
|
||||
- Le test du bundle gardait la limite d'entrées du ZIP en exigeant un champ `chunk` sur chaque fichier, c'est-à-dire la disposition en packs plutôt que la limite elle-même. Il compte maintenant les entrées que portera l'APK — 278 pour un plafond de 65 535 — si bien que les deux dispositions passent et qu'un retour au fichier-par-source échoue toujours
|
||||
|
||||
|
|
@ -263,10 +295,12 @@ Recréer l'environnement virtuel, utiliser le guide d'installation depuis l'outi
|
|||
## Retiré
|
||||
<!-- [en] -->
|
||||
|
||||
- The residue check that called a language broken when its res_lang row has active at NULL — listed nowhere, no longer re-enablable. False in the 18 source: an ('active','=',False) domain compiles to (IS NULL OR = FALSE), the Languages menu action carries active_test: False, sorting goes through COALESCE(active, FALSE), and reading returns bool(value). Odoo writes that NULL itself, active being a Boolean with no default and res.lang.csv having no such column, which makes one NULL per language added to the catalogue — so « zero before, nonzero after » is not enough to declare a residue. A test now refuses a verdict key that nothing defines any more
|
||||
- Ubuntu 20.04 and 22.04 support, on every architecture: pikepdf needs qpdf 12.2, whose build requires C++20, while focal ships GCC 9 and publishes no `g++-10` for s390x
|
||||
|
||||
<!-- [fr] -->
|
||||
|
||||
- Le contrôle de résidus qui jugeait cassée une langue dont la ligne res_lang porte active à NULL — listée nulle part, plus réactivable. Faux dans la source 18 : un domaine ('active','=',False) compile en (IS NULL OR = FALSE), l'action du menu Langues porte active_test: False, le tri passe par COALESCE(active, FALSE), et la lecture rend bool(value). C'est Odoo lui-même qui écrit ce NULL, active étant un booléen sans défaut et res.lang.csv n'ayant pas cette colonne, soit un NULL par langue ajoutée au catalogue — « zéro avant, non nul après » ne suffit donc pas à déclarer un résidu. Un test refuse désormais une clé de verdict que plus rien ne définit
|
||||
- Le support d'Ubuntu 20.04 et 22.04, sur toutes les architectures : pikepdf réclame qpdf 12.2, dont la compilation exige C++20, quand focal livre GCC 9 et ne publie pas de `g++-10` pour s390x
|
||||
|
||||
<!-- [en] -->
|
||||
|
|
|
|||
|
|
@ -15,6 +15,14 @@ Recréer l'environnement virtuel, utiliser le guide d'installation depuis l'outi
|
|||
|
||||
## Ajouté
|
||||
|
||||
- Un hook `pre-commit` liste les commentaires à relire dans les fichiers qu'on indexe, et ne bloque jamais : sur les sources du dépôt, 373 fichiers rendent 463 signaux, et un contrôle bloquant à cette échelle se fait désinstaller la semaine suivante. L'outil qui le sert, `script/analyse/check_comment_hygiene.py`, rapporte deux familles de sûreté inégale — la donnée identifiante, adresse, courriel ou chemin de compte, qui est une trouvaille ; et le récit, marqueur de témoignage, date absolue ou première personne, qui est un signal à RELIRE, l'outil ne pouvant savoir si la phrase énonce un fait durable. Il lit les commentaires et les docstrings, les lignes `#` comme les commentaires shell de fin de ligne, écarte le code tiers, et se replie sur un balayage ligne à ligne quand un source ne se parse pas, un rapport vide déclarant sinon propre un fichier qu'il n'a jamais lu. Les codes de sortie suivent la convention du dépôt : 0 rien à signaler, 1 des trouvailles, 2 l'outil a échoué
|
||||
- Le menu TODO montre le contexte fourni à un assistant, éparpillé sur six sources : instructions, règles, skills, commandes déployées, hooks git et mémoire. Chaque commande déployée est comparée à son gabarit du dépôt en ignorant les lignes d'identité git que le déploiement substitue, si bien qu'une copie périmée se voit là où une égalité stricte les déclarerait toutes périmées. Rien de `private/` n'est relevé, pas même un compte : nommer un fichier dont l'objet est de retenir ce qui ne doit pas sortir revient à le désigner
|
||||
- Dupliquer une base et la neutraliser pour de bon : la duplication passe par `exp_duplicate_database` d'Odoo plutôt que par `CREATE DATABASE … TEMPLATE`, qui copie les tables et rien d'autre. Odoo seul coupe les connexions ouvertes sur la source — un shell Odoo laissé ouvert suffit à faire refuser PostgreSQL —, régénère `database.uuid`, copie le filestore et exécute les fichiers `neutralize.sql` des modules installés. Les modules maison du dépôt n'obtenaient aucun des quatre, et l'un d'eux ouvrait une porte : supprimer tous les `ir.mail_server` fait retomber Odoo sur le `smtp_server` du fichier de configuration, là où le serveur bouchon d'Odoo existe précisément pour boucher ce trou. La neutralisation d'Odoo commence à la 16 ; de 12 à 15 la copie retombe sur la technique de longue date du dépôt, `update_prod_to_dev.sh`, qui ne pose pas `is_neutralized`, ne désactive aucun cron et laisse les clés de paiement, mais supprime les serveurs de courriel et pose un compte de développement. Le chemin suivi est ANNONCÉ à l'exécution, une copie dont on ignore par quel chemin elle est passée ne se jugeant pas, et un script introuvable fait échouer la copie plutôt que de la laisser sortir brute en s'annonçant neutralisée
|
||||
- L'écran de qualité de migration dit si une migration a réussi, là où il comparait seulement les paliers : tous les verdicts s'affichent, de la 12 à la 18 — seule façon de voir qu'un échec a été rattrapé à un palier plus haut — lus dans le journal de progression et rattachés au palier ODOO, non au compteur du pilote, décalé d'un rang. Il dit où vivent les traces, config.conf laissant logfile= vide et la sortie d'Odoo mourant avec le terminal ; il montre le passage du journal d'étape qui entoure chaque commande, garde par tee ce qu'il lance lui-même et le relit sans relancer ; et il lance six étapes de revue par « r », en demandant avant de basculer le checkout, car rejouer un test d'un autre palier ouvrait la base avec la mauvaise version, qui y écrit avant d'échouer. Un statut se lit comme les outils l'écrivent — 0 rien à signaler, 1 des trouvailles, 2 l'outil a échoué — si bien que plus rien n'est peint en rouge là où rien n'a échoué. La sortie est capturée par pseudo-terminal, jamais par un tube : smoke_public_url exige stdin ET stdout sur un terminal et, derrière un tube, cesse en silence d'offrir la réparation des vues COW ; neuf exécutions y passent, deux restent dehors, pty.spawn naissant en 0×0 où un plein écran se perdrait
|
||||
- Trois contrôles rejoignent la revue de migration, chacun pour ce qu'un palier détruit sans signaler le moindre échec. Les trous de manifeste : un dépôt d'addons absent du manifeste d'un palier n'existe pas sur disque pendant cette étape, Odoo déclare donc ses modules introuvables, le pilote propose de les effacer, et la fonctionnalité part avec eux — seul le trou compte, présent avant et après, absent au milieu, ce qui ramène 35 candidats à 19 vraies omissions au lieu de 46 % de bruit. Le type de vue tree, supprimé en Odoo 18 sans conversion, se lit dans les SOURCES, là où tous les autres outils de la revue lisent la base et où un module jamais installé ne laisse rien ; le mot reste un identifiant valide, si bien que sur 465 occurrences 80 seulement cassent, et lxml et ast décident par la position du littéral, jamais une regex. La dérive du plan comptable : une montée de version recharge le gabarit de localisation en silence — trois des scripts l10n du noyau appellent try_loading() sans force_create=False, donc tout compte que le gabarit n'apparie pas par code est CRÉÉ, et les groupes ainsi ajoutés reclassent le plan existant. Un compte absolu n'y dit rien, seul l'ÉCART entre deux paliers d'une même migration se juge, et l'outil prescrit de rejouer le palier plutôt que de réparer : sa clé naturelle de suppression attrape aussi des comptes réappariés par code
|
||||
- run.sh réveille le registre par HTTP pendant que le serveur démarre. Odoo ne charge le registre d'une base qu'à la PREMIÈRE requête qui la concerne, et sur une base migrée la personne qui ouvre la page attend des dizaines de secondes ; la sonde prend ce temps à sa place et s'arrête à la première réponse, un 303, un 404 ou un 500 prouvant tous que le registre est chargé. Elle ne peut pas nuire : elle rend TOUJOURS 0, meurt avec run.sh par un trap, abandonne après deux minutes, et prend le port sur la ligne de commande, puis dans config.conf, puis dans le journal, exact même quand le port demandé était pris — l'écoute sur une interface vide ou générale est sondée par le bouclage. `--erplibre-disable-warmup-http` la coupe et est le seul drapeau RETIRÉ avant odoo_bin.sh, qu'Odoo refuse ; `--no-http` et `--stop-after-init` la coupent aussi et passent, puisqu'il n'y a rien à réveiller quand personne n'écoute
|
||||
- Une convention d'écriture pour ce qui reste dans git. Un sujet de commit lu seul, sans diff ni corps, doit dire quelle partie du système change et ce qui y est désormais différent — le symptôme, l'erreur citée et la métaphore sont des PREUVES, et une preuve va dans le corps. Un commentaire a le CODE pour sujet, au présent de ce qu'il fait : une phrase dont le sujet est un incident, une machine, une date ou une personne part vers `tasks/`, non versionné, tandis que le mode de défaillance que le code empêche reste. Rien d'identifiant hors de `private/` — ni client, ni base réelle, ni hôte, ni adresse, ni courriel, ni chemin de compte — et l'exemple qui illustre cet interdit s'invente au lieu de s'emprunter, un test figeant pour toujours ce qu'il contient. Une mesure qui établit un fait durable reste, dépouillée de sa date et de son opérateur ; le relevé de ce qui répondait ce jour-là part
|
||||
- Un hook `commit-msg` refuse la part mécanique de cette convention d'écriture, et rien de plus : tag absent, sujet de plus de 72 caractères, sujet ouvrant sur une citation, corps de plus de 10 lignes pour une langue, adresse IP, courriel, chemin de compte, terme d'une liste de noms interdits qui vit hors de git puisque c'est elle qu'elle protège — absente, ce dernier contrôle se tait. Il compte des caractères et non des octets, sans quoi un sujet français de 72 caractères tomberait sur ses accents ; il exclut les trailers et le diff de `--cleanup=scissors` ; et son refus nomme `git commit --no-verify`, un garde-fou qui refuse trop étant désinstallé. Dire sur quoi porte le code reste un jugement qu'aucun hook ne rend. Le prédicat qui distingue une adresse du parc d'une version de manifeste Odoo, d'une boucle locale, d'un masque, d'une adresse de réseau ou d'un bloc de documentation RFC 5737 est partagé avec le contrôle des commentaires, deux prédicats pour une même question finissant par diverger. Ses 40 tests pèsent les acceptations — un « Merge branch », un fixup de rebase — autant que les refus
|
||||
- `long_test/` — des tests qui créent de vraies machines et durent des heures, tenus hors de `test/` pour que le lanceur unitaire reste lançable en quelques secondes. `deep_proxmox.py` empile des Proxmox dans des Proxmox, `deep_qemu.py` des QEMU dans des QEMU, et les deux partagent un moteur. Mesuré sur 28 cœurs : trois étages coûtent 34 minutes, le quatrième 4 h 20 d'amorçage plus 7 h 18 d'installation — tout y est 15 à 30 fois plus lent, et c'est là que les fabricants cessent de documenter l'imbrication. La profondeur est un paramètre et vaut trois par défaut, parce que trois marche
|
||||
- deep_qemu PROUVE KVM à chaque étage au lieu de le supposer : `deploy_qemu.py` ne passe jamais `--cpu host-passthrough` et, quand /dev/kvm manque, il n'échoue pas — il pose `--virt-type qemu` et crée une VM entièrement ÉMULÉE, sept minutes et demie de démarrage, sans qu'aucun code de retour ne le dise. Sans garde, la descente mesurerait de la TCG empilée en croyant mesurer de l'imbrication. Chaque étage doit montrer `/dev/kvm`, `nested=Y` et un domaine enfant en `type='kvm'` ; ce qui n'a pas été lu vaut NON
|
||||
- Les deux tests longs acceptent `--hote` pour partir d'une machine qu'on possède déjà, au lieu de créer une VM de tête pour héberger un hyperviseur qu'on a sous la main — cela coûte cinq minutes ET un étage d'imbrication. Le plan se dimensionne alors sur la RACINE, lue par ssh ; les délais comptent la profondeur ABSOLUE ; et la racine n'est jamais un étage atteint, jamais détruite, et son entrée ~/.ssh/config n'est jamais retirée
|
||||
|
|
@ -101,12 +109,20 @@ Recréer l'environnement virtuel, utiliser le guide d'installation depuis l'outi
|
|||
|
||||
## Modifié
|
||||
|
||||
- L'indexation nomme les fichiers, jamais `git add -A`. Le ratissage indexe tout ce qui n'est pas suivi, et le dépôt garde deux répertoires non suivis EXPRÈS : `private/`, seul endroit autorisé à porter une donnée de client, et `tasks/`, où la convention envoie l'enquête précisément parce qu'il n'est pas versionné. Il emporte aussi ce qui est en cours ailleurs dans le checkout, sous un sujet qui ne le couvre pas ; `git add -p` indexe les hunks quand un fichier porte deux sujets
|
||||
- Une invite à compte à rebours laisse 15 secondes pour décider, là où cinq ne suffisaient pas à LIRE la question : le compte à rebours n'existe pas pour aller vite mais pour qu'une exécution puisse être laissée sans surveillance, et trop court il fait l'inverse — la réponse vient par réflexe, ou un défaut que personne n'a lu s'applique. Une base restaurée porte le nom du fichier de sauvegarde, qui en porte déjà un parlant, plutôt que « test », sous lequel des migrations successives finissaient toutes sur un même nom. Le nom est assaini, puisqu'il finit dans un createdb, et borné à 41 caractères : le pilote ajoute « _neutralize_upgrade_18 » et PostgreSQL tronque à 63, ce qui ferait finir deux paliers sur le même nom. Un téléchargement distant garde celui que le serveur a donné
|
||||
- todo.py éclaté en neuf fichiers, un par sujet, avec un socle commun par formulaire. Il portait 9 500 lignes de plus qu'un fichier ne devrait et tous les sujets y passaient ; les formulaires de déploiement répétaient la même mécanique de champs et de validation, si bien qu'une correction dans l'un ne gagnait jamais les autres. Aucun changement de comportement
|
||||
- La branche, le profil et le type se choisissent par VM. Ils étaient globaux, ce qui obligeait à tout basculer pour déployer une seule machine autrement
|
||||
- Un socle commun décrit le système invité, là où chaque formulaire le redécrivait
|
||||
|
||||
## Corrigé
|
||||
|
||||
- « odoo_bin.sh db --drop » échouait par AccessDenied à chaque palier de migration, et le clone butait ensuite sur « database already exists » : db_restore.py lit le config.conf du dépôt, y voit admin_passwd = admin et n'envoie donc aucun mot de passe maître, quand odoo_bin.sh ne passait pas de « -c », si bien qu'Odoo lisait ~/.odoorc et son mot de passe haché. ODOO_RC ferme cette couture en un point plutôt qu'à vingt sites d'appel, les versions 12 à 18 le lisant après « -c » et avant ~/.odoorc, donc un choix explicite l'emporte toujours
|
||||
- La vue SQL account.root que crée Odoo 17 est retirée avant le chargement en 18, où le modèle porte _auto = False et _table_query = '0', si bien que son nom n'entre plus dans aucune requête et que le contrôle des tables manquantes l'ignore. La vue n'est pas seulement morte mais FAUSSE, bâtie sur la colonne code que l'ORM 18 n'écrit plus, et elle est l'unique épingle des deux colonnes héritées où database_cleanup échoue — aucun DROP COLUMN, OpenUpgrade les lisant encore ensuite
|
||||
- La réparation de migration créait des listes de prix qui n'avaient pas lieu d'être, de deux façons. Elle interrogeait `env.user.has_group()`, qui répond oui dès que l'exécutant est membre du groupe — et la migration l'y ajoute en cours de route —, là où la case des réglages lit tout autre chose : ce que `base.group_user` IMPLIQUE. Décider sur l'exécutant créait une liste de prix dans une base dont la fonctionnalité est éteinte, et Odoo prévenait alors à chaque ouverture des réglages qu'il allait l'archiver. Et une liste de prix partagée entre sociétés, au `company_id` vide, ne comptait pas comme appartenant à la société : la réparation voyait une société sans liste et fabriquait un doublon vide à côté de l'existante, sur une base qui n'avait pourtant rien perdu. Les deux lisent désormais l'implication du groupe et le détecteur `pricelist_missing` du même outil, qui distingue déjà les deux cas ; le contrôle « restant de migration » posait la même mauvaise question et a été corrigé avec elles
|
||||
- La liste noire de l'anonymisation passait son SQL à psql en UN seul argument, et Linux plafonne un argument à 131 072 octets : le mode qui couvre le plus de tables était justement celui qui cassait, sur « OSError: [Errno 7] Argument list too long ». Le SQL passe désormais par un fichier avec `-f`, qui garde le `--single-transaction` que l'entrée standard aurait perdu en silence. Les colonnes texte à longueur déclarée sont tronquées par `left(…, n)`, l'identifiant en TÊTE pour qu'une colonne unique le reste, et tous les identifiants sont cités — Odoo laisse nommer un champ user ou order. Écarter toute colonne sous contrainte CHECK laissait le nom du partenaire intact : sur du texte, seules les contraintes de FORME sont hors de portée, et un UPDATE qui échoue n'écrit rien
|
||||
- L'anonymisation respecte ce qu'une valeur SIGNIFIE, là où le type SQL dit seulement ce qu'elle EST. Odoo déclare `parent_path` en `char` mais y range un chemin d'identifiants — 1/7/12/ — reparsé aussitôt par `int()` : un nom écrit là casse le premier chargement de page ; tout modèle `_parent_store` en porte un, et `account_payment_term.days_next_month` passe de même à `int()`. Les deux noms connus sont écartés, puis le contenu lui-même est sondé : une colonne dont chaque valeur est un chemin reste intacte, même dans un module maison, et les barres obliques sont exigées, si bien qu'une valeur tout en chiffres n'échappe pas à l'anonymisation en passant pour un identifiant. Les nombres étaient tirés uniformément sur 0 à 1000, ce qui est faux pour tout nombre borné par son usage — heures, pourcentages, taux : un `float` qui porte une heure de la journée, tiré hors de 0..23, fait lever « ValueError: hour must be in 0..23 » à l'affichage de la fiche, borne qui vit dans le Python d'Odoo là où aucune contrainte PostgreSQL ne la déclare. Le tirage respecte désormais la seule borne que les DONNÉES déclarent, leur propre étendue, min et max mesurés par table ; 0 à 1000 ne reste que pour une colonne vide ou impossible à sonder
|
||||
- Le lanceur unitaire ne prenait que sept préfixes de noms, « le reste demandant une base de données », et exécutait 1131 tests là où les 3703 du répertoire passent avec PostgreSQL injoignable ; il balaie test/test_*.py. Deux formes rendent un fichier muet sans erreur — unittest.main() posé en plein milieu, qui sort avant même que la seconde moitié soit définie (quatre fichiers, 87 tests), et l'absence de bloc __main__, qui compte zéro (huit fichiers, 174 tests) — et une garde refuse désormais les deux, ainsi que tout retour à une liste de préfixes
|
||||
- Le vérificateur du transfert mobile n'acceptait que la disposition en packs, quand une compilation réelle livre un tar.gz par dépôt. Il échouait sur `<slug> : index.json absent` et arrêtait `compile_and_run.sh` avant l'APK — depuis le 2026-08-20, pour quiconque est sur le main mobile actuel. Il accepte désormais les deux dispositions, et prouve la présence de CHAQUE fichier promis plutôt qu'un échantillon de vingt : traverser les 139 archives coûte 6 s, et 124 350 fichiers sont comptés
|
||||
- Le test du bundle gardait la limite d'entrées du ZIP en exigeant un champ `chunk` sur chaque fichier, c'est-à-dire la disposition en packs plutôt que la limite elle-même. Il compte maintenant les entrées que portera l'APK — 278 pour un plafond de 65 535 — si bien que les deux dispositions passent et qu'un retour au fichier-par-source échoue toujours
|
||||
|
||||
|
|
@ -121,6 +137,7 @@ Recréer l'environnement virtuel, utiliser le guide d'installation depuis l'outi
|
|||
- Le pont NAT s'écrivait avant de savoir si le NAT existe. Six lignes d'iptables et « code de retour 1 » arrivaient après que la strophe soit déjà posée dans /etc/network/interfaces, et rien dans ce bruit ne disait qu'il fallait redémarrer : l'hôte tournait le noyau cloud de Debian, dépouillé de netfilter. C'est notre propre install_proxmox.sh qui produit cet état, donc une Proxmox imbriquée fraîchement installée y est TOUJOURS — le garde va désormais là où la conséquence est, et non à la confirmation de l'hôte
|
||||
## Retiré
|
||||
|
||||
- Le contrôle de résidus qui jugeait cassée une langue dont la ligne res_lang porte active à NULL — listée nulle part, plus réactivable. Faux dans la source 18 : un domaine ('active','=',False) compile en (IS NULL OR = FALSE), l'action du menu Langues porte active_test: False, le tri passe par COALESCE(active, FALSE), et la lecture rend bool(value). C'est Odoo lui-même qui écrit ce NULL, active étant un booléen sans défaut et res.lang.csv n'ayant pas cette colonne, soit un NULL par langue ajoutée au catalogue — « zéro avant, non nul après » ne suffit donc pas à déclarer un résidu. Un test refuse désormais une clé de verdict que plus rien ne définit
|
||||
- Le support d'Ubuntu 20.04 et 22.04, sur toutes les architectures : pikepdf réclame qpdf 12.2, dont la compilation exige C++20, quand focal livre GCC 9 et ne publie pas de `g++-10` pour s390x
|
||||
|
||||
## Modifié
|
||||
|
|
|
|||
17
CHANGELOG.md
17
CHANGELOG.md
|
|
@ -15,6 +15,14 @@ Recreating the virtual environment, use installation guide from tool `make`.
|
|||
|
||||
## Added
|
||||
|
||||
- A `pre-commit` hook lists the comments worth re-reading in the files being staged, and never blocks: over the repository's own sources, 373 files yield 463 signals, and a blocking check at that scale gets uninstalled the following week. The tool behind it, `script/analyse/check_comment_hygiene.py`, reports two families of unequal certainty — identifying data, an address, an e-mail or an account path, which is a finding; and narrative, a witness marker, an absolute date or the first person, which is a signal to RE-READ, since it cannot know whether the sentence states a durable fact. It reads comments and docstrings, `#` lines and shell trailing comments alike, skips vendored code, and falls back on a line scan when a source will not parse, an empty report otherwise declaring clean a file it never read. Exit codes follow the repository convention: 0 nothing to report, 1 findings, 2 the tool failed
|
||||
- The TODO menu shows the context an assistant is given, scattered as it is over six sources: instructions, rules, skills, deployed commands, git hooks and memory. Each deployed command is compared against its repository template, ignoring the git identity lines the deployment substitutes, so a stale copy shows up where a strict equality would declare them all stale. Nothing from `private/` is reported, not even a count: naming a file whose purpose is to hold what must not go out amounts to pointing at it
|
||||
- Duplicating a database and neutralising it for good: duplication goes through Odoo's `exp_duplicate_database` rather than `CREATE DATABASE … TEMPLATE`, which copies the tables and nothing else. Only Odoo drops the source's open connections — one Odoo shell left open is enough for PostgreSQL to refuse — regenerates `database.uuid`, copies the filestore, and runs the `neutralize.sql` files of the installed modules. The repository's in-house modules obtained none of the four, and one of them opened a door: deleting every `ir.mail_server` makes Odoo fall back on the configuration file's `smtp_server`, where Odoo's own placeholder server exists precisely to plug that hole. Odoo's neutralisation begins at 16; from 12 to 15 the copy falls back on the repository's long-standing `update_prod_to_dev.sh`, which sets no `is_neutralized`, disables no cron and leaves the payment keys, but does remove the mail servers and lay down a development account. The route taken is ANNOUNCED at run time, a copy whose route is unknown being unjudgeable, and a missing script fails the copy rather than letting it come out raw while announcing itself neutralised
|
||||
- The migration quality screen says whether a run succeeded, where it only compared the tiers: every verdict shows, 12 through 18 — the only way to see that a failure at one tier was recovered higher up — read from the progression file and tied to the ODOO tier, not to the driver's counter, which is off by one. It names where the traces live, config.conf leaving logfile= empty and Odoo's output dying with the terminal; it shows the step-log passage around each command, keeps by tee what it launches itself and re-reads that without rerunning; and it runs six review steps from « r », asking before it switches the checkout, since replaying a test from another tier opened the database with the wrong version, which writes before it fails. A status is read the way the tools write it — 0 nothing to report, 1 findings, 2 the tool failed — so nothing is painted red where nothing failed. Output is captured through a pseudo-terminal, never a pipe: smoke_public_url requires stdin AND stdout to be terminals and, behind a pipe, silently stops offering the COW view repair; nine runs go through it, two stay out, pty.spawn being born 0×0 where a full-screen tool would lay out on nothing
|
||||
- Three checks join the migration review, each for what a tier destroys without reporting a single failure. The manifest holes: an addons repository absent from one tier's manifest does not exist on disk during that step, so Odoo declares its modules missing, the driver offers to delete them, and the feature leaves with them — only the hole counts, present before and after, absent in between, which turns 35 candidates into 19 real omissions instead of 46% noise. The tree view type, removed in Odoo 18 with no shim, is read in the SOURCES, where every other review tool reads the database and a module that never installed leaves nothing; the word is still a valid identifier, so of 465 occurrences only 80 break, and lxml and ast decide by the literal's position, never a regex. The chart drift: a bump reloads the localisation template in silence — three of the core l10n scripts call try_loading() without force_create=False, so every account the template cannot match by code is CREATED, and the groups thus added reclassify the existing chart. An absolute count says nothing there, only the GAP between two tiers of one migration can be judged, and the tool prescribes replaying the tier rather than repairing: its natural deletion key also catches accounts re-matched by code
|
||||
- run.sh warms the registry over HTTP while the server starts. Odoo loads a database's registry only on the FIRST request that concerns it, and on a migrated database whoever opens the page waits tens of seconds; the probe takes that time instead and stops at the first answer, a 303, a 404 or a 500 all proving the registry is loaded. It cannot get in the way: it ALWAYS returns 0, dies with run.sh through a trap, gives up after two minutes, and takes the port from the command line, then config.conf, then the log, exact even when the requested port was taken — an empty or wildcard listen interface is probed on the loopback. `--erplibre-disable-warmup-http` turns it off and is the only flag STRIPPED before odoo_bin.sh, which Odoo rejects; `--no-http` and `--stop-after-init` turn it off too and go through, there being nothing to wake when no one listens
|
||||
- A writing convention for what stays in git. A commit subject read alone, with no diff and no body, must say which part of the system changes and what is now different there — the symptom, the quoted error and the metaphor are EVIDENCE, and evidence belongs in the body. A comment has the CODE for subject, in the present of what it does, so a sentence whose subject is an incident, a machine, a date or a person goes to the unversioned `tasks/`, while the failure mode the code prevents stays. Nothing identifying outside `private/` — no customer, real database, host, address, e-mail or account path — and an example illustrating that ban is invented rather than borrowed, a test freezing forever what it holds. A measurement that establishes a durable fact stays, stripped of its date and its operator; the reading of what answered that day goes
|
||||
- A `commit-msg` hook refuses the mechanical part of that writing convention and nothing more: no tag, a subject over 72 characters, a subject opening on a quotation, a body over 10 lines for one language, an IP address, an e-mail, an account path, or a term from a forbidden-names list that lives outside git since the list is what it protects — absent, that last check stays silent. It counts characters, not bytes, or a 72-character French subject would fall on its accents; it excludes the trailers and the `--cleanup=scissors` diff; and its refusal names `git commit --no-verify`, a guard rail that refuses too much getting uninstalled. Whether the subject says what the code is about stays a judgement no hook makes. The predicate telling a fleet address from an Odoo manifest version, a loopback, a mask, a network address or an RFC 5737 documentation block is shared with the comment check, two predicates for one question drifting apart. Its 40 tests weigh the acceptances — a « Merge branch », a rebase fixup — as much as the refusals
|
||||
- `long_test/` — tests that create real machines and take hours, kept out of `test/` so the unit runner stays runnable in seconds. `deep_proxmox.py` stacks Proxmox in Proxmox, `deep_qemu.py` stacks QEMU in QEMU, and they share one engine. Measured on 28 cores: three levels cost 34 minutes, the fourth 4 h 20 of boot plus 7 h 18 of install — everything there is 15 to 30 times slower, and that is where the vendors stop documenting nesting. The depth is a parameter and defaults to three, because three works
|
||||
- deep_qemu proves KVM at every level instead of assuming it: `deploy_qemu.py` never passes `--cpu host-passthrough` and, when /dev/kvm is missing, it does not fail — it sets `--virt-type qemu` and creates a fully EMULATED VM, seven and a half minutes to boot, with no exit code to say so. Unguarded, the descent would measure stacked TCG while believing it measured nesting. Each level must show `/dev/kvm`, `nested=Y` and a child domain in `type='kvm'`; what was not read counts as NO
|
||||
- Both long tests take `--hote` to start from a machine you already own, rather than creating a head VM to host a hypervisor you have on hand — that costs five minutes AND one level of nesting. The plan is then sized on the ROOT, read over ssh; the delays count ABSOLUTE depth; and the root is never a level reached, never destroyed, and its ~/.ssh/config entry is never removed
|
||||
|
|
@ -99,12 +107,20 @@ Recreating the virtual environment, use installation guide from tool `make`.
|
|||
|
||||
## Changed
|
||||
|
||||
- Staging names the files, never `git add -A`. The sweep stages everything untracked, and this repository keeps two directories untracked ON PURPOSE: `private/`, the only place allowed to hold customer data, and `tasks/`, where the convention sends the investigation precisely because it is not versioned. It also swallows whatever else is in flight in the checkout, under a subject that does not cover it; `git add -p` stages the hunks when one file carries two subjects
|
||||
- A countdown prompt gives 15 seconds to decide, where five were not enough to READ the question: the countdown exists so a run can be left unattended, not to go fast, and too short it does the opposite — the answer comes by reflex, or a default no one read is taken. A restored database is named after the backup file, which already carries a telling name, rather than « test », under which successive migrations all landed on one name. The name is sanitised, since it ends up in a createdb, and capped at 41 characters: the driver appends « _neutralize_upgrade_18 » and PostgreSQL truncates at 63, which would put two tiers on the same name. A remote download keeps the name the server gave
|
||||
- todo.py split into nine files, one per subject, with a shared base per form. It carried 9 500 lines more than a file should and every subject went through it; the deployment forms repeated the same field-and-validation machinery, so a fix in one never reached the others. No behaviour changes
|
||||
- Branch, profile and type are chosen per VM. They were global, which meant switching everything to deploy a single machine differently
|
||||
- One shared base describes the guest system, where each form used to describe it again
|
||||
|
||||
## Fixed
|
||||
|
||||
- `odoo_bin.sh db --drop` failed with AccessDenied at every migration tier, and the clone then hit « database already exists »: db_restore.py reads the repository's config.conf, sees admin_passwd = admin and therefore sends no master password, while odoo_bin.sh passed no « -c », so Odoo read ~/.odoorc and its hashed one. ODOO_RC closes that seam in one place instead of twenty call sites, versions 12 to 18 reading it after « -c » and before ~/.odoorc, so an explicit choice still wins
|
||||
- The account.root SQL view Odoo 17 creates is dropped before the load into 18, where the model carries _auto = False and _table_query = '0', so its name enters no query and the missing-table check skips it. The view is not merely dead but WRONG, built on the code column the 18 ORM no longer writes, and it is the sole pin holding the two legacy columns database_cleanup fails on — no DROP COLUMN, OpenUpgrade still reading them afterwards
|
||||
- The migration repair created pricelists that should not exist, in two ways. It asked `env.user.has_group()`, which says yes as soon as the caller belongs to the group — and the migration adds it along the way — where the settings checkbox reads something else entirely: what `base.group_user` IMPLIES. Deciding on the caller built a pricelist in a database whose feature is off, and Odoo then warned on every opening of the settings that it would archive it. And a pricelist shared across companies, with an empty `company_id`, did not count as belonging to the company: the repair saw a company without a list and made an empty duplicate beside the existing one, on a database that had lost nothing. Both now read the group implication and the tool's own `pricelist_missing` detector, which already tells the two cases apart; the migration-residue check asked the same wrong question and was corrected with them
|
||||
- The anonymisation blacklist handed its SQL to psql as a single argument, and Linux caps one argument at 131 072 bytes: the mode that covers the most tables was exactly the one that broke, on « OSError: [Errno 7] Argument list too long ». The SQL now travels through a file with `-f`, which keeps the `--single-transaction` that standard input would have silently dropped. Text columns with a declared length are truncated by `left(…, n)`, the id FIRST so a unique column stays unique, and every identifier is quoted — Odoo allows a field named user or order. Skipping every column under a CHECK constraint had left the partner name untouched: on text, only FORM constraints are out of reach, and an UPDATE that fails writes nothing
|
||||
- Anonymisation respects what a value MEANS, where the SQL type says only what it IS. Odoo declares `parent_path` as `char` but stores an id path in it — 1/7/12/ — parsed straight back with `int()`, so a name written there breaks the first page load; every `_parent_store` model carries one, and `account_payment_term.days_next_month` goes to `int()` the same way. The two known names are skipped, then the content itself is probed: a column whose every value is a path is left alone, even in an in-house module, and the slashes are required, so a value of pure digits does not escape anonymisation by passing for an id. Numbers were drawn uniformly over 0 to 1000, which is wrong for every number bounded by its usage — hours, percentages, rates: a float holding an hour of day, drawn outside 0..23, makes displaying the record raise « ValueError: hour must be in 0..23 », a bound that lives in Odoo's Python where no PostgreSQL constraint declares it. The draw now respects the only bound the DATA declares, its own range, min and max measured per table; 0 to 1000 remains solely for a column that is empty or cannot be probed
|
||||
- The unit runner took seven filename prefixes, « the rest needing a database », and ran 1131 tests where all 3703 in the directory pass with PostgreSQL unreachable; it globs test/test_*.py. Two shapes make a file silent without an error — unittest.main() placed mid-file, which exits before the second half is even defined (four files, 87 tests), and no __main__ block at all, which counts zero (eight files, 174 tests) — and a guard now refuses both, along with any return to a list of prefixes
|
||||
- The mobile bundle check accepted only the pack layout, when a real build ships one tar.gz per repository. It failed on `<slug> : index.json absent` and stopped `compile_and_run.sh` before the APK — since 2026-08-20, for anyone on the current mobile main. It now accepts both layouts, and proves the presence of EVERY promised file rather than a sample of twenty: streaming all 139 archives costs 6 s, and 124 350 files are accounted for
|
||||
- The bundle test guarded the ZIP entry limit by demanding a `chunk` field on every file, which is the pack layout rather than the limit itself. It now counts the entries the APK will carry — 278 against a ceiling of 65 535 — so either layout passes and a return to file-per-source still fails
|
||||
|
||||
|
|
@ -119,6 +135,7 @@ Recreating the virtual environment, use installation guide from tool `make`.
|
|||
- The NAT bridge was written before knowing whether NAT exists. Six lines of iptables and "return code 1" came after the stanza had already gone into /etc/network/interfaces, and nothing in that noise said a reboot was needed: the host was running Debian's cloud kernel, stripped of netfilter. Our own install_proxmox.sh produces that state, so a freshly installed nested Proxmox is ALWAYS in it — the guard now sits where the consequence is, not at host confirmation
|
||||
## Removed
|
||||
|
||||
- The residue check that called a language broken when its res_lang row has active at NULL — listed nowhere, no longer re-enablable. False in the 18 source: an ('active','=',False) domain compiles to (IS NULL OR = FALSE), the Languages menu action carries active_test: False, sorting goes through COALESCE(active, FALSE), and reading returns bool(value). Odoo writes that NULL itself, active being a Boolean with no default and res.lang.csv having no such column, which makes one NULL per language added to the catalogue — so « zero before, nonzero after » is not enough to declare a residue. A test now refuses a verdict key that nothing defines any more
|
||||
- Ubuntu 20.04 and 22.04 support, on every architecture: pikepdf needs qpdf 12.2, whose build requires C++20, while focal ships GCC 9 and publishes no `g++-10` for s390x
|
||||
|
||||
## Changed
|
||||
|
|
|
|||
Loading…
Reference in a new issue