Commit graph

11 commits

Author SHA1 Message Date
76fb9198cb [ADD] migration: look at a COW copy before agreeing to give it up
The prompt asked whether to neutralize copies without showing what they hold.
Answering meant giving up a customization sight unseen — often three lines, an
id and a container width, sometimes a whole page, and nothing told them apart.

« v » now shows both halves of the question. What the copy changed, diffed
against the module view it shadows: on the database at hand, 5 lines added and
3 removed, two CSS anchors and a container width. And why it breaks, by
showing the declaration in each version — portal.frontend_layout is a
standalone template in 12.0 and inheritance specs in 13.0, which is the whole
explanation. « w » is the same two, full screen, space to switch.

The current version comes from ir_module_module, not .odoo-version: the
checkout is switched to the target before this runs, so reading the file
compared the target with itself and printed the same declaration twice. That
is what it did until it was run against a real migration.

--list says which copies a past neutralization put aside. A renamed key is
invisible in the interface, so without it the only trace was remembering.

Checked on the VM mid-migration: both views on view 2670, the screen builds
headless and toggles, --list reports and reports nothing when there is
nothing. A missing database now exits 2 with a message instead of a traceback.

--- FR ---

L'invite demandait de neutraliser des copies sans montrer ce qu'elles
contiennent. Répondre revenait à renoncer à une personnalisation sans l'avoir
vue — souvent trois lignes, un id et une largeur de conteneur, parfois une
page entière, et rien ne les distinguait.

« v » montre désormais les deux moitiés de la question. Ce que la copie a
changé, comparé à la vue de module qu'elle masque : sur la base en cours, 5
lignes ajoutées et 3 retirées, deux ancres CSS et une largeur. Et pourquoi ça
casse, en affichant la déclaration dans chaque version —
portal.frontend_layout est un gabarit autonome en 12.0 et des consignes
d'héritage en 13.0, ce qui est toute l'explication. « w » donne les deux en
plein écran, espace pour basculer.

La version courante vient d'ir_module_module, pas de .odoo-version : le
checkout est basculé sur la cible avant cette étape, donc lire le fichier
comparait la cible avec elle-même et affichait deux fois la même déclaration.
C'est ce qu'il faisait jusqu'à l'essai sur une vraie migration.

--list dit quelles copies une neutralisation passée a mises de côté. Une clé
renommée est invisible dans l'interface ; sans cela, la seule trace était de
s'en souvenir.

Vérifié sur la VM en cours de migration : les deux vues sur la vue 2670,
l'écran se construit sans terminal et bascule, --list rapporte et ne rapporte
rien quand il n'y a rien. Une base absente sort en 2 avec un message plutôt
qu'une trace d'appel.

Assisted-by: Claude Opus 5
2026-08-17 01:25:23 -04:00
b28b734338 [ADD] migration: see and repair the website COW views
A copy-on-write view freezes the module view it came from; the module moves
on and the upgrade dies hours later on a missing anchor. These tools
predict, snapshot, diff, neutralize and reset them. The migration screen
gains the real state of each step, replay from any of them, and statistics.

--- FR ---

Une vue copy-on-write fige la vue de module dont elle vient ; le module
évolue et la mise à niveau meurt des heures plus tard sur un point
d'ancrage absent. Ces outils les prévoient, photographient, comparent,
neutralisent et réinitialisent. L'écran de migration gagne l'état réel de
chaque étape, la reprise depuis n'importe laquelle, et des statistiques.

Assisted-by: Claude Opus 5
2026-08-10 03:10:50 -04:00
133c1ce1f9 [FIX] script todo upgrade: don't create branch if already exist 2026-08-07 02:11:11 -04:00
d8749422cd [FIX] todo upgrade: download_database_backup_cli lives on db_manager
Choosing « remote » as the migration source raised AttributeError: the method
had moved to DatabaseManager, and todo_upgrade still called it on the TODO
object. The remote path was therefore unusable — the only way to start a
migration from a production backup rather than a local zip.

--- FR ---

Choisir « remote » comme source de migration levait une AttributeError : la
méthode avait été déplacée vers DatabaseManager, et todo_upgrade l'appelait
toujours sur l'objet TODO. Le chemin distant était donc inutilisable — le seul
moyen de démarrer une migration depuis une sauvegarde de production plutôt que
depuis un zip local.

Assisted-by: Claude Opus 5
2026-08-07 02:10:50 -04:00
4972add36f [FIX] todo upgrade wrong method get_odoo_version 2026-03-29 14:51:02 -04:00
1e731114f5 [IMP] script: update copyright year to 2026
Reflect the current year in all TechnoLibre
license headers across script/, test/, and docker/.

Generated by Claude Code 2.1.74 model claude-sonnet-4-6

Co-Authored-By: Mathieu Benoit <mathben@technolibre.ca>
2026-03-11 23:16:05 -04:00
0a7bca4801 [UPD] script todo_upgrade support odoo --neutralize 2026-03-07 00:48:08 -05:00
54f8ba0feb [UPD] script execute to share exec_command_live 2026-02-13 04:07:44 -05:00
9769bc83b5 [FIX] todo upgrade: copying database when missing 2026-01-05 07:52:30 -05:00
41fbc39c21 [FIX] script config: support merge dict configuration between 3 config
- fix upgrade when missing log
2025-11-11 00:07:17 -05:00
cbc43fde3c [IMP] todo support odoo upgrade
- add example odoo test
- prevent delete production file with validation
- add makefile with selenium
- script prod to dev uninstall module after installation
- adapt todo with private directory
- script to download remote database
- TODO show documentation for migration
2025-10-31 01:43:26 -04:00