[FIX] finalize_db: detach `ir_filters pointing to deleted ir_actions`

OpenUpgrade migrations can delete and recreate ``ir_actions`` records with
new ids, leaving ``ir_filters.action_id`` (custom user filters) pointing to
a now-missing action. Opening the custom filters list then fails with
"Record does not exist or has been deleted (ir.actions.actions(<id>,))"
when Odoo resolves the ``action_id`` many2one ``display_name``.

Detach such filters (set ``action_id = NULL``) as a final, version-agnostic
cleanup step: the filter stays usable, only the broken action link is
dropped. Placed in ``finalize_db.sh`` so the check runs whatever the target
version, with an integrated re-count that warns if orphans remain.

.gitignore

@@ -1 +1,2 @@
 final_404_addons
+migration.log

README.md

@@ -413,10 +413,30 @@ The script works on a **copy** of the original database. You can restart as many
 
 ### Viewing Detailed Logs
 
-Odoo/OpenUpgrade logs are displayed in real-time. For a problematic migration:
+All output (scripts, Docker containers, OpenUpgrade logs) is automatically saved to `migration.log` at the project root. The file is overwritten at the start of each run (full migration or resume).
+
+```bash
+# Follow live output while also saving to file (already done automatically)
+tail -f migration.log
+
+# Search for errors after the fact
+grep -i error migration.log
+
+# View with ANSI colors preserved (less handles CRLF line endings natively)
+less -R migration.log
+
+# Plain text output without CRLF artifacts
+cat migration.log | col -b
+```
+
+> **Note:** `migration.log` is recorded via a pseudo-TTY (`script`), which preserves
+> color output in the terminal. As a side effect, the file uses `\r\n` line endings.
+> Use `less -R` or `col -b` for clean viewing.
+
+For a problematic migration:
 
 1. Note the version where the error occurs
-2. Check the logs to identify the problematic module/table
+2. Check `migration.log` to identify the problematic module/table
 3. Add a fix in the `pre_upgrade.sh` for that version
 4. Restart the migration
 

scripts/finalize_db.sh

@@ -12,17 +12,6 @@ CLEANUP_SQL=$(cat <<'EOF'
 DROP SEQUENCE IF EXISTS base_registry_signaling;
 DROP SEQUENCE IF EXISTS base_cache_signaling;
 
--- Reset website templates to their original state.
--- Views with arch_fs (file source) that have been customized (arch_db not null)
--- are reset to use the file version, EXCEPT for actual website pages which
--- contain user content that must be preserved.
-UPDATE ir_ui_view
-SET arch_db = NULL
-WHERE arch_fs IS NOT NULL
-  AND arch_fs LIKE 'website/%'
-  AND arch_db IS NOT NULL
-  AND id NOT IN (SELECT view_id FROM website_page);
-
 -- Purge compiled frontend assets (CSS/JS bundles).
 -- These cached files reference old asset versions and must be regenerated
 -- by Odoo after migration to avoid broken stylesheets and scripts.
@@ -34,6 +23,76 @@ EOF
 )
 query_postgres_container "$CLEANUP_SQL" "$DB_NAME"
 
