Readonly-felter er en af de funktioner i Odoo, der ved første øjekast virker ligetil, men som spiller en meget større rolle, end de fleste brugere forventer.
Uanset om du er en forretningsbruger, der undrer dig over, hvorfor visse felter er gråtonede, eller en udvikler, der ønsker at kontrollere feltadfærden i din Odoo-tilpasning, dækker denne guide alt, hvad du behøver at vide.
At forstå, hvordan readonly-felter fungerer, er nøglen til at opbygge pålidelige arbejdsgange, beskytte dataintegritet og levere en mere glidende oplevelse for dit team.
Denne Odoo-feltvejledning gennemgår både de forretningsmæssige og tekniske sider af readonly, så uanset om du konfigurerer Odoo eller bygger ovenpå det, vil du finde det, du har brug for her.
Hvad er readonly-feltet i Odoo
Et readonly-felt i Odoo er et felt, der viser en værdi, men som ikke kan redigeres direkte af brugeren gennem grænsefladen. Dataene er synlige, men input er låst.
I formularvisningen vises readonly-felter typisk som almindelig tekst snarere end interaktive inputbokse. Afhængigt af Odoo-temaet kan de se lidt grålige ud eller blot flade ud sammenlignet med redigerbare felter.
Inden for Odoo-datamodellen kan readonly-adfærd anvendes på to forskellige niveauer:
- På feltniveau (Python/ORM): feltet er altid readonly på tværs af alle visninger og kontekster
- På visningsniveau (XML): feltet er readonly i en specifik visning eller under specifikke betingelser
Denne skelnen er vigtig. Et felt, der er markeret som readonly på ORM-niveau, kan ikke redigeres gennem nogen brugergrænseflade. Et felt, der er markeret som readonly på visningsniveau, er beskyttet i den pågældende kontekst, men kan stadig være skrivbart i andre visninger eller gennem server-side kode.
Readonly er ikke en felttype i sig selv. Det er en attribut, der kan anvendes på enhver af de standard Odoo-felttyper: Char, Integer, Float, Many2one, Date og andre. Dette er en kernekomponent i Odoo-rammen til at kontrollere, hvordan felter opfører sig ved kørsel.
Hvordan readonly-feltet fungerer
For at forstå, hvordan readonly-felter opfører sig, hjælper det at se på begge sider: Odoo ORM (Python) og visningslaget (XML).
Readonly på ORM-niveau
I Odoo ORM kan et felt erklæres som permanent readonly direkte i Python-modellen. Dette er mest almindeligt for beregnede felter, der henter deres værdi fra andre data. Feltdefinitionen inkluderer readonly=True som en parameter, og Odoo vil aldrig tillade brugeren at redigere det gennem UI'en.
Dette niveau af readonly er en del af Odoo Python-felter API'en og er dokumenteret i den officielle Odoo udviklerguide. Det gælder globalt, uanset hvilken visning der anvendes.
Tilstandsbaseret readonly
Et af de mest almindelige mønstre i Odoo-udvikling er at gøre et felt readonly baseret på den aktuelle tilstand af et dokument. Dette er, hvordan standardmoduler som Salg, Indkøb og Regnskab låser deres data, når et dokument bevæger sig forbi udkaststadiet.
I Odoo 16 og tidligere versioner blev dette gjort ved hjælp af attrs attributten i visnings-XML, hvor en domænebetingelse blev kombineret med feltelementet. I Odoo 17 og senere er syntaksen mere kortfattet og skrevet direkte som et inline-udtryk på feltelementet.
Begge tilgange opnår det samme resultat: feltet er redigerbart, mens dokumentet er i kladde, og bliver låst, når det skrider frem gennem arbejdsprocessen. Dette er et grundlæggende koncept i enhver Odoo teknisk tutorial, der dækker feltkonfiguration.
Beregnede Felter og Readonly
Odoo beregnede felter er som standard readonly. Når du definerer et felt med en compute metode, antager Odoo, at det ikke skal redigeres direkte, fordi dets værdi automatisk er afledt fra andre felter.
Hvis du ønsker, at et beregnet felt også skal gemmes, skal du indstille både compute parameteren og store=True. Disse gemte Odoo databasefelter er et almindeligt mønster for ydeevneoptimering, da de kan bruges i søgefiltre og sorteres effektivt på databaseniveau uden at skulle genberegne værdier i realtid.
Gøre et Beregnet Felt Skrivbart
Hvis du har brug for, at et beregnet felt også skal acceptere manuel indtastning, kan du definere en invers metode sammen med det. Den inverse metode fortæller Odoo, hvad der skal gøres, når en bruger skriver en værdi til det beregnede felt. Uden en invers forbliver feltet som standard readonly. Dette er en del af de mere avancerede Odoo ORM felttyper API og er dækket i dybden i Odoo udviklerguiden.
Forretningsbrugssager
Readonly felter vises i alle Odoo-moduler. Her er fem praktiske eksempler fra virkelige forretningsarbejdsgange.
1. CRM: Låsning af Vundne og Tabte Muligheder
I CRM-modulet er den forventede indtægt og lukningsdato redigerbare, mens en lead bliver arbejdet på. Når en mulighed er markeret som Vundet eller Tabt, sættes disse felter til readonly for at bevare en nøjagtig optegnelse af, hvad der blev lukket og til hvilken værdi.
Dette forhindrer nogen i at gå tilbage og justere tal efterfølgende, hvilket ville forvrænge salgsrapporter og pipeline-analyser.
2. Salg: Beskyttelse af Bekræftede Ordrelinjer
Når en salgsordre går fra Udkast til Bekræftet, bliver ordrelinjerne skrivebeskyttede. Brugere kan ikke længere ændre produktet, mængden eller prisen, efter at kunden har modtaget en bekræftelse.
Hvis ændringer virkelig er nødvendige, skal ordren eksplicit nulstilles til udkast, hvilket skaber en revisionsspor og gør rettelsen intentionel snarere end utilsigtet.
3. Lager: Validerede Lagerbevægelser Mængder
I lageroperationer, når en levering eller modtagelse er valideret, bliver de udførte mængder låst. Dette beskytter integriteten af lagervurderingen og sikrer, at optegnelserne matcher det, der fysisk er flyttet gennem lageret.
Redigerbare mængder efter validering kunne stille og roligt korrumpere lagerbeholdninger på tværs af flere lokationer.
4. Regnskab: Bogførte Journalpostlinjer
I regnskab, når en journalpost er bogført, bliver alle dens linjer skrivebeskyttede. Dette er både et lovkrav i mange lande og et kerneprincip i dobbelt bogholderi.
At tillade redigeringer efter bogføring ville kompromittere pålideligheden af finansielle erklæringer og skabe alvorlige overholdelsesrisici.
5. Produktion: Færdige Arbejdsordredata
I Produktionsmodulet, når en arbejdsordre er markeret som færdig, bliver den faktiske varighed og producerede mængder sat til skrivebeskyttede. Dette bevarer nøjagtige produktionsoptegnelser, der fodrer ind i omkostningsanalyse og præstationssporing.
Oprettelse eller tilpasning af et readonly-felt
Der er to hovedveje til at konfigurere skrivebeskyttede felter i Odoo: ved at bruge Odoo Studio til en no-code tilgang, eller ved at skrive Python og XML direkte for fuld teknisk kontrol.
Ved at bruge Odoo Studio
Odoo Studio-felter gør det nemt at tilføje eller ændre readonly-adfærd uden at skrive nogen kode. For at konfigurere et felt som readonly ved hjælp af Studio:
- Åbn Odoo Studio fra hovedmenuen (blyantikonet)
- Naviger til formularvisningen, hvor du vil konfigurere feltet
- Klik på det felt, du vil ændre
- I højre sidepanel for egenskaber skal du skifte "Readonly"-muligheden
- Gem og luk Studio
Studio giver også mulighed for at indstille betinget readonly adfærd ved hjælp af domæneudtryk. For eksempel kan du gøre et felt readonly kun når et statusfelt er lig med en bestemt værdi, uden at skrive en eneste linje kode.
Odoo Studio-tilgangen til at oprette felter er det rigtige valg for konsulenter og administratorer, der hurtigt og sikkert skal håndhæve dataregler. Ændringer foretaget gennem Studio gemmes i databasen og vil ikke blive overskrevet ved modulopgraderinger.
Brug af Python til teknisk tilpasning
For udviklere, der bygger tilpassede Odoo-moduler, indstilles readonly-attributten direkte på feltdefinitionen i Python-modellen. Dette er standard Odoo Python-felts brug og er dækket i hver Odoo udviklerguide.
Du kan indstille readonly=True som en statisk parameter på enhver felttype, hvilket gør det permanent ikke-redigerbart. For mere fleksibel kontrol giver states-parameteren dig mulighed for at definere, i hvilke dokumenttilstande feltet skal være skrivbart versus readonly.
Denne tilgang er særligt nyttig, når du tilføjer brugerdefinerede felter til eksisterende Odoo-modeller som en del af et Odoo-tilpasningsprojekt. Det holder feltlogikken tæt på datamodellen i stedet for spredt over flere visningsfiler.
Brug af XML Visningsattributter
For visningsniveau readonly-adfærd tilføjer du readonly-attributten direkte til felt-elementet i din visnings-XML. Dette er en del af den standard Odoo udviklingsarbejdsgang for enhver teknisk tilpasning.
Fordelen ved visningsniveau readonly er fleksibilitet: det samme felt kan opføre sig forskelligt i forskellige visninger eller under forskellige betingelser uden at ændre den underliggende feltdefinition. Dette er ofte den foretrukne tilgang, når du har brug for at tilføje restriktioner til eksisterende standardfelter uden at ændre deres Python-definition.
I Odoo 17 er den inline udtryksyntax for readonly-betingelser renere og mere læsbar end den ældre attrs-ordbogssyntax, der blev brugt i tidligere versioner. Begge tilgange er gyldige afhængigt af hvilken Odoo-version du kører.
Bedste praksis
At bruge readonly-felter korrekt handler om at anvende dem på det rigtige niveau, af den rigtige grund. Her er de vigtigste retningslinjer fra et Odoo konsulentperspektiv.
1. Foretræk Visningsniveau Readonly Når Konteksten Varierer
Hvis et felt kun skal være readonly i visse dokumenttilstande eller i specifikke visninger, skal du anvende readonly på visningsniveau snarere end modelniveau. Dette holder din Odoo datamodel fleksibel og tillader backend-processer eller API-integrationer at skrive til feltet, når det er nødvendigt.
2. Juster Readonly Betingelser med Dokumentlivscyklussen
Dine readonly-betingelser bør matche den naturlige strøm af dine dokumenter. Felter bør låses, når dokumentet når en tilstand, hvor yderligere redigeringer ville forårsage problemer. Dette skaber en forudsigelig og intuitiv oplevelse for brugerne, hvilket er et af kendetegnene ved en velimplementeret Odoo-tilpasning.
3. Test på tværs af Brugerroller
Readonly-adfærd kan interagere med adgangsrettigheder på uventede måder. Test altid din konfiguration som både en standardbruger og en administrator for at bekræfte, at feltet opfører sig korrekt for hver rolle. Hvad der ser readonly ud for én brugergruppe, kan stadig være redigerbart for en anden afhængigt af deres profil.
4. Kombiner Readonly med Påkrævet Hvor Det Giver Mening
I multi-stage formularer kan et felt være påkrævet i udkast, men skrivebeskyttet i senere tilstande. Du kan kombinere begge attributter i din visnings-XML for at håndhæve dette mønster på en ren måde. Dette er almindeligt for felter som leveringsdatoer eller referencenumre, der skal udfyldes, før et dokument bekræftes.
5. Dokumentér din skrivebeskyttede logik
I tilpasset Odoo-udvikling, især på komplekse datamodeller, skal du altid tilføje en kommentar, der forklarer, hvorfor et felt er skrivebeskyttet. Fremtidige udviklere, der vedligeholder koden, skal forstå den forretningsmæssige årsag bag begrænsningen, ikke kun den tekniske implementering.
6. Brug Studio-felter til hurtige, opgraderingssikre ændringer
For enkle brugssager tilbyder Odoo Studio-felter en hurtig og opgraderingssikker måde at tilføje skrivebeskyttet adfærd. Forbehold Python-tilpasning til tilfælde, hvor Studio ikke kan levere den nødvendige logik, såsom komplekse tværfeltsbetingelser eller integration med brugerdefinerede beregnede felter.
Almindelige faldgruber
Selv erfarne Odoo-brugere og udviklere støder på de samme problemer med skrivebeskyttede felter. Her er dem, der er værd at vide om, før de overrasker dig.
Forveksling af visningsniveau skrivebeskyttet med en sikkerhedsgrænse
Et felt, der er indstillet som skrivebeskyttet i en visning, forhindrer ikke opdateringer gennem XML-RPC API, ORM skriveopkald i Python eller serverhandlinger. Visningsniveau skrivebeskyttet er en UI-begrænsning, ikke en sikkerhedskontrol. Hvis du virkelig har brug for at forhindre alle skrivninger til et felt, skal du håndhæve det på ORM-niveau eller gennem adgangskontrolregler, ikke kun i visningen.
At gøre felter permanent skrivebeskyttede, når betinget ville være bedre
Det er fristende helt at låse et felt, når du vil beskytte det. Men hvis brugerne legitimt har brug for at redigere det i visse situationer, såsom når de nulstiller et dokument til udkast, vil en permanent skrivebeskyttelse på ORM-niveau blokere dem helt, inklusive eventuelle korrektionarbejdsgange. Tænk altid igennem hele livscyklussen, før du vælger permanent frem for betinget.
At glemme onchange-metoder
Hvis et skrivebeskyttet felt også refereres i en onchange-metode, kan den metode stadig forsøge at tildele en værdi til det. Dette kan producere forvirrende adfærd, hvor feltet ser ud til at opdatere under brugerinteraktion, men derefter vender tilbage eller udløser en fejl. Sørg for, at din onchange-logik tager højde for skrivebeskyttede felter.
Ikke at anvende readonly konsekvent på tværs af alle visninger
Et felt, der er markeret som readonly i formularvisningen, kan stadig være redigerbart i listevisningen eller kanbanvisningen, hvis disse visninger ikke inkluderer den samme restriktion. Tjek altid, at din readonly-konfiguration anvendes konsekvent i hver visning, hvor feltet vises.
Bivirkninger ved at arve standardmodeller
Når du arver fra en standard Odoo-model og tilføjer readonly=True til et eksisterende felt, påvirker denne ændring alle visninger, der viser det felt, inklusive standardvisninger. Sørg for, at dette er intentionelt, og at det ikke vil bryde standard Odoo-adfærd eller konflikte med andre tilpasninger på den samme model.
Konklusion
Readonly-felter er et fundamentalt værktøj i Odoo til at guide brugere gennem arbejdsprocesser, beskytte dataintegritet og håndhæve forretningsregler uden at stole alene på træning.
Nøglen er at vide, hvornår man skal anvende readonly på visningsniveau versus modelniveau, og sikre at betingelserne stemmer overens med, hvordan dit team faktisk arbejder. En velkonfigureret Odoo-datamodel gør altid brug af readonly-felter på de rigtige tidspunkter i dokumentlivscyklussen.
Uanset om du konfigurerer dem gennem Odoo Studio for en no-code tilgang eller definerer dem direkte i Python og XML som en del af et bredere Odoo udviklingsprojekt, forbliver logikken bag readonly-felter konsekvent: vis dataene, men beskyt dem mod utilsigtede ændringer.
De er måske ikke det mest diskuterede emne inden for Odoo-tilpasning, men de er stille en af de mest indflydelsesrige.
Hos Dasolo hjælper vi virksomheder med at implementere, tilpasse og optimere Odoo på tværs af alle moduler og industrier. Hvis du har brug for hjælp til at konfigurere felter, designe pålidelige arbejdsprocesser eller forbedre din Odoo-datamodel, er vores team klar til at støtte dig. Kontakt os og fortæl os om dit projekt.