Mathieu Benoit
9a7b8cb36f
Le même chiffre veut dire deux choses opposées. Zéro cron actif est le succès attendu d'une copie et une panne totale sur une production. Un rapport qui ignore cela crie au loup sur ce qu'on vient de demander, et l'on cesse de le lire. L'attente est donc déclarée, copy ou live, et chaque contrôle dit ce qu'il juge sous l'une et sous l'autre. Deux contrôles ont été ÉCARTÉS sous copy après mesure : sur la base 12 d'origine, jamais démarrée, 11 crons étaient déjà en retard et db_backup déjà vide — notre propre update_prod_to_dev les efface. Les afficher en rouge aurait été du bruit ; en vert, un mensonge. Ils sont montrés non jugés, avec la raison. Le code Python en base a été mesuré et abandonné : 132 actions serveur, zéro citant un modèle inexistant, et les 3 « modèles sans table » sont ir.autovacuum et deux autres modèles abstraits d'Odoo. --- EN --- The same number means two opposite things. Zero active cron is the expected success of a copy and a total outage on production. A report that ignores this cries wolf over what was just requested, and stops being read. The expectation is therefore declared, copy or live, and each check states what it judges under either. Two checks were DROPPED under copy after measuring: on the untouched 12 source database, 11 crons were already late and db_backup already empty — our own update_prod_to_dev deletes them. Red would have been noise; green a lie. They are shown unjudged, with the reason. In-database Python was measured and dropped: 132 server actions, none naming a missing model, and the 3 "models without a table" are ir.autovacuum and two other Odoo abstract models. Assisted-by: Claude Opus 5 |
||
|---|---|---|
| .. | ||
| auto_ask.py | ||
| database_manager.py | ||
| deploy_form_lib.py | ||
| deploy_form_plan.py | ||
| kdbx_manager.py | ||
| logo_ascii.txt | ||
| migration_form.py | ||
| migration_stats.py | ||
| migration_status.py | ||
| migration_status_tui.py | ||
| proxmox_deploy_form.py | ||
| proxmox_menu.py | ||
| qemu_access.py | ||
| qemu_deploy.py | ||
| qemu_deploy_form.py | ||
| qemu_hardware.py | ||
| qemu_install.py | ||
| qemu_install_monitor.py | ||
| qemu_manage.py | ||
| qemu_menu.py | ||
| README.base.md | ||
| README.fr.md | ||
| README.md | ||
| source_todo.sh | ||
| textual_setup.py | ||
| todo.json | ||
| todo.py | ||
| todo_example.json | ||
| todo_file_browser.py | ||
| todo_i18n.py | ||
| todo_prefs.py | ||
| todo_telemetry.py | ||
| todo_upgrade.py | ||
| version_manager.py | ||
TODO is an assistant robot to use ERPLibre
Execute it with ./script/todo/todo.py or make todo.
For a new project, copy todo_example.json to private/todo/todo_override.json | private/todo/todo_override_private.json and edit it.
The mail/ package is the mail client reachable from Assistant > Mail:
several IMAP/SMTP accounts, a local cache, and a Textual TUI. See
../../doc/EMAIL.md.
Where the code lives
todo.py carries the menus and the general helpers. Everything around a
single subject sits in its own file, and the whole thing is assembled by
mixins on the TODO class — one file, one subject, its header states its
boundary.
| File | What it owns |
|---|---|
todo.py |
the menus, the configuration, the general helpers |
qemu_menu.py |
the QEMU/KVM menu, the image catalogue, the statistics |
qemu_deploy.py |
deciding then running a deployment |
qemu_install.py |
the recipes run inside a VM |
qemu_manage.py |
lifecycle, disks, hardware, cleanup, addresses |
qemu_access.py |
SSH, tunnels, consoles, Android emulator |
proxmox_menu.py |
the same, on a REMOTE Proxmox VE host |
The two deployment forms — libvirt here, Proxmox over there — ask the same questions, so they share a foundation rather than each holding a copy:
| File | What it owns |
|---|---|
deploy_form_lib.py |
pure logic (sizes, plan, totals, spec), the shared CSS, the resource-row factory, the progress view |
deploy_form_plan.py |
the plan's gestures: overrides, locks, copies, renaming, free values |
qemu_deploy_form.py |
what QEMU/KVM adds: desktops, tools, branches, install profiles |
proxmox_deploy_form.py |
what Proxmox adds: host, storage, bridge, VMID, address |
A form inherits PlanMixin and provides three hooks: which presets each
resource offers, the name a VM would fall back to, and what a lock freezes.
test_todo_deploy_form_lib.py fails if a form redefines a gesture the
foundation already carries — that is what keeps the architecture from drifting
back into two copies.