Cloud Storage Solutions v.11

Não, esta funcionalidade só existe a partir da versão 15. Antes, o módulo usa uma estrutura de pastas predefinida:

1. Odoo - pasta raiz da sincronização

2. Modelos - pastas para cada tipo de documento Odoo. Por exemplo «Projects», «Partners». Por domínio pode haver pastas mais específicas: «Customer 1 Projects», «Projects of the Customer 2», «Internal Projects», etc.

3. Objetos - pastas para cada documento, p. ex. «Project 1» ou «Customer 1»

4. Ficheiros e pastas deste documento Odoo a sincronizar.

Assim pode ter, por exemplo:

• Odoo / Projects / Project 1 / ficheiros e pastas do projeto 1

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

• Odoo / Customers / Customer 1 / ficheiros e pastas do cliente 1

A estrutura é sempre plana: só esses níveis. Não se misturam vários tipos de documento na mesma ramificação. Na pasta «Customer 1» não se guardam ao mesmo tempo encomendas, faturas e projetos. Cada tipo tem a(s) sua(s) pasta(s). Caso contrário, a sincronização inversa não teria critério.

Não, a ferramenta usa um único ponto de extremidade de utilizador. Todos os processos de sincronização correm sob um único administrador cloud (aplicação). Os direitos das pastas / ficheiros criados não são automatizados. Administre-os na sua solução de armazenamento cloud.

A aplicação assume que o conteúdo binário dos anexos fica no Cloud Client e não no servidor Odoo. Esses anexos no Odoo passam a ser do tipo URL e pode aceder-lhes a qualquer momento a partir da caixa de anexos ou do Cloud Client.

Após a configuração, não são necessárias ações manuais: a sincronização é totalmente automática. Decida que tipos de documento Odoo devem ser sincronizados e configure um modelo relacionado para cada um (clientes, encomendas de venda ou compra, tarefas, projetos, etc.).

Sim, pode. Para isso, prepare uma regra para cada uma e aplique filtros: por exemplo, por tipo de projeto.

Torne os filtros mutuamente exclusivos para que um documento seja atribuído de forma inequívoca. Por exemplo: «cliente mas não fornecedor», «fornecedor mas não cliente». Caso contrário, a pasta do documento saltaria de um modelo para outro.

Não, a ferramenta é apenas um núcleo técnico. Precisa também do conector do seu cliente cloud.

Sim, embora com muitas pastas/anexos o processo possa ser lento. Ainda assim, clientes relataram ambientes com >10k parceiros e ~5k variantes de produto, e os processos foram aceitáveis.

Alguns pontos:

1. A sincronização está feita para que qualquer item seja sincronizado e não se perca, ainda que não seja rápido. Filas FIFO e o commit de cada trabalho garantem-no.
2. O número de objetos pode ser limitado logicamente. A configuração dos modelos permite restringir itens obsoletos (p. ex. parceiros arquivados ou encomendas de há 2 anos).

Não. Temos razões fortes para evitar a sincronização em tempo real:

• Desempenho. Se a sincronização for em tempo real, cada carregamento de ficheiro mostra o ecrã de espera.

• Conflitos. Se 2 utilizadores alterarem um item ao mesmo tempo, a situação pode ficar sem solução. Com trabalhos regulares podemos corrigir depois; em tempo real seria preciso uma fila, ainda mais confusa.

• Funcionalidade. Em especial, mudar o nome e reestruturar. A sincronização inversa baseia-se na lógica dos diretórios e em cada sincronização verifica 100 % dos itens. Após cada atualização seriam milhares de pedidos por segundo. Caso contrário, as alterações perder-se-iam.

Não, esta funcionalidade só fica disponível a partir da versão 15.

Sim, consoante a configuração do seu cliente cloud.

Segundo as politicas atuais da Odoo Apps Store:

• Cada modulo comprado para a versao 12.0 ou anterior da acesso a todas as versoes ate 12.0.
• A partir da versao 13.0, cada versao do modulo deve ser comprada em separado.
• Independentemente da versao, a compra da direito a todas as atualizacoes e correcoes dentro de uma versao major.

A equipa faOtools nao controla essas politicas. Para questoes, contacte diretamente os representantes da Odoo Apps Store.

A forma mais direta e usar o fluxo da loja Odoo:

1. Abra a pagina do modulo e clique em Deploy on odoo.sh

2. Sera redirecionado para o GitHub. Inicie sessao e clique em Create a new repo ou use um existente. O repositorio deve ser privado. Nao e permitido publicar as apps com licenca OPL-1. Se necessario, crie um repo novo para o projeto Odoo.sh

3. Depois, no odoo.sh, clique em Deploy, confirme e clique em Continue. A instalacao comeca.

Estes passos instalam a app no ramo de producao. Para outros ramos ou para atualizar:

1. Transferir o codigo-fonte da loja Odoo

2. Fazer commit do modulo no repositorio GitHub. Nenhuma pasta/ficheiro da app deve estar no .gitignore. Os repos criados pelo odoo.sh podem ignorar caminhos importantes (p. ex. /lib). Envie todos os diretorios e ficheiros do modulo

3. Fazer deploy do ramo alvo do projeto odoo.sh ou esperar pela compilacao automatica se as definicoes o assumirem.

Sim. O Odoo adiciona automaticamente as dependencias ao carrinho: exclua as ferramentas ja compradas para nao pagar duas vezes.

Um aviso vermelho/laranja nao afeta as funcoes da app. Por vezes os nossos modulos nao passam os testes automaticos padrao, porque estes assumem um comportamento que conflitua com os objetivos da app. Por exemplo, alteramos o calculo do preco e os testes Odoo comparam o preco final com o algoritmo padrao.

Primeiro, verifique as funcoes da base implantada. Esta tudo a funcionar?

Se ainda achar que o aviso afeta funcoes reais, contacte-nos e envie os registos completos de instalacao e a lista completa de modulos implantados (nucleo e de terceiros).

Nao, so distribuimos as ferramentas atraves da loja oficial de aplicacoes Odoo.

Infelizmente, nao temos meios tecnicos para oferecer precos individuais.

Nao, as apps de terceiros nao podem ser usadas no Odoo Online. O Odoo SaaS bloqueia essa possibilidade.

Sim, a ferramenta precisa de todos os modulos assinalados nas dependencias. O preco na pagina da app ja as inclui.