Reference Field i Odoo — Komplett Guide for Bruk og Beste Praksis

Introduksjon

De fleste Odoo-utviklere bruker Many2one når en post skal peke på en annen post. Det fungerer i de fleste tilfeller. Men noen ganger må lenken kunne peke til ulike typer dokumenter avhengig av konteksten — for eksempel en salgsordre, en innkjøpsordre, en produksjonsordre eller noe helt annet. Det er akkurat dette Reference-feltet er ment for.

Reference-feltet er et fleksibelt felttype i Odoo som lar en enkelt feltlenke peke til poster fra flere forskjellige modeller som du definerer i en liste. Brukeren velger først hvilken type dokument det er, og så velger vedkommende den konkrete posten. Resultatet er en polymorf kobling som kan brukes i varierte arbeidsflyter.

Denne veilederen forklarer hva Reference-feltet lagrer, hvordan det oppfører seg i Odoo-modellen, hvordan du oppretter og tilpasser det via Studio eller Python, og viser praktiske forretnings-case hvor feltet gir reell verdi.

Hva er Reference-feltet i Odoo

I Odoo sitt ORM er Reference-feltet en spesiell felttype som lagrer en pekepost til en hvilken som helst av modellene du legger i selection-listen. Det skiller seg fra Many2one ved at det ikke er låst til én fast modell.

I databasen lagres Reference-verdien som tekst i formatet modell_navn,post_id. For eksempel lagres en henvisning til salgsordre 42 som sale.order,42. Det er viktig å ha dette i bakhodet ved direkte spørringer eller filtrering mot databasen.

I brukergrensesnittet oppleves Reference-feltet som en to-trinns prosess: brukeren velger først type dokument fra en nedtrekksliste (f.eks. Salgsordre, Faktura eller Prosjektoppgave), og deretter søker og velger den konkrete posten i modellen. Når brukerne forstår flyten er den enkel og tydelig.

Slik kan en enkel definisjon av et Reference-felt se ut i Python:

from odoo import fields, models

class HelpDeskTicket(models.Model):
    _inherit = 'helpdesk.ticket'

    related_document = fields.Reference(
        selection=[
            ('sale.order', 'Sale Order'),
            ('purchase.order', 'Purchase Order'),
            ('account.move', 'Invoice'),
            ('project.task', 'Project Task'),
        ],
        string='Related Document',
    )

selection-parameteren er en liste med tupler. Hver tuppel inneholder det tekniske modellnavnet (f.eks. sale.order) og den lesbare etiketten brukeren ser i menyen. Du bestemmer hvilke modeller som skal være tilgjengelige.

Det finnes også en dynamisk variant der selection-listen bygges ved kjøring fra ir.model, slik at tilgjengelige installerte modeller fylles automatisk. Dette gir fleksibilitet, men kan bli for omfattende for sluttbrukere hvis det ikke filtreres.

I Odoo Studio finner du Reference-feltet i feltpanelet under navnet Reference. Når du legger det til via Studio kan du velge hvilke modeller som skal være valgbare direkte i grensesnittet uten å skrive kode, noe som gjør det tilgjengelig for forretningsbrukere.

Hvordan feltet fungerer

For å bruke Reference-feltet riktig i utvikling er det viktig å forstå hvordan data lagres og hentes.

Lagring i databasen

I motsetning til en Many2one som lagrer et heltall (fremmednøkkelen), lagrer Reference-feltet en tekststreng som kombinerer modellnavn og post-ID, for eksempel sale.order,15. I PostgreSQL blir dette lagret i en VARCHAR-kolonne. Dermed finnes ingen databasepålagt fremmednøkkel for å sikre referanse-integritet — det er et bevisst valg for å støtte feltets polymorfe natur.

Fordi det ikke er noen database-fremmednøkkel, rydder ikke Odoo automatisk Reference-feltet når den refererte posten slettes. Om en salgsordre fjernes vil et Reference-felt som pekte til den fremdeles inneholde tekstverdien. Dette er en viktig oppførsel å ta høyde for i utviklingen.

Tilgang til den lenkede posten i Python

Når du leser en Reference-verdi i Python, returnerer Odoo et faktisk record-objekt for den refererte modellen. Du kan behandle det som en vanlig record — få tak i felt, id og metadata. Hvis feltet er tomt returneres False.

ticket = self.env['helpdesk.ticket'].browse(1)
doc = ticket.related_document

if doc:
    print(doc._name)   # e.g. 'sale.order'
    print(doc.name)    # e.g. 'S00042'
    print(doc.id)      # e.g. 15

Dette gjør ORM-opplevelsen sømløs: selv om lagringen er en enkel tekststräng, løser rammen den til et ordentlig record-objekt når du ber om det i koden.

Viktige felt-attributter

Her er de mest relevante attributtene du kan sette på et Reference-felt i Odoo:

