OwnCloud / NextCloud Odoo Integration v.8

Nej, denne funktion findes først fra version 15. Før det arbejder modulet med en foruddefineret mappestruktur:

1. Odoo - rodmappe til synken

2. Modeller - mapper for hver Odoo-dokumenttype. For eksempel «Projects», «Partners». Efter domæne kan der være mere specifikke mapper: «Customer 1 Projects», «Projects of the Customer 2», «Internal Projects» osv.

3. Objekter - mapper for hvert dokument, f.eks. «Project 1» eller «Customer 1»

4. Filer og mapper knyttet til dette Odoo-dokument, som skal synkroniseres.

Så kan du for eksempel have:

• Odoo / Projects / Project 1 / filer og mapper til projekt 1

• Odoo / Customer 1 Projects / Project 1; Odoo / Customer 2 Projects / Project 3, ...

• Odoo / Customers / Customer 1 / filer og mapper til kunde 1

Strukturen er altid flad: kun disse niveauer. Forskellige dokumenttyper kan ikke ligge i samme gren. I mappen «Customer 1» kan man ikke holde både ordrer, fakturaer og projekter. Hver type har egen/egne mappe(r). Ellers har den baglæns synk intet kriterium.

Nej, værktøjet bruger ét brugerendepunkt. Alle synkprocesser kører under én cloud-administrator (app). Rettigheder til oprettede mapper / filer automatiseres ikke. Administrer dem i din cloudlagerløsning.

Appen antager, at den binære indhold af vedhæftninger gemmes i Cloud Client i stedet for på Odoo-serveren. Sådanne vedhæftninger i Odoo bliver af typen URL, og du kan når som helst åbne dem fra vedhæftningsfeltet eller fra Cloud Client.

Efter opsætningen kræves ingen manuelle handlinger: synkroniseringen er fuldt automatisk. Beslut, hvilke Odoo-dokumenttyper der skal synkroniseres, og opret en relateret model for hver (kunder, salgs- eller indkøbsordrer, opgaver, projekter osv.).

Ja, det kan du. Opret en regel til hver og anvend filtre: for eksempel efter projekttype.

Gør filtrene indbyrdes udelukkende, så et dokument kan tildeles entydigt. For eksempel: «kunde men ikke leverandør», «leverandør men ikke kunde». Ellers hopper dokumentmappen fra én model til en anden.

Nej, værktøjet er kun en teknisk kerne. Du skal også bruge forbindelsen til din cloud-klient.

Ja, selvom processen kan være langsom med mange mapper/vedhæftninger. Kunder har dog rapporteret miljøer med >10k partnere og ~5k produktvarianter, og processerne var acceptable.

Nogle punkter:

1. Synken er bygget, så ethvert element synkroniseres og ikke går tabt, selv om det ikke er hurtigt. FIFO-køer og commit af hvert job garanterer det.
2. Antallet af objekter kan begrænses logisk. Modelkonfigurationen lader dig udelukke forældede poster (f.eks. arkiverede partnere eller ordrer fra for 2 år siden).

Nej. Vi har stærke grunde til at undgå realtidssynk:

• Ydeevne. Ved realtidssynk giver hver filupload en indlæsningsskærm.

• Konflikter. Hvis 2 brugere ændrer et element samtidig, kan det blive uløseligt. Med almindelige job kan vi rette bagefter; i realtid skulle der bruges en kø, endnu mere vildledende.

• Funktionalitet. Især omdøbning og omstrukturering. Den baglæns synk bygger strengt på kataloglogikken og tjekker 100 % af elementerne ved hver synk. Efter hver opdatering ville det være tusindvis af anmodninger i sekundet. Ellers ville ændringer gå tabt.

Nej, denne funktion er først tilgængelig fra version 15.

Ja, afhængigt af din cloud-klients konfiguration.

Nej, tags synkroniseres ikke. Vi overvejede funktionen tidligere, men besluttede ikke at indføre den af flere grunde:

• Forbindelsesbiblioteket understøtter ikke hentning eller opdatering af OwnCloud-tags

• Odoo-vedhæftninger har ikke attributten «tags», og det er uklart, hvornår sådanne tags ville blive tildelt brugere.

• Da appen giver tovejs synk, kan der opstå kritiske konflikter, som er svære at løse.

Ifolge de gaeldende regler for Odoo Apps Store:

• Hvert modul kobt til version 12.0 eller tidligere giver adgang til alle versioner op til 12.0.
• Fra version 13.0 skal hver modulversion kobes separat.
• Uanset version giver kobet ret til alle opdateringer og fejlrettelser inden for en hovedversion.

faOtools-teamet styrer ikke disse regler. Ved sporgsmaal, kontakt Odoo Apps Store-representanterne direkte.

Den mest direkte tilgang er Odoo-butikkens indbyggede arbejdsgang:

1. Abn modulets side, og klik pa Deploy on odoo.sh

2. Du bliver omdirigeret til GitHub. Log ind, og klik pa Create a new repo, eller brug et eksisterende. Repot skal vaere privat. Apps under OPL-1 ma ikke offentliggores. Opret om nodvendigt et nyt repo til Odoo.sh-projektet

3. Ga derefter til odoo.sh, klik pa Deploy, bekraeft, og klik pa Continue. Installationen starter.

Disse trin installerer appen pa production-grenen. Til andre grene eller opdatering:

1. Download kildekoden fra Odoo-butikken

2. Commit modulet til GitHub-repot. Ingen app-mapper/filer ma sta i .gitignore. Repoer oprettet af odoo.sh kan ignorere vigtige stier (f.eks. /lib). Upload alle modulmapper og -filer

3. Deploy malgrenen i odoo.sh-projektet, eller vent pa det automatiske build, hvis indstillingerne angiver det.

Ja. Odoo laegger automatisk alle afhaengigheder i indkobskurven: udelad allerede kobte vaerktojer, sa du ikke betaler to gange.

En rod/orange advarsel pavirker ikke appens funktioner. Nogle gange bestar vores moduler ikke de standard automatiske tests, fordi de forventer en adfaerd, der er i konflikt med appens mal. Vi aendrer f.eks. prisberegningen, mens Odoo-testene sammenligner slutprisen med standardalgoritmen.

Tjek forst funktionerne i den deployede database. Virker alt?

Hvis du stadig mener, at advarslen pavirker reelle funktioner, kontakt os, og send de fulde installationslogfiler og den fulde liste over deployede moduler (kerne og tredjepart).

Nej, vi distribuerer kun vaerktojerne via den officielle Odoo-appbutik.

Desvaerre har vi ikke tekniske midler til individuelle priser.

Nej, tredjepartsapps kan ikke bruges pa Odoo Online. Odoo SaaS blokerer den mulighed.

Ja, vaerktojet kraver alle moduler markeret som afhaengigheder. Prisen pa appsiden inkluderer allerede disse afhaengigheder.