Pole tylko do odczytu w Odoo to pozornie prosta funkcja: pokazuje wartość, lecz blokuje możliwość jej modyfikacji przez użytkownika z poziomu interfejsu.
Niezależnie czy widzisz przygaszone pole w formularzu jako końcowy użytkownik, czy projektujesz logikę w module — zrozumienie, dlaczego pole jest zablokowane, oszczędza czasu i zapobiega błędom.
Prawidłowe stosowanie pól readonly pomaga utrzymać spójność danych, chronić audytowalność procesów i upraszcza codzienną pracę zespołu.
Ten poradnik omawia zarówno praktyczne scenariusze biznesowe, jak i techniczne sposoby wdrożenia readonly w Odoo — przydatne zarówno dla administratorów, jak i programistów.
Czym jest pole tylko do odczytu w Odoo
Pole readonly w Odoo to element danych, który użytkownik może zobaczyć, ale nie może go bezpośrednio edytować w GUI — wartość istnieje, ale wejście użytkownika jest zablokowane.
W formularzach takie pola zwykle wyglądają jak zwykły tekst zamiast pól wejściowych; w wielu motywach mają także stonowany, „wyblakły” wygląd, który sugeruje brak możliwości zmiany.
W Odoo można ustawić zachowanie tylko do odczytu na dwóch poziomach: modelu danych (ORM/Python) i widoku (XML).
- Na poziomie pola (Python/ORM): atrybut readonly zadeklarowany w modelu sprawia, że pole jest zawsze nieedytowalne niezależnie od widoku.
- Na poziomie widoku (XML): readonly stosuje się tylko w danym widoku lub pod określonym warunkiem, pozostawiając pole możliwym do zapisu gdzie indziej.
To rozróżnienie ma znaczenie: ustawienie na poziomie ORM oznacza ochronę nie do obejścia z poziomu UI, natomiast ograniczenie w XML chroni jedynie dany kontekst interfejsu.
Readonly nie jest nowym typem pola — to atrybut, który można dodać do wszystkich standardowych typów Odoo: Char, Integer, Float, Many2one, Date itd., i służy do kontroli zachowania pól w czasie działania aplikacji.
Jak działa atrybut readonly
Aby w pełni pojąć konsekwencje readonly, warto rozważyć jednocześnie warstwę modelu danych (Python/ORM) i warstwę widoków (XML).
Readonly na poziomie ORM
W modelach Python można zadeklarować pole jako permanentnie readonly — typowym zastosowaniem są pola obliczane (computed), którym przypisuje się readonly=True i które użytkownik nie może edytować przez UI.
Takie ustawienie jest częścią API pól Odoo i działa globalnie, niezależnie od tego, które widoki pokazują dane pole.
Readonly zależny od stanu dokumentu
Popularny wzorzec to blokowanie pól w zależności od stanu dokumentu — np. gdy dokument wychodzi ze stanu roboczego i staje się zatwierdzony, odpowiednie pola są blokowane, by zachować historię zmian.
W starszych wersjach Odoo stosowano atrybut attrs w XML; nowsze wersje (np. Odoo 17) oferują bardziej zwięzłą, inline’ową składnię do definiowania warunków readonly bezpośrednio na elemencie pola.
Efekt jest prosty: podczas gdy dokument jest w szkicu, pole można edytować; po przejściu dalej w procesie pole zostaje zablokowane — to podstawowy mechanizm kontroli cyklu życia rekordów w Odoo.
Pola obliczane a readonly
Pola compute są domyślnie tylko do odczytu — Odoo zakłada, że ich wartość pochodzi z logiki obliczeniowej i nie powinna być nadpisywana ręcznie.
Jeśli pole obliczane ma być też przechowywane w bazie (store=True), staje się możliwe szybkie filtrowanie i sortowanie po nim bez ponownego przeliczania przy każdym zapytaniu, co poprawia wydajność wyszukiwania i raportowania.
Jak uczynić pole obliczane zapisywalnym
Gdy konieczne jest ręczne wprowadzanie wartości do pola compute, definiuje się metodę inverse, która określa, co zrobić przy zapisie. Bez inverse pole pozostanie readonly — to opcja dla bardziej zaawansowanych integracji w ORM.
Przykłady zastosowań biznesowych
Readonly występuje we wszystkich modułach Odoo — poniżej pięć praktycznych przykładów z codziennych procesów biznesowych.
1. CRM: zablokowanie danych przy wygranej/przegranej okazji
W CRM prognozowane przychody czy planowana data zamknięcia pozostają edytowalne podczas pracy nad leadem; po oznaczeniu jako Wygrane/Przegrane pola są blokowane, żeby zachować wiarygodność historii sprzedaży.
Dzięki temu nikt nie zmieni wyników retrospektywnie, co chroni analizy pipeline’u i raporty sprzedażowe przed zafałszowaniem.
2. Sprzedaż: ochrona linii zamówienia po potwierdzeniu
Po przejściu zamówienia ze stanu Szkic do Potwierdzonego linie zamówienia stają się nieedytowalne — zmiana produktu, ilości czy ceny wymaga jawnego cofnięcia do szkicu.
Wymuszanie takiego procesu tworzy ślad audytu i zapobiega przypadkowym korektom po potwierdzeniu zamówienia klientowi.
3. Magazyn: zamrożone ilości po walidacji przesunięć
W magazynie, po zatwierdzeniu operacji przyjęcia czy wydania, ilości wykonane są blokowane, co zabezpiecza wartość zapasów i spójność stanów między lokalizacjami.
Edycje po walidacji mogłyby cicho zniekształcić salda magazynowe i wywołać problemy przy rozliczeniach międzylokacyjnych.
4. Księgowość: zapisane dekretacje
W księgowości linie księgowe po zaksięgowaniu stają się nieedytowalne — to często wymóg prawny i jeden z fundamentów rzetelnego prowadzenia ksiąg.
Możliwość bezpośredniej edycji po zatwierdzeniu podważałaby wiarygodność sprawozdań finansowych i zwiększała ryzyko niezgodności z przepisami.
5. Produkcja: dane wykonania pracy po zamknięciu zlecenia
W produkcji po zakończeniu zlecenia produkcyjnego czas pracy i ilości wytworzone zostają zapisane jako readonly — kluczowe dla analiz kosztów i efektywności pracy maszyn oraz ludzi.
Tworzenie i modyfikacja pól readonly
Są dwie główne ścieżki konfiguracji pola readonly: bezkodowe narzędzie Odoo Studio lub tradycyjne podejście developerskie (Python + XML).
Korzystanie z Odoo Studio
Studio pozwala szybko dodać lub zmienić ustawienie readonly bez programowania — dobre rozwiązanie dla administratorów i konsultantów.
- Uruchom Odoo Studio z menu (ikona ołówka)
- Przejdź do formularza, w którym chcesz skonfigurować pole
- Kliknij pole, które chcesz zmodyfikować
- W panelu właściwości po prawej włącz opcję "Readonly"
- Zapisz i zamknij Studio
Studio umożliwia także ustawienie warunkowego readonly za pomocą wyrażeń domenowych — na przykład zablokowanie pola tylko przy określonym statusie, bez jednej linii kodu.
Zmiany wprowadzone przez Studio są zapisywane w bazie i zwykle bezpieczne przy aktualizacjach modułów — to szybki i bezpieczny sposób egzekwowania reguł danych.
Modyfikacje od strony Pythona — podejście techniczne
Dla deweloperów atrybut readonly ustawia się bezpośrednio w definicji pola w modelu Python — to standardowe użycie pól Odoo w kodzie modułu.
Możesz użyć readonly=True jako statycznego parametru albo states, by określić, w jakich stanach dokumentu pole ma być zapisywalne lub zablokowane.
To podejście jest przydatne, gdy dodajesz własne pola do istniejących modeli i chcesz utrzymać logikę blisko modelu danych zamiast rozpraszać ją po widokach.
Ustawienie readonly w XML widoku
Aby zablokować pole tylko w danym widoku, dodaj atrybut readonly do elementu pola w pliku XML widoku — standardowa praktyka w rozwoju Odoo.
Zaletą tej metody jest elastyczność: to samo pole może być edytowalne w jednym widoku, a zablokowane w innym, bez zmiany definicji modelu.
W Odoo 17 dostępna jest bardziej przejrzysta składnia warunków readonly niż starsze attrs, choć obie metody pozostają poprawne w zależności od wersji Odoo.
Zasady dobrych praktyk
Dobre stosowanie pól readonly polega na wybieraniu poziomu i momentu blokady zgodnie z realnymi potrzebami biznesu — poniżej najważniejsze wskazówki dla konsultanta.
1. Preferuj readonly na poziomie widoku, gdy kontekst się zmienia
Jeżeli pole ma być zablokowane tylko w określonych stanach lub widokach, stosuj readonly w XML — zachowasz elastyczność i umożliwisz zapisy z poziomu backendu lub integracji, gdy to konieczne.
2. Dopasuj warunki readonly do cyklu życia dokumentu
Reguły blokowania powinny odpowiadać logicznym punktom procesów — pola blokowane w momentach krytycznych zapobiegają błędom i są przewidywalne dla użytkowników.
3. Testuj z perspektywy różnych ról użytkowników
Atrybut readonly wchodzi w interakcję z uprawnieniami. Sprawdź zachowanie jako zwykły użytkownik i jako administrator — to uchroni przed niespodziankami wynikającymi z profili dostępu.
4. Łącz readonly z required tam, gdzie ma to sens
Czasem pole powinno być obowiązkowe w szkicu, a następnie zablokowane — kombinacja required i readonly w widoku dobrze realizuje ten wzorzec (np. daty dostawy, numery referencyjne).
5. Dokumentuj logikę readonly
Dodawaj komentarze w kodzie wyjaśniające powód blokady — przyszły deweloper musi znać biznesowe uzasadnienie, nie tylko techniczny zapis readonly=True.
6. Używaj Studio do szybkich, bezpiecznych zmian
Do prostych reguł Studio wystarcza i jest bezpieczne przy aktualizacjach. Zarezerwuj modyfikacje Pythona dla złożonych przypadków, które Studio nie obsłuży (np. skomplikowane zależności między wieloma polami).
Najczęstsze pułapki
Nawet doświadczeni użytkownicy popełniają błędy przy pracy z readonly — oto sytuacje, które mogą zaskoczyć.
Pomylenie ograniczenia widoku z zabezpieczeniem danych
Readonly ustawione w widoku nie blokuje zapisu przez API, XML-RPC, ani wywołania ORM w Pythonie — to ograniczenie UI, nie mechanizm bezpieczeństwa. Jeśli chcesz uniemożliwić zapis z każdego źródła, zabezpiecz pole na poziomie modelu lub przez reguły dostępu.
Zamknięcie pola na stałe tam, gdzie lepsze byłoby rozwiązanie warunkowe
Czasami łatwiej jest od razu ustawić readonly w modelu, ale jeśli użytkownicy muszą móc je edytować w określonych sytuacjach (np. przy cofnięciu dokumentu do szkicu), trwała blokada uniemożliwi poprawki i zaburzy procesy korygujące.
Zapominanie o metodach onchange
Jeśli pole readonly jest modyfikowane w metodzie onchange, możesz zobaczyć nieoczekiwane zachowania — wartości mogą chwilowo zmieniać się w UI, potem cofnąć lub wyrzucić błąd. Upewnij się, że logika onchange bierze pod uwagę stan readonly.
Niespójność w różnych widokach
Pole zablokowane w formularzu może być nadal edytowalne w widoku listy lub kanban, jeżeli te widoki nie zawierają tej samej reguły. Sprawdź wszystkie widoki, w których pole się pojawia.
Efekty uboczne przy dziedziczeniu standardowych modeli
Dodanie readonly=True do istniejącego pola w dziedzicznym module wpłynie na wszystkie widoki — również standardowe. Upewnij się, że taka zmiana jest przemyślana i nie zaburzy funkcjonowania innych rozszerzeń.
Podsumowanie
Pola readonly to podstawowe narzędzie w Odoo do prowadzenia użytkownika przez procesy, ochrony danych i wymuszania reguł biznesowych bez polegania wyłącznie na szkoleniach.
Najważniejsze jest dobranie właściwego poziomu blokady — widok kontra model — oraz dopasowanie warunków do rzeczywistego przebiegu pracy zespołu.
Niezależnie od tego, czy ustawiasz reguły w Odoo Studio, czy implementujesz je w Pythonie i XML, idea pozostaje ta sama: pokazać dane, ale chronić je przed niezamierzonymi zmianami.
Może nie są najgłośniejszym tematem w customizacji Odoo, ale mają duży wpływ na jakość wdrożenia i stabilność procesów.
W Dasolo wspieramy firmy we wdrożeniach, dostosowaniach i optymalizacji Odoo w różnych branżach. Jeśli potrzebujesz pomocy przy konfiguracji pól, projektowaniu bezpiecznych workflowów lub optymalizacji modelu danych, możemy pomóc. Skontaktuj się z nami i opowiedz o swoim projekcie.