+# ────────────────────────────────────────────────────────────
+# Fix orphan ir_filters pointing to deleted ir_actions
+#
+# During OpenUpgrade migrations, ir_actions records can be deleted and
+# recreated with new ids, while ir_filters.action_id (custom user filters)
+# still points to the old, now-missing action. When a user opens the custom
+# filters list, Odoo tries to resolve the display_name of the many2one
+# action_id and raises "Record does not exist or has been deleted
+# (ir.actions.actions(<id>,))". We detach such filters (set action_id = NULL),
+# which keeps the filter usable and only drops the broken action link.
+# ────────────────────────────────────────────────────────────
+FIX_ORPHAN_FILTERS_SQL=$(cat <<'EOF'
+DO $$
+DECLARE
+    orphan_count INTEGER;
+    remaining INTEGER;
+BEGIN
+    SELECT COUNT(*) INTO orphan_count
+    FROM ir_filters f
+    LEFT JOIN ir_actions a ON a.id = f.action_id
+    WHERE f.action_id IS NOT NULL AND a.id IS NULL;
+
+    IF orphan_count > 0 THEN
+        UPDATE ir_filters f
+        SET action_id = NULL
+        FROM (
+            SELECT f2.id
+            FROM ir_filters f2
+            LEFT JOIN ir_actions a ON a.id = f2.action_id
+            WHERE f2.action_id IS NOT NULL AND a.id IS NULL
+        ) orphans
+        WHERE f.id = orphans.id;
+        RAISE NOTICE 'Detached % orphan ir_filters pointing to deleted ir_actions', orphan_count;
+    ELSE
+        RAISE NOTICE 'OK: no orphan ir_filters to fix';
+    END IF;
+
+    -- Verification
+    SELECT COUNT(*) INTO remaining
+    FROM ir_filters f
+    LEFT JOIN ir_actions a ON a.id = f.action_id
+    WHERE f.action_id IS NOT NULL AND a.id IS NULL;
+
+    IF remaining > 0 THEN
+        RAISE WARNING 'Still % orphan ir_filters remaining after fix', remaining;
+    END IF;
+END $$;
+EOF
+)
+echo "Fixing orphan ir_filters pointing to deleted ir_actions..."
+query_postgres_container "$FIX_ORPHAN_FILTERS_SQL" "$DB_NAME"
+
+# Reset modules still marked as 'to upgrade' before launching the Odoo shell
+# scripts below. Loading the registry in `odoo shell` re-triggers the upgrade
+# of these modules, which can fail on broken views (e.g. website_sale
+# TypeError). The controlled `-u all` at the end of this script performs the
+# real update afterwards. We deliberately do NOT touch 'to install' modules:
+# forcing them to 'installed' would skip their install scripts entirely.
+#
+# Uncomment the SELECT below to trace which modules were pending upgrade
+# before we neutralize their state (useful if the `-u all` above is removed).
+# query_postgres_container "
+# SELECT name FROM ir_module_module WHERE state = 'to upgrade' ORDER BY name;
+# " "$DB_NAME" || true
+query_postgres_container "
+UPDATE ir_module_module
+SET state = 'installed'
+WHERE state = 'to upgrade';
+" "$DB_NAME" || true
+
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
 
 PYTHON_SCRIPT="${SCRIPT_DIR}/lib/python/fix_duplicated_views.py"
@@ -77,7 +136,7 @@ fi
 
 
 # Launch Odoo with database in finale version to run all updates
-run_compose --debug run "$ODOO_SERVICE" -u all --log-level=debug --stop-after-init --no-http
+run_compose --debug run "$ODOO_SERVICE" -u all --log-level=debug --stop-after-init --no-http --load=base,web,openupgrade_framework
 
 echo ""
 echo "Running post-migration view validation..."

upgrade.sh

@@ -4,6 +4,13 @@ set -euo pipefail
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 source "${SCRIPT_DIR}/lib/common.sh"
 
+readonly LOG_FILE="${SCRIPT_DIR}/migration.log"
+if [[ -z "${_MIGRATION_LOGGING:-}" ]]; then
+    rm -f "$LOG_FILE"
+    export _MIGRATION_LOGGING=1
+    exec script -q -c "$(printf '%q ' "$0" "$@")" "$LOG_FILE"
+fi
+
 ####################
 # USAGE & ARGUMENTS
 ####################
@@ -225,3 +232,4 @@ log_step "POST-UPGRADE PROCESSES"
 "${SCRIPT_DIR}/scripts/finalize_db.sh" "$FINALE_DB_NAME" "$FINALE_SERVICE_NAME"
 
 log_step "UPGRADE PROCESS ENDED WITH SUCCESS"
+log_info "Full logs available at: ${LOG_FILE}"

versions/15.0/known_changes.yaml

@@ -8,6 +8,7 @@ obsolete:
 # Modules merged into Odoo Core in version 15.0
 merged_in_core:
   - project_category
+  - project_deadline
 
 # Modules renamed in version 15.0
 renamed: