Cloud Storage Solutions v.10

No, questa funzione esiste solo dalla versione 15. Prima il modulo usa una struttura di cartelle predefinita:

1. Odoo - cartella radice della sync

2. Modelli - cartelle per ogni tipo di documento Odoo. Ad esempio «Projects», «Partners». Per dominio possono esserci cartelle più specifiche: «Customer 1 Projects», «Projects of the Customer 2», «Internal Projects», ecc.

3. Oggetti - cartelle per ogni documento, es. «Project 1» o «Customer 1»

4. File e cartelle di questo documento Odoo da sincronizzare.

Potete così avere ad esempio:

• Odoo / Projects / Project 1 / file e cartelle del progetto 1

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

• Odoo / Customers / Customer 1 / file e cartelle del cliente 1

La struttura è sempre piatta: solo questi livelli. Tipi di documento diversi non stanno nello stesso ramo. Nella cartella «Customer 1» non si tengono insieme ordini, fatture e progetti. Ogni tipo ha la/e propria/e cartella/e. Altrimenti la sync inversa non avrebbe un criterio.

No, lo strumento usa un unico endpoint utente. Tutti i processi di sync avvengono sotto un solo admin cloud (app). I diritti delle cartelle / file creati non sono automatizzati. Gestiteli nella vostra soluzione di storage cloud.

L'app presuppone che il contenuto binario degli allegati sia conservato nel Cloud Client e non sul server Odoo. Tali allegati in Odoo diventano di tipo URL e potete accedervi in qualsiasi momento dalla casella allegati o dal Cloud Client.

Dopo la configurazione non servono azioni manuali: la sincronizzazione è completamente automatica. Decidete quali tipi di documento Odoo sincronizzare e impostate un modello correlato per ciascuno (clienti, ordini di vendita o acquisto, attività, progetti, ecc.).

Sì, è possibile. Preparate una regola per ciascuna e applicate dei filtri: ad esempio per tipo di progetto.

Rendete i filtri mutuamente esclusivi così un documento viene assegnato in modo certo. Ad esempio: «cliente ma non fornitore», «fornitore ma non cliente». Altrimenti la cartella del documento passerebbe da un modello all'altro.

No, lo strumento è solo un nucleo tecnico. Serve anche il connettore del vostro client cloud.

Sì, anche se con molte cartelle/allegati il processo può essere lento. I clienti hanno comunque segnalato ambienti con >10k partner e ~5k varianti prodotto, e i processi erano accettabili.

Alcuni punti:

1. La sync è costruita perché ogni elemento venga sincronizzato e non perso, anche se non è veloce. Code FIFO e il commit di ogni job lo garantiscono.
2. Il numero di oggetti può essere limitato logicamente. La configurazione dei modelli consente di escludere elementi obsoleti (es. partner archiviati o ordini di 2 anni fa).

No. Abbiamo ragioni solide per evitare la sincronizzazione in tempo reale:

• Prestazioni. Se la sync è in tempo reale, ogni caricamento file mostra la schermata di attesa.

• Conflitti. Se 2 utenti modificano un elemento insieme, la situazione può restare irrisolta. Con job regolari si può correggere dopo; in tempo reale servirebbe una coda, ancora più fuorviante.

• Funzionalità. In particolare rinomina e ristrutturazione. La sync inversa si basa strettamente sulla logica delle directory e a ogni sync controlla il 100 % degli elementi. Dopo ogni aggiornamento sarebbero migliaia di richieste al secondo. Altrimenti le modifiche andrebbero perse.

No, questa funzione è disponibile solo dalla versione 15.

Sì, in base alla configurazione del client cloud.

Secondo le politiche attuali dell'Odoo Apps Store:

• Ogni modulo acquistato per la versione 12.0 o precedente da accesso a tutte le versioni fino alla 12.0.
• Dalla versione 13.0 ogni versione del modulo va acquistata separatamente.
• Indipendentemente dalla versione, l'acquisto da diritto a tutti gli aggiornamenti e le correzioni entro una major version.

Il team faOtools non controlla queste politiche. Per qualsiasi domanda, contattate direttamente i rappresentanti dell'Odoo Apps Store.

L'approccio piu diretto e il flusso integrato dello store Odoo:

1. Apri la pagina del modulo e fai clic su Deploy on odoo.sh

2. Verrai reindirizzato a GitHub. Accedi e fai clic su Create a new repo o usa uno esistente. Il repository deve essere privato. Non e consentito pubblicare le app con licenza OPL-1. Se serve, crea un nuovo repo per il progetto Odoo.sh

3. Poi, in odoo.sh, fai clic su Deploy, conferma e fai clic su Continue. Parte l'installazione.

Questi passaggi installano l'app sul branch di produzione. Per altri branch o per aggiornare:

1. Scarica il codice sorgente dallo store Odoo

2. Esegui il commit del modulo nel repository GitHub. Nessuna cartella/file dell'app deve essere in .gitignore. I repo creati da odoo.sh a volte ignorano percorsi importanti (es. /lib). Carica tutte le directory e i file del modulo

3. Esegui il deploy del branch di destinazione del progetto odoo.sh oppure attendi la build automatica se previsto.

Si. Odoo aggiunge automaticamente le dipendenze al carrello: escludi gli strumenti gia acquistati per non pagare due volte.

Un avviso rosso/arancione non influisce sulle funzioni dell'app. A volte i nostri moduli non superano i test automatici standard perche questi assumono un comportamento in conflitto con gli obiettivi dell'app. Ad esempio cambiamo il calcolo del prezzo, mentre i test Odoo confrontano il prezzo finale con l'algoritmo standard.

Controllate prima le funzioni del database distribuito. Funziona tutto?

Se pensate ancora che l'avviso influisca sulle funzioni reali, contattateci e inviate i log di installazione completi e l'elenco completo dei moduli distribuiti (core e di terze parti).

No, distribuiamo gli strumenti solo tramite lo store ufficiale delle app Odoo.

Purtroppo non abbiamo i mezzi tecnici per prezzi individuali.

No, le app di terze parti non si possono usare su Odoo Online. Odoo SaaS blocca questa possibilita.

Si, lo strumento richiede tutti i moduli indicati nelle dipendenze. Il prezzo sulla pagina dell'app le include gia.