Innledning
Hver gang en bruker setter prioritet på en lead, velger betalingsmetode eller markerer et produkt som aktivt eller arkivert i Odoo, er det sannsynligvis et Selection-felt ved spill. Dette feltet er et av de mest brukte i Odoo og viktig å mestre for å bygge pålitelige datamodeller.
I motsetning til fritekstfelt der hvem som helst kan skrive hva som helst, begrenser et Selection-felt innholdet til en forhåndsbestemt liste med valg. Denne begrensningen sikrer konsistente data, enklere filtrering og rapportering, og reduserer risikoen for stavefeil og variasjoner som ellers kan skade aggregeringer og dashbord over tid.
Denne veiledningen forklarer hva en Selection lagrer, hvordan den vises i brukergrensesnittet, og hvordan du lager eller endrer feltet via Odoo Studio, Python-moduler eller XML-RPC. Du får også konkrete eksempler fra vanlige arbeidsflyter og en sjekkliste over feil som ofte dukker opp.
Hva er et Selection-felt i Odoo
I Odoo sitt ORM lagres en Selection som en tekstnøkkel hentet fra en fastsatt liste. Hvert alternativ består av et teknisk nøkkelord som lagres i databasen og en visningstekst (label) som brukeren ser i grensesnittet.
Tenk deg et felt for prioritet som har et begrenset sett valg:
priority = fields.Selection([
('0', 'Normal'),
('1', 'Low'),
('2', 'High'),
('3', 'Very High'),
], string='Priority', default='0')I eksemplet ovenfor er '0', '1', '2' og '3' de tekniske nøklene som faktisk ligger i databasen, mens etikettene Normal, Low, High og Very High er det brukeren ser. Skillelinjen mellom nøkkel og visningstekst er sentral når du senere skal endre etiketter uten å ødelegge eksisterende poster.
I brukergrensesnittet vises Selection-felt typisk som en nedtrekksmeny i skjemaer, og som den lesbare etiketten i listevisninger. Med badge-widgeten blir hvert valg vist som en farget etikett, noe som gjør det enklere å skanne mange poster raskt.
I Odoo Studio kalles dette feltet også Selection. Felt laget i Studio får ofte et x_studio_-prefiks i navn, mens felt opprettet via kode eller API får et teknisk navn du selv bestemmer.
Slik fungerer feltet
I databasen er Selection-feltet lagret som en VARCHAR-kolonne i PostgreSQL, og databasen lagrer alltid nøkkelen — aldri visningsteksten. Når du lager domener eller serverhandlinger, må du derfor bruke tekniske nøkler, ikke de menneskelige etikettene.
Dersom du søker etter alle leads med høy prioritet, må domenet være [('priority', '=', '2')] og ikke [('priority', '=', 'High')].
Viktige feltattributter
Her er de viktigste egenskapene ved et Selection-felt i Odoo:
- selection: Listen med
(key, label)-tupler som definerer valgene. Dette kan også være navnet på en metode (som en streng) som returnerer listen dynamisk. - default: Nøkkelen som brukes når feltet ikke har verdi enda. Uten default starter feltet tomt.
- required: Tvinger brukeren til å velge et alternativ før lagring. Kombinert med et default er dette et vanlig mønster for statuser.
- selection_add: Brukes ved modul-arkeologi for å legge til nye alternativer i et eksisterende Selection-felt uten å overskrive hele listen. Dette er riktig måte å utvide innebygde felt på.
- ondelete: Styrer hva som skjer med poster som bruker et alternativ hvis modulen som la det til avinstalleres, og fungerer sammen med
selection_add.
Statisk vs. dynamisk liste
Som standard defineres valgalternativene statisk i feltdeklarasjonen. Men du kan også sende inn navnet på en metode som bygges ved kjøretid, slik at listen kan variere etter bruker, selskap eller annen kontekst.
contract_type = fields.Selection(
selection='_get_contract_types',
string='Contract Type'
)
def _get_contract_types(self):
if self.env.user.has_group('hr.group_hr_manager'):
return [('permanent', 'Permanent'), ('fixed', 'Fixed Term'), ('interim', 'Interim')]
return [('permanent', 'Permanent'), ('fixed', 'Fixed Term')]Visning i ulike view-typer
I et skjema vises Selection som en vanlig nedtrekksliste. Ved å bruke widget="badge" kan du gjøre valgene til fargede etiketter i liste- og kanbanvisninger. widget="radio" viser valgene som inline radioknapper — nyttig når antallet alternativer er lite og du vil ha alle synlige samtidig.
Samspill med ORM
Å lese og skrive Selection-felt i ORM er enkelt: du gir feltet nøkkelen, og Odoo håndterer visningen. Ved bruk av XML-RPC og fields_get vil selection-attributtet gi en full liste av [key, label]-par som eksterne verktøy kan bruke til å vise riktige etiketter.
Praktiske forretningsscenarier
Selection-feltet finnes i nesten alle moduler i en standard Odoo-installasjon. Her er fem konkrete eksempler fra daglig bruk.
CRM: Lead-prioritet og pipeline-stadier
Prioritetsfeltet i CRM er et typisk Selection-felt som hjelper salgsteam å identifisere hvilke leads som krever rask oppfølging. Verdiene brukes også i Kanban-farger og kan trigge automatiske handlinger ved eskalering — et enkelt grep som ofte gir stor forbedring i datakvalitet etter lansering.
Salg: Faktureringsregler og produktinnstillinger
Felt som bestemmer faktureringspolicy for et produkt — for eksempel om fakturering skjer på bestilt eller levert mengde — er Selection-felt som styrer hele faktureringsflyten. Tilsvarende bruker abonnementsmoduler Selection for å skille forhåndsbetalt og etterbetalt syklus, og slike valg har direkte konsekvenser for økonomiprosesser.
Lager: Produkt- og lot-status
I produksjon og kvalitetskontroll brukes Selection-felt til å spore status på partier, serienummer og reparasjonsordrer. En reparasjonsordre kan flytte seg gjennom draft, confirmed, under repair, ready og done — og hver overgang kan utløse e-poster, flytting av varer eller regnskapsføringer. Feltet er selve kontrollpunktet i arbeidsflyten.
Regnskap: Betalingsmetode og journaltype
Journaltypefeltet i regnskapet skiller mellom salg-, kjøp-, kasse- og bankjournaler. Denne verdien bestemmer riktig føringslogikk, hvilke kontoer som er tilgjengelige, og hvilke operasjoner som er tillatt. Her ser du at et Selection-felt kan styre forretningsregler, ikke bare merke en post.
HR: Ansettelsestype og kontraktsstatus
HR bruker Selection for å håndtere ansettelsestyper, kontraktsstadier og permisjonssøknader. Kontraktsstatus kan for eksempel gå fra ny til åpen til utløpt eller kansellert, og overganger kan trigge varsler, onboarding-sjekklister og lønnsjusteringer basert på type ansettelse.
Hvordan opprette eller tilpasse Selection-feltet
Tre måter å legge til et Selection-felt på
Avhengig av behov for versjonskontroll og automatisering finnes det tre vanlige fremgangsmåter for å legge til et Selection-felt.
Bruke Odoo Studio (uten kode)
- Odoo Studio er verktøyet for å legge til felt uten Python. Fremgangsmåten er enkel:
- Åpne Odoo Studio fra menyen.
- Gå til skjemaet hvor du ønsker feltet.
- Dra et Selection-felt fra sidemenyen inn på skjemaet.
- Legg til valgene i feltets egenskaper og gi hver etikettnavn.
- Sett eventuelt default og marker feltet som påkrevd.
Lagre og lukk Studio.
Studio oppretter nøkkel-etikett-par med automatisk genererte nøkler og gir feltet et x_studio_-navn. Dette er ofte den raskeste metoden når du gjør endringer sammen med en kunde.
Definere feltet i en Python-modul
For utviklere er riktig måte å definere Selection i Python i en modul, spesielt om endringen skal være versjonsstyrt og rulles ut mellom miljøer:
from odoo import fields, models
class SaleOrder(models.Model):
_inherit = 'sale.order'
x_delivery_slot = fields.Selection([
('morning', 'Morning (8h - 12h)'),
('afternoon', 'Afternoon (13h - 17h)'),
('evening', 'Evening (18h - 20h)'),
], string='Delivery Slot', default='morning')
Etter å ha definert feltet, må du legge det inn i riktig view-XML for at det skal vises. Odoo oppretter databaskolonnen ved installasjon eller oppgradering av modulen.
Når du skal legge til alternativer i et innebygd felt, bruk selection_add i stedet for å overskrive feltet:
class SaleOrder(models.Model):
_inherit = 'sale.order'
state = fields.Selection(
selection_add=[('custom_approval', 'Pending Approval')],
ondelete={'custom_approval': 'set default'}
)
Opprette felt gjennom XML-RPC API
For automatisert administrasjon eller skript som provisionerer konfigurasjon eksternt, kan du opprette Selection-felt via XML-RPC:
field_id = models.execute_kw(
ODOO_DB, uid, ODOO_API_KEY,
'ir.model.fields', 'create',
[{
'name': 'x_contract_category',
'field_description': 'Contract Category',
'model_id': model_id,
'ttype': 'selection',
'selection': "[('standard', 'Standard'), ('premium', 'Premium'), ('custom', 'Custom')]",
'state': 'manual',
}]
)
Anbefalte fremgangsmåter
Merk at ved API-oppretting sendes selection som en strengrepresentasjon av en Python-liste. state: 'manual' angir at feltet er manuelt opprettet — korrekt for felt laget via Studio eller API, og nyttig i automatiserte konfigurasjonsskript.
1. Bruk meningsfulle og stabile nøkler
Nøkkelen er det som faktisk lagres og brukes i domener, serverlogikk og automatisering. Velg korte, beskrivende nøkler som du ikke forventer å endre: 'draft', 'confirmed', 'cancelled'. Unngå å bruke rene tall som nøkler med mindre rekkefølgen virkelig betyr noe, fordi tall gjør koden vanskeligere å forstå senere.
2. Hold listen kort og dekkende
Et Selection-felt med mer enn åtte–ti alternativer tyder ofte på at feltet prøver å løse for mye. Når listen vokser, vurder en Many2one-relasjon til en konfigurasjonsmodell i stedet. Det gir brukerne mulighet til å administrere alternativer selv uten utviklerinnblanding.
3. Sett alltid default for påkrevde felt
Hvis feltet er påkrevd bør det ha en fornuftig standardverdi. Dette unngår valideringsfeil når poster opprettes programmatisk, ved import eller via API uten brukerinteraksjon. Default bør representere den mest typiske eller minst forpliktende tilstanden.
4. Bruk selection_add når du utvider innebygde felt
Når du legger til nye alternativer i et eksisterende Odoo-felt, bruk selection_add i stedet for å definere feltet på nytt. Dette gir bedre kompatibilitet med andre moduler som også kan utvide feltet. Husk også ondelete for å bestemme oppførsel ved avinstallering.
5. Bruk badge-widget for synlighet i lister
Vanlige fallgruver
I liste- og kanbanvisninger gir standard tekstvisning lite oversikt. Med widget="badge" blir verdiene fargede etiketter som er enklere å skanne — spesielt nyttig for statusfelt der rask gjenkjenning er viktig.
Å endre en nøkkel ødelegger eksisterende data
Etiketter kan endres trygt fordi databasen bruker nøkkelen, men selve nøkkelen kan aldri endres etter at poster med den eksisterer. Endrer du en nøkkel uten migrering, vil eksisterende poster få manglende verdi i grensesnittet, og domener eller automasjoner vil slutte å fungere uten å gi feilmelding. Trengs nøkkelen byttet må du kjøre en datamigrering på forhånd.
Å fjerne et alternativ etterlater foreldreløse poster
Sletter du et alternativ mens poster fortsatt refererer til det, vil disse postene vise en ødelagt eller manglende verdi. Før du fjerner alternativer, søk etter og oppdater poster som bruker dem eller arkiver dem — dette er en vanlig utfordring i opprydningsprosjekter.
Å bruke etiketten i stedet for nøkkelen i domener
En vanlig feil, særlig blant ikke-tekniske brukere, er å bygge filtre basert på den menneskelige etiketten i stedet for den lagrede nøkkelen. Slike domener returnerer ofte null treff uten feilmelding, noe som kan være vanskelig å feilsøke. Sjekk alltid feltdefinisjonen for å vite hvilken nøkkel som hører til hvilken etikett.
Feil valg av felttype — Selection når Many2one er bedre
Hvis listen endres ofte, brukerne selv skal kunne administrere alternativer, eller alternativene har egne egenskaper (farge, sekvens, konto), er Many2one ofte et bedre valg. Selection passer for stabile, utviklerstyrte lister; for mer dynamiske behov er Many2one mer fremtidsrettet.
Ikke håndtere tom verdi i serverside-logikk
Oppsummering
Et ikke-påkrevd Selection-felt kan være False når det ikke er valgt noe. Serverkode eller automatiske handlinger som sammenligner feltet med en streng uten å sjekke for False først, kan gi uventet oppførsel eller feil. Håndter alltid tomme verdier eksplisitt i beregnede felt og serverhandlinger.
Selection-feltet er enkelt ved første øyekast, men får mye tyngde når du ser hvordan nøkkel og etikett spiller sammen, når du bør bruke selection_add, og når en Many2one er et bedre valg. Slike valg skiller en robust Odoo-implementering fra en som skaper problemer senere.
Enten du legger til kontraktstyper i Studio, definerer leveringsvinduer i en Python-modul eller oppretter kvalitetsstatus via API, gir mønstrene i denne guiden grunnlaget for riktige valg i dine arbeidsflyter.
Riktig brukt er Selection-feltet et viktig verktøy for å sikre datakvalitet ved kilden — det holder poster ryddige, rapporter korrekte og automasjoner pålitelige. Hos Dasolo bistår vi bedrifter med implementasjon, tilpasning og optimalisering av Odoo i alle avdelinger. Trenger du hjelp med å designe datamodell, legge til skreddersydde felt eller bygge en modul fra bunnen av, står vårt team klart. Ta kontakt med oss