Cloud Storage Solutions v.8

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. Arquivos e pastas deste documento Odoo a sincronizar.

Assim pode ter, por exemplo:

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

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

• Odoo / Customers / Customer 1 / arquivos 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 (aplicativo). Os direitos das pastas / arquivos criados não são automatizados. Administre-os na sua solução de armazenamento cloud.

A aplicativo 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 arquivo 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 políticas atuais da Odoo Apps Store:

• Cada módulo comprado para a versao 12.0 ou anterior da acesso a todas as versões ate 12.0.
• A partir da versao 13.0, cada versao do módulo deve ser comprada em separado.
• Independentemente da versao, a compra da direito a todas as atualizações e correcoes dentro de uma versao major.

A equipa faOtools nao controla essas políticas. Para questões, contacte diretamente os representantes da Odoo Apps Store.

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

1. Abra a página do módulo e clique em Deploy on odoo.sh

2. Será redirecionado para o GitHub. Inicie sessão e clique em Create a new repo ou use um existente. O repositorio deve ser privado. Nao e permitido publicar as apps com licença OPL-1. Se necessário, crie um repo novo para o projeto Odoo.sh

3. Depois, no odoo.sh, clique em Deploy, confirme e clique em Continue. A instalação começa.

Estes passos instalam a app no ramo de produção. Para outros ramos ou para atualizar:

1. Transferir o código-fonte da loja Odoo

2. Fazer commit do módulo no repositorio GitHub. Nenhuma pasta/arquivo da app deve estar no .gitignore. Os repos criados pelo odoo.sh podem ignorar caminhos importantes (p. ex. /lib). Envie todos os diretórios e arquivos do módulo

3. Fazer deploy do ramo alvo do projeto odoo.sh ou esperar pela compilacao automática se as definições o assumirem.

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

Um aviso vermelho/laranja nao afeta as funções da app. Por vezes os nossos módulos nao passam os testes automáticos padrão, porque estes assumem um comportamento que conflitua com os objetivos da app. Por exemplo, alteramos o cálculo do preço e os testes Odoo comparam o preço final com o algoritmo padrão.

Primeiro, verifique as funções da base implantada. Esta tudo a funcionar?

Se ainda achar que o aviso afeta funções reais, contacte-nos e envie os registos completos de instalação e a lista completa de módulos implantados (nucleo e de terceiros).

Nao, so distribuimos as ferramentas através da loja oficial de aplicações Odoo.

Infelizmente, nao temos meios tecnicos para oferecer preços 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 módulos assinalados nas dependências. O preço na página da app ja as inclui.