Jak Naprawić Błąd „Record Does Not Exist or Has Been Deleted” w Odoo

Wstęp

Komunikat „Rekord nie istnieje lub został usunięty” to jedno z tych powiadomień w Odoo, które pojawia się nagle i dezorientuje użytkownika — najczęściej w trakcie otwierania formularza, zatwierdzania dokumentu lub wykonywania automatycznego zadania.

Mimo dramatycznego brzmienia, rzadko oznacza faktyczne uszkodzenie danych; najczęściej sygnalizuje, że gdzieś jest złamane powiązanie lub brakuje odniesienia.

Wyjaśnijmy więc, co naprawdę się dzieje i jak bezpiecznie rozwiązać problem.

Co oznacza ten błąd

Błąd pojawia się, gdy Odoo próbuje odwołać się do rekordu po jego identyfikatorze (ID), który:

• Już nie istnieje
• Został usunięty
• Jest niedostępny z powodu uprawnień
• Należy do innej firmy/kontekstu wielofirmowego

Przykład:

record = self.env['res.partner'].browse(45)

Jeżeli rekord o ID 45 nie istnieje, Odoo wyrzuci wspomniany błąd.

Najczęstsze przyczyny

1. Odwołania do usuniętych rekordów

Pola Many2one mogą wskazywać na elementy, które zostały wcześniej skasowane.

Do takiej sytuacji dochodzi najczęściej po:

• Ręcznym usuwaniu danych
• Czyszczeniu danych testowych
• Nieudanych importach

2. Błędne mapowanie zewnętrznych ID

Przy integracjach z zewnętrznymi systemami trafiają czasem nieprawidłowe identyfikatory.

Gdy Odoo otrzyma:

{ "partner_id": 99999 }

A taki ID nie istnieje, pojawi się błąd.

3. Ograniczenia wielofirmowe

Rekord może istnieć, lecz nie być widoczny w aktualnym kontekście firmy.

Przełączenie na superużytkownika często ujawnia ukryty rekord.

4. Problemy po migracji lub aktualizacji

Po upgrade’ach modułów odniesienia mogą wskazywać na przestarzałe lub przebudowane rekordy.

Jak to naprawić

Krok 1 – Sprawdź, czy rekord istnieje

record = self.env['model.name'].browse(record_id)
if record.exists():
    # bezpieczne użycie

Krok 2 – Zweryfikuj prawa dostępu

Przetestuj scenariusz z kontem administratora.

Jeżeli admin widzi rekord, a zwykły użytkownik nie — problem leży w regułach dostępu.

Krok 3 – Oczyść pola relacyjne

Zlokalizuj osierocone Many2one i popraw lub wyzeruj ich wartości.

Krok 4 – Sprawdź integracje zewnętrzne

Przejrzyj:

• treść payloadów API
• logikę mapowania
• warstwę synchronizacji

Niespójne mapowanie ID to częsta przyczyna w systemach zintegrowanych.

Jak zapobiegać

• Unikaj wpisywania na stałe identyfikatorów
• Korzystaj z zewnętrznych identyfikatorów poprawnie
• Waliduj dane przyjmowane przez API
• Testuj migracje na środowisku staging
• Nie usuwaj rekordów, które są referencjonowane w innych miejscach

Jak Dasolo eliminuje problemy „Rekord nie istnieje”

Błąd „Record Does Not Exist” zwykle wynika z niespójności powiązań między modelami. Choć objawia się w interfejsie, przyczyna leży często w usuniętych rekordach, uszkodzonych relacjach lub niebezpiecznej manipulacji danymi poza ORM.

W Dasolo traktujemy ten komunikat jako sygnał strukturalny, nie jedynie incydent. Najczęściej odsłania on:

• Osierocone odniesienia relacyjne
• Niewłaściwe procesy usuwania
• Niedopasowania w integracjach
• Brak walidacji przed dostępem do rekordu
• Niespójne zarządzanie kontekstem wielofirmowym

Aby zapobiegać takim przypadkom, projektujemy systemy Odoo z kontrolowanym cyklem życia danych. Zamiast usuwać krytyczne wpisy, preferujemy archiwizację, a integralność referencyjną wymuszamy przez dobre praktyki ORM. Dzięki temu ograniczamy niespodziewane wyjątki "rekord nie znaleziony" w środowisku produkcyjnym.

Podsumowanie

Błąd „Record Does Not Exist” w Odoo pojawia się, gdy system próbuje dostać się do rekordu, który został usunięty lub nigdy nie powstał poprawnie. Zwykle nie chodzi o utratę danych jako taką, lecz o złamaną logikę relacji lub niebezpieczne operacje na bazie.

Utrzymując spójną architekturę relacji, weryfikując istnienie rekordu przed dostępem i unikając bezpośrednich operacji na bazie, deweloperzy znacząco zmniejszą częstotliwość tego błędu. W dobrze zaprojektowanych wdrożeniach Odoo integralność rekordów zapewniają kontrolowane procesy i przewidywalne zarządzanie danymi.

Rozwiązanie problemu na poziomie architektury nie tylko eliminuje jednorazowy błąd, lecz także zwiększa stabilność bazy i długoterminową niezawodność systemu.