• selection: Liste av tupler som bestemmer hvilke modeller som kan velges. Kan også være navnet på en metode (streng) som returnerer en slik liste dynamisk.
• string: Feltets etikett som vises i brukergrensesnittet.
• required: Gjør feltet obligatorisk. Bruker må velge både modell og post før lagring.
• readonly: Hindrer brukere i å endre feltet i UI. Nyttig når referansen settes programmatisk.
• help: Tooltip som vises ved hover over feltetiketten. Godt for å veilede brukeren om hva som skal velges.
• compute: Reference-felt kan også være beregnet ved hjelp av en Python-metode, akkurat som andre felttyper. Praktisk for automatisk setning basert på forretningsregler.

Filtrering og søk

Siden verdien er en tekststreng, krever filtrering på Reference-feltet spesifikk domene-syntaks. For å søke poster som peker til et bestemt dokument må du bygge hele strengverdien selv:

tickets = self.env['helpdesk.ticket'].search([
    ('related_document', '=', 'sale.order,15')
])

Du kan også filtrere på modelltype ved hjelp av like:

tickets = self.env['helpdesk.ticket'].search([
    ('related_document', 'like', 'sale.order,')
])

Husk denne strengbaserte søkeatferden når du lager rapporter eller beregnede felt som er avhengig av Reference-verdier — den oppfører seg annerledes enn Many2one-domener.

Forretningsscenarier

Reference-feltet kommer til sin rett når samme kontekstlenke kan peke på forskjellige dokumenttyper avhengig av situasjonen. Her følger fem konkrete eksempler fra virkelige arbeidsprosesser.

1. Helpdesk-saker koblet til ulike dokumenter

Et supportteam kan få henvendelser som gjelder fakturaer, leveranser, kontrakter eller produkter. I stedet for å ha egne felter for hver dokumenttype kan du legge ett Reference-felt på saken, slik at agenten velger type (Faktura, Salgsordre, Leveranse osv.) og deretter den aktuelle posten. All relevant kontekst samles på ett sted.

2. Salgsaktiviteter med flere kilder

I en salgsavdeling kan oppgaver oppstå fra en lead, et tilbud, en kontrakt eller en supportsak. Et Reference-felt på aktiviteter eller noter gjør det mulig å knytte aktiviteten til opprinnelsesdokumentet uavhengig av modelltype — praktisk i CRM-tilpasninger.

3. Notat- og annotasjonssystem på tvers av moduler

Noen bedrifter ønsker et felles notatsystem som kan festes til kunder, prosjektoppgaver, produksjonsordrer eller innkjøp. Et Reference-felt gjør at samme notatmodell kan brukes på tvers av objekter uten å duplisere strukturene for hver modul.

4. Generisk godkjenningsflyt

I et godkjenningssystem må forespørselen peke på dokumentet som skal godkjennes. Siden godkjenninger kan gjelde innkjøp, reiseregninger, permisjoner eller kontrakter, holder et Reference-felt godkjenningsmodellen ren og gjenbrukbar — samme logikk dekker alle dokumenttyper.

5. Utlegg knyttet til prosjekt eller kundeordre

I enkelte oppsett skal utlegg knyttes enten til et prosjekt eller en salgsordre. Et Reference-felt som tilbyr project.project og sale.order i utvalget gir regnskapet fleksibilitet til å koble kostnaden riktig — særlig nyttig for konsulentselskaper og tjenesteleverandører.

Opprette eller tilpasse Reference-feltet

Det finnes to hovedmåter å legge til et Reference-felt: via Odoo Studio for en kodefri løsning, eller ved å definere det i Python når du trenger full kontroll.

Bruke Odoo Studio

Odoo Studio gjør det enkelt å legge til et Reference-felt på en form uten kode. Åpne Studio på modellen, gå til Fields-panelet og legg til et felt av typen Reference. Du blir spurt hvilke modeller som skal være valgbare. Felt opprettes som et manuelt (x_)-felt, likt andre Studio-felt.

Dette er nyttig for raske tilpasninger og for forretningsanalytikere som vil endre skjemaer uten utviklere. Husk at Studio-felter kan ha begrensninger for avanserte behov som dynamisk selection eller beregnede verdier.

Teknisk implementasjon i Python

For en fullverdig utviklingsløsning definerer du Reference-feltet i Python-modellen. Under følger et eksempel som viser hvordan du bruker en dynamisk metode for utvalget:

from odoo import api, fields, models

class ApprovalRequest(models.Model):
    _name = 'approval.request'
    _description = 'Approval Request'

    name = fields.Char(string='Request Name', required=True)

    @api.model
    def _get_document_types(self):
        return [
            ('purchase.order', 'Purchase Order'),
            ('hr.expense.sheet', 'Expense Report'),
            ('hr.leave', 'Time Off Request'),
            ('sale.order', 'Sale Order'),
        ]

    document_ref = fields.Reference(
        selection='_get_document_types',
        string='Document',
        help='Select the document this approval relates to.',
    )

Ved å bruke navnet på en metode for selection får du fleksibilitet: du kan legge inn betingelser, filtrere etter installerte moduler eller bygge listen fra konfigurasjonsdata.

Opprettelse via XML-RPC API

Du kan også opprette Reference-feltet programmatisk via Odoos XML-RPC API — nyttig ved fjernkonfigurasjon. Felt-typen er reference og selection sendes som en strengrepresentasjon av listen:

field_id = models.execute_kw(
    ODOO_DB, uid, ODOO_API_KEY,
    'ir.model.fields', 'create',
    [{
        'name': 'x_related_document',
        'field_description': 'Related Document',
        'model_id': model_id,
        'ttype': 'reference',
        'selection': "[('sale.order', 'Sale Order'), ('purchase.order', 'Purchase Order')]",
        'state': 'manual',
    }]
)

Merk at når du oppretter felt via API, blir selection sendt som en Python-evaluerbar streng snarere enn en faktisk liste — slik lagres den i ir.model.fields.

Beste praksis

Her er noen praktiske retningslinjer å følge når du jobber med Reference-felt i modellen din.

• Hold selection-listen kort og relevant. Ikke legg til alle modeller bare fordi du kan. Begrens til dokumenttypene som faktisk gir mening for prosessen — for lange lister forvirrer brukerne.
• Bruk Many2one når koblingen alltid går mot én modell. Reference er laget for polymorfe relasjoner; hvis modellen aldri varierer er Many2one enklere, raskere å søke på og bedre støttet i rapportering.
• Sjekk alltid for nullverdier i beregnede felt. Når Reference er tomt returneres False i Python. All kode som bruker lenken må ta høyde for dette for å unngå unntak.
• Håndter foreldreløse referanser med automatiske jobber. Siden databasen ikke håndhever referanseintegritet, er det lurt å kjøre en automatisert sjekk eller cron som finner og rydder opp utdaterte referanser til slettede poster.
• Bruk beskrivende etiketter i selection. Det brukerne ser i dropdown er andre element i tuppelen — skriv forretningsvennlige navn som «Kunde–faktura» i stedet for tekniske modellnavn som account.move.
• Dokumentér feltet godt i tekniske spesifikasjoner. Reference-felt oppfører seg annerledes enn Many2one, så fremtidige utviklere bør få en klar forklaring på hvorfor det ble valgt og hvilke modeller som er koblet.

Vanlige fallgruver

Vanlige feil vi ser når folk begynner å bruke Reference-felt.

Å anta at det er en Many2one i domener

Utviklere skriver av og til domener som om feltet var en Many2one, for eksempel [('document_ref', '=', 15)]. Det virker ikke — den lagrede verdien er en streng som sale.order,15, ikke bare et tall. Bygg hele strengverdien i domenet.

Å glemme at slettede poster etterlater foreldreløse verdier

Siden det ikke finnes en fremmednøkkel i databasen, fjernes ikke Reference-verdier ved sletting av målposten. Hvis en salgsordre slettes og et ticket-felt fortsatt inneholder sale.order,42, vil feltlesning returnere False i stedet for feil — men koden må håndtere en slik ugyldig referanse.

Å bruke dynamisk «alle modeller»-utvalg for bredt

Selv om du kan fylle selection med alle modeller fra ir.model, er dette vanligvis for bredt for brukervendte felt. Hundrevis av valg forvirrer og fører til feilregistrering. Begrens alltid til en kuratert liste.

Å forvente innebygd gruppering i rapporter

Reference-felt lagres som tekst og fungerer ikke som fremmednøkler for Odoos standard group-by og pivot. Hvis du trenger gruppering etter koblet dokument må du løse det med egendefinert kode eller et beregnet felt som ekstraherer modellnavnet til et separat felt.

Forveksling mellom Reference og Many2one i Studio

I Odoo Studio forveksles ofte Reference med Many2one fordi begge lenker til andre poster. Hovedforskjellen: Many2one peker alltid til én bestemt modell, mens Reference lar brukeren velge modell hver gang feltet fylles ut. Hvis du valgte feil felttype må du rekonstruere feltet.

Oppsummering

Reference-feltet dekker behovet Many2one ikke kan: fleksibel lenking til ulike dokumenttyper. Det er enkelt å definere, fungerer i Studio for kodefrie løsninger og kan integreres i Python for tekniske implementasjoner.

De viktigste punktene å huske er tekstlagringens format, mangel på automatisk opprydding ved sletting, og at filtrering må bygges som komplette strengverdier i stedet for rene ID-er. Forstå disse forskjellene, så blir feltet forutsigbart i modellen din.

Enten du bygger en generell godkjenningsflyt, kobler support-saker til ulike dokumenter eller lager et fleksibelt notatsystem på tvers av moduler, gir Reference-feltet en ryddig og vedlikeholdbar løsning uten å duplisere logikken for hver modelltype.

Trenger du hjelp med Odoo-implementasjonen din?

Hos Dasolo hjelper vi bedrifter med å implementere, tilpasse og optimalisere Odoo slik at systemet speiler faktiske forretningsprosesser. Enten du trenger egendefinert feltlogikk, datamodellering fra bunnen av eller utvidelse av eksisterende oppsett, har vi kompetansen som trengs.

Jobber du med et Odoo-prosjekt og ønsker veiledning om felttyper, dataarkitektur eller utviklingspraksis, ta gjerne kontakt. Vi kan gjennomgå situasjonen din og anbefale riktig løsning.

Kontakt Dasolo