Każda firma działa inaczej — rejestrujecie w zespole dane, których nie przewidziano w standardowym oprogramowaniu. Właśnie po to istnieją pola niestandardowe w Odoo: pozwalają dopasować system do twoich unikalnych potrzeb.
Zamiast próbować zmusić procesy do dopasowania się do sztywnych struktur danych, Odoo umożliwia dodawanie własnych pól praktycznie do każdego rekordu — klienta, zamówienia sprzedaży, produktu czy faktury. Decydujesz, jakie informacje są istotne, a system przechowuje je obok standardowych danych.
Ten przewodnik wyjaśnia najważniejsze kwestie: czym są pola niestandardowe, jak funkcjonują od strony technicznej, jak je tworzyć (z kodem i bez) oraz jak używać ich tak, żeby baza Odoo pozostała przejrzysta i łatwa w utrzymaniu.
Czym jest pole niestandardowe w Odoo
Pole niestandardowe to po prostu dodatkowa kolumna w modelu Odoo, przypisana do konkretnego rekordu i przechowująca określoną wartość — działa tak samo jak pole standardowe, tylko że dodane później.
W Odoo wszystkie pola niestandardowe mają techniczny prefiks x_. Pole utworzone w Studio zwykle zaczyna się od x_studio_, natomiast pola tworzone w projekcie programistycznym często otrzymują prefiks związany z firmą, np. x_dasolo_cost_center.
Dla użytkownika pole niestandardowe wygląda i zachowuje się jak normalne pole: pojawia się w formularzach, listach, filtrach, grupowaniach i raportach. Osoba nieznająca zaplecza technicznego nie zauważy różnicy.
Dostępne typy pól
Odoo oferuje szeroką gamę typów pól, które zaspokajają większość potrzeb biznesowych:
- Tekst krótki (Char): krótkie etykiety, kody referencyjne
- Tekst długi: pole wielowierszowe na opisy i notatki
- Integer: liczby całkowite, przydatne do zliczeń
- Float/Decimal: liczby z przecinkiem, do pomiarów i proporcji
- Monetary: kwoty z uwzględnieniem waluty powiązanej z odpowiednim polem
- Boolean: wartość prawda/fałsz — checkbox
- Data / Data i czas: daty kalendarzowe lub znaczniki czasu
- Selection: zamknięta lista wyboru — dropdown
- Many2one: odnośnik do pojedynczego rekordu innego modelu
- One2many: kolekcja powiązanych rekordów z innego modelu
- Many2many: powiązania wielokrotne z innym modelem
- Binary: załączniki plikowe
- HTML: sformatowana treść bogatego tekstu
Dobrze dobrany typ pola na etapie projektowania oszczędza wiele problemów później — gdy możliwe wartości są znane, lepiej użyć Selection niż pola tekstowego, by uniknąć niejednolitych wpisów.
Jak pole działa w praktyce
Odoo opiera się na ORM (Object-Relational Mapping). Każdy widok i rekord odpowiada klasie Pythona powiązanej z tabelą w PostgreSQL. Dodając pole niestandardowe, rejestrujesz je w warstwie metadanych, a system automatycznie tworzy kolumnę w bazie.
To właśnie daje elastyczność modelu danych w Odoo: nie modyfikujesz źródła aplikacji, lecz rozszerzasz model przez zapisy w tabeli ir.model.fields. Przy starcie system odczytuje te metadane i dynamicznie buduje pola.
Pola definiowane w kodzie kontra pola zapisane w bazie
W typowym rozwoju Odoo pola definiuje się w klasach Pythona przy użyciu frameworkowych typów pól. Taka definicja jest częścią modułu i ładowana podczas instalacji modułu.
Przykładowa deklaracja w module wygląda mniej więcej tak (to schematyczny fragment pokazujący, skąd pole pochodzi):
Pola tworzone przez UI lub API są zapisywane w ir.model.fields ze stanem state = 'manual' i ładowane w runtime. Efekt dla użytkownika jest taki sam — realna kolumna w bazie i pełna funkcjonalność w interfejsie.
Relacje i pole odwrotne
Gdy dodajesz pole Many2one wskazujące na inny model, Odoo zwykle oczekuje istnienia odpowiadającego pola One2many po drugiej stronie. To nie jedynie konwencja — ORM wykorzystuje te relacje do nawigacji między rekordami.
Przykładowo, jeśli dodasz x_project_id (Many2one do projektu) na zamówieniu sprzedaży, warto też zapewnić x_sale_order_ids (One2many do zamówień) po stronie modelu projektu, żeby łatwo przejść od projektu do powiązanych zamówień w standardowym interfejsie.
Pola obliczane (computed)
Pola obliczane to te, których wartość generuje się automatycznie na podstawie innych pól. W kodzie definiujesz metodę obliczającą i wiążesz ją z polem za pomocą parametru compute — takie pole jest zwykle tylko do odczytu i aktualizuje się przy zmianie zależności.
Pola obliczane dają dużą moc, ale wymagają programowania. Nie stworzymy ich standardowo przez Odoo Studio bez włączenia trybu deweloperskiego i znajomości Pythona.
Przykłady zastosowań w firmie
W większości wdrożeń, z którymi pracujemy, pola niestandardowe pojawiają się niemal zawsze. Poniżej pięć typowych zastosowań, które wracają w praktyce klientów.
1. CRM — lepsza kwalifikacja leadów
Standardowe leady trzymają podstawowe dane, ale zespoły sprzedaży często potrzebują dodatkowych pól, np. wyboru branży (Selection) lub powiązania z modelem "Segment Rynku" (Many2one), aby szybciej klasyfikować potencjalnych klientów i raportować lejki sprzedażowe według segmentów.
2. Sprzedaż — przypisanie wewnętrznych kodów projektów
Firmy rozliczające się projektowo zwykle potrzebują prostego pola na kod projektu lub odniesienie budżetowe na ofercie czy zamówieniu. Pole Char typu "Kod projektu" na sale.order pozwala umieszczać tę informację na dokumentach i filtrować zamówienia w raportach bez wdrażania pełnego modułu projektowego.
3. Magazyn — specyficzne cechy produktów
Poza standardowymi atrybutami produkty mogą wymagać branżowych specyfikacji — np. "Okres gwarancji (miesiące)" (Integer), "Norma certyfikacji" (Selection) czy "Kraj pochodzenia" (Many2one do res.country). Takie pola integrują się z kartą produktu i raportami magazynowymi.
4. Księgowość — przypisanie kosztów i centrów kosztów
Zespoły finansowe często muszą tagować faktury lub zapisy księgowe centrum kosztów czy linijką budżetową. Many2one na account.move wskazujący na model "Centrum kosztów" umożliwia szczegółowe alokacje bez ingerencji w analitykę, a filtry i tabele przestawne natychmiast działają z tym polem.
5. HR — dodatkowe dane onboardingowe
HR potrzebuje czasem danych, których nie ma w standardzie: lokalne typy umów, wewnętrzne kategorie kompetencji czy przypisania do floty służbowej. Pola na hr.employee pozwalają trzymać te informacje w Odoo, a nie w rozproszonych arkuszach kalkulacyjnych, co ułatwia wyszukiwanie i raportowanie.
Tworzenie i dostosowywanie pola
Drogi tworzenia pól
Są dwie podstawowe metody tworzenia pól w Odoo — wybór zależy od zespołu i złożoności wymaganej logiki.
Opcja 1: Odoo Studio — bez kodu
- Polom dodanym przez Studio mogą zarządzać użytkownicy biznesowi bez programowania. Procedura jest szybka i intuicyjna: otwierasz formularz, do którego chcesz dodać pole (np. zamówienie sprzedaży),
- wchodzisz w tryb edycji Studio,
- przeciągasz wybrany typ pola na formularz,
- ustawiasz etykietę, techniczną nazwę i parametry,
- zapisujesz i wychodzisz z trybu edycji.
Studio tworzy wpis w ir.model.fields z prefiksem x_studio_ i wstawia pole do widoku — bez deployu i restartu. To najlepsza droga dla prostych pól bez niestandardowej logiki.
Opcja 2: Dostosowanie techniczne przez API lub moduł
Gdy potrzeba pól obliczanych, skomplikowanych filtrów lub kontroli wersji, tworzymy pola programowo przez XML-RPC API lub pisząc moduł Pythona. To właściwa ścieżka, gdy pole ma być częścią repozytorium kodu i przetrwać aktualizacje.
Przykład tworzenia pola selection przez API pokazuje standardowy sposób automatycznej konfiguracji modelu zdalnie,
gdy najpierw pobieramy identyfikator modelu, a potem tworzymy wpis w ir.model.fields ze wszystkimi atrybutami pola (nazwa techniczna, opis, typ, lista wyborów, state = 'manual').
Taki sposób wpisuje się w typowe praktyki deweloperskie Odoo i jest przydatny przy automatyzacji konfiguracji oraz w projektach zdalnych.
Jeśli pole ma być na stałe częścią systemu i podlegać kontroli wersji, najlepszym rozwiązaniem jest zdefiniowanie go w module Pythona i instalacja modułu — to ułatwia utrzymanie przy aktualizacjach.
Dodanie pola do widoku
Utworzenie pola nie wystarcza — musisz je pokazać w odpowiednim miejscu interfejsu. Studio robi to automatycznie w trakcie tworzenia. Przy podejściu technicznym dodajesz pole do widoku przez zmianę XML widoku lub przez stworzenie widoku dziedziczącego, który wstrzykuje pole w pożądane miejsce.
Dobre praktyki
Pola łatwo tworzyć, ale brak planu architektonicznego prowadzi do bałaganu, który trudno naprawić. Oto praktyki, które pomagają utrzymać porządek.
Stosuj Selection zamiast darmowego tekstu, gdy wartości są ograniczone
Gdy lista możliwych wartości jest znana, wybierz Selection zamiast Char — zapobiega to niespójności wpisów (różne warianty tego samego słowa), co utrudnia filtrowanie i raporty. Dropdown zapewnia spójność bez dodatkowego wysiłku.
Nadaj polom jasne i spójne nazwy
Nazwa techniczna powinna odzwierciedlać zawartość pola, nie jego miejsce w formularzu. Nazwa typu x_field_1 za kilka miesięcy utrudni utrzymanie. Przyjmij konwencję nazewnictwa i dokumentuj cel każdego pola.
Nie przeciążaj natywnych modeli
Gdy widzisz dziesięć pól na sale.order, to sygnał, że lepiej stworzyć oddzielny model. Jeśli grupa pól opisuje nowy byt biznesowy (projekt, kontrakt, certyfikat), rozważ własny model połączony Many2one zamiast mnożenia pól na jednym modelu.
Testuj najpierw na środowisku stagingowym
Zanim wprowadzisz zmiany do produkcji, wypróbuj je na kopii bazy. Tworzenie pola jest zwykle bezpieczne, ale błędny wybór modelu lub typu może wymagać ręcznych napraw — lepiej wychwycić to wcześniej.
Dokumentuj wszystkie pola niestandardowe
Prowadź rejestr z dodanych pól: model, nazwa techniczna, cel i zleceniodawca. Implementacje Odoo z czasem akumulują pola — bez dokumentacji trudno później ustalić, które są używane i które można usunąć.
Wybierz właściwe narzędzie do logiki obliczeniowej
Jeżeli wartość zależy od innych pól, zastosuj pole obliczane zamiast polegać na ręcznym wprowadzaniu. To zmniejsza błędy i zapewnia spójność — pola obliczane to standardowa funkcjonalność Pythona w Odoo i są dobrze udokumentowane.
Typowe pułapki
Typowe błędy, na które natrafiają nawet doświadczeni zespoły
Zapomnienie One2many przy tworzeniu Many2one
To najczęstszy błąd techniczny: dodanie Many2one na modelu A wskazującego na model B bez stworzenia odwrotnego One2many na modelu B. W efekcie nie da się w standardowym interfejsie przeglądać powiązanych rekordów z poziomu modelu B — zawsze twórz obie strony jednocześnie.
Usuwanie pola, które zawiera dane
Usunięcie pola kasuje kolumnę z bazy i wszystkie jej dane bez możliwości cofnięcia. Jeśli jest choć cień szansy, że dane będą potrzebne, zamiast usuwać pole lepiej je ukryć lub zarchiwizować.
Tworzenie pól bezpośrednio na produkcji
Zmienianie konfiguracji na żywej bazie bez testów to ryzyko — nawet proste dodanie pola może zepsuć widok i generować błędy dla użytkowników. Najpierw weryfikuj na środowisku testowym.
Konflikty nazw z polami standardowymi
Odoo odrzuci nazwę już istniejącą, ale łatwo stworzyć pole, które będzie kolidować z modułem instalowanym później. Prefiks firmowy (np. x_acme_) znacząco redukuje to ryzyko.
Dodawanie pola do widoku bez uwzględnienia UX
Możliwość dodania pola nie oznacza, że powinno być od razu widoczne. Zagracone formularze spowalniają pracę. Jeśli pole jest potrzebne tylko w określonych sytuacjach, umieść je na osobnej karcie lub pokaż warunkowo.
Mieszanie pól Studio i pól technicznych bez strategii
Łączenie modyfikacji przez Studio i przez kod bez jasnej zasady prowadzi do nazewnictwa kolidującego i problemów konserwacyjnych. Ustal na początku, czy Studio służy do prostych pól, a kod do logiki, czy preferujesz podejście kodowe dla wszystkich zmian.
Podsumowanie
Pola niestandardowe to najprostszy sposób, by dostosować Odoo do twojego działania. Nie wymagają modyfikacji źródła, ładnie integrują się z platformą i pozwalają użytkownikom zbierać właściwe dane bez obejść.
Klucz to przemyślane podejście: dobierz typ pola, nazwij je jasno, przestrzegaj konwencji relacyjnych i dokumentuj. Dobra architektura pól ułatwia utrzymanie systemu i jego rozwój wraz z firmą.
Niezależnie od tego, czy korzystasz z Odoo Studio do szybkich rozwiązań bez kodu, czy tworzysz moduły Pythona w ramach szerszego projektu dostosowań, zasady pozostają takie same: dopasuj pole do danych, utrzymuj model czytelny i testuj przed wdrożeniem na produkcję.
W Dasolo pomagamy firmom wdrażać, dostosowywać i optymalizować Odoo, aby system odzwierciedlał ich rzeczywiste procesy. Czy potrzebujesz kilku pól w istniejącym systemie, czy kompletnego modułu na zamówienie — nasz zespół służy wsparciem.
Skontaktuj się z nami, jeśli potrzebujesz porady przy wdrożeniu Odoo — chętnie przejrzymy twoją konfigurację i zaproponujemy najczystsze rozwiązanie.