Histórico da Página
...
| Informações | ||
|---|---|---|
| ||
Para consultar a descrição completa de cada requisito, clique aqui. |
| Categoria | O que o Review da Solução avalia |
| Documentação de uso | Garante que a documentação (recursos, regras, instalação, pré-requisitos, etc.) seja completa, acessível e atualizada para o usuário final e administrador. |
| Desenvolvimento | Verifica se o código segue as boas práticas do TOTVS Fluig e evita variações técnicas, consultas diretas ao banco, bibliotecas desatualizadas, códigos duplicados e configurações fixas. |
| Segurança | Assegura que a solução não exponha vulnerabilidades e que as informações sejam protegidas. Exige o uso de conexões seguras (SSL/TLS) em serviços externos. |
| Distribuição | Confirma se a solução segue as diretrizes para ser empacotado e publicado. |
| Privacidade | Garante que a solução tenha Termos de uso e Política de privacidade adequados à legislação, com transparência sobre a coleta e tratamento de dados. |
| Técnico | Garante que o parceiro envie o código-fonte completo e o artefato compilado devidamente. |
| Instalação | Verifica se a instalação é isenta de erros. O instalador deve executar todos os procedimentos (deploy, criação de registros, etc.) e validar permissões/pré-requisitos automaticamente. |
| Onboarding | Assegura que a solução proporcione um Onboarding rápido e simples, sem exigir configurações manuais ou processos adicionais após a instalação. |
| Uso | Garante que a solução funcione sem travamentos ou erros, oferecendo boa usabilidade, interface responsiva, mensagens claras e conteúdo sem erros gramaticais. |
| Processos | Garante que a solução Flows esteja configurado corretamente, sem inconsistências. |
| Configuração | Garante que a solução permita ao administrador controlar o acesso e a disponibilidade do app da solução no ambiente. |
| QA | Garante que o parceiro forneça uma licença válida para testes, caso a solução possua licenciamento adicional, para validação completa. |
...
| Item | Descrição | Detalhes/Exemplos | Link de apoio |
|---|---|---|---|
1. Imagens e informações da Store incompletas | Falta de banners, thumbnails ou descrição adequada do appda solução. | - | |
2. Documentação insuficiente ou desatualizada | Falta de documentação dentro do appda solução. | Não detalha instalação, parametrização, regras de negócio ou integrações. | |
3. Não informar o que o app a solução altera no TOTVS Fluig | Não detalhar na documentação o que o app a solução altera no TOTVS Fluig. | Registro de formulários, processos, papéis, grupos e demais mudanças. | Alterações no Fluig: como detalhá-las na documentação técnica? |
4. Ausência de canal de suporte e SLA | Documentação sem informações de atendimento ao cliente. | - | Por que é necessário incluir na documentação o canal de suporte e o tempo de SLA? |
5. Erros de grafia da marca e conceitos do TOTVS Fluig | Uso incorreto da marca e conceitos. | “GED" no lugar de “ECM”, uso incorreto de “TOTVS Fluig Plataforma”, etc. | Como usar corretamente conceitos, recursos, marcas ou submarcas do Fluig? |
6. Termos de Uso e Política de Privacidade ausentes | Documentos não disponíveis dentro do appda solução. | - | |
7. Uso de console.log e debugs em produção | Uso de comandos de debug em código de produção. | - | |
8. Arquivos não minificados (JS/CSS) | Impacta performance e não segue padrão oficial. | - | |
9. Logs sem identificação do appda solução | Falta de prefixo específico para rastreabilidade. | Exemplo: log.info(“@<Nome do App da solução + Parceiro>” + message); | |
10. Arquivos obrigatórios mal preenchidos | Preenchimento incorreto de arquivos essenciais. | application.info, component.xml, page.xml, versionamento incorreto. | |
11. Uso de APIs internas | Utilização de APIs que não são públicas. | - | |
12. Código com recursos desnecessários ou prejudiciais | Código com elementos que não agregam valor ou são prejudiciais. | Código comentado excessivo, valores fixos. | |
13. Arquivos não utilizados no pacote | Inclusão de arquivos que não são necessários no pacote de distribuição. | - | |
14. Uso de fonts/links externos sem necessidade | Dependência desnecessária de recursos externos. | - | Passo a Passo: Adicionar Recursos Externos ao Widget (JS/CSS) |
15. Falta de i18n (internacionalização) | O aplicativo A solução não suporta diferentes idiomas. | - | Passo a Passo: Configuração de Internacionalização (i18n) em Widgets |
16. Sobrescrever CSS interno do TOTVS Fluig | Modificação de estilos padrões do TOTVS Fluig. | Gera conflitos visuais e funcionais. | |
17. Processos sem imagem do diagrama | Fluxos de processo sem a imagem representativa do diagrama. | ||
18. Importação incorreta de JS/CSS | Referência feita no .ftl ao invés de usar o application.info. | - | Passo a Passo: Adicionar Recursos Externos ao Widget (JS/CSS) |
19. Não utilizar o Fluig Style Guide | Desrespeito ao guia de estilo visual do TOTVS Fluig. | - | |
20. Acesso direto ao Banco de Dados | É proibido usar JDBC direto ou consultas SQL hardcoded. | Use sempre Datasets e Serviços. | Proibição de Acesso Direto ao Banco de Dados (DB) e Otimização de Consultas |
21. Bibliotecas Obsoletas | Uso de versões antigas ou bibliotecas com vulnerabilidades conhecidas (CVEs). | - | |
22. Variáveis Fixas | Dados sensíveis ou de configuração fixos no código. | IPs, senhas, e-mails ou caminhos de servidor fixos. Tudo deve ser parametrizável. | Não Utilizar Recursos Técnicos com Valores Fixos (Acesso Dinâmico) |
...
- Portal do Parceiro: A comunicação principal ocorre diretamente pelo Portal de parceiros a ferramenta de submissão.
- Chat Exclusivo: Utilize o grupo de chat criado pela TOTVS no Google Chat para interações rápidas.
- E-mail de Apoio: [email protected].
| Dica |
|---|
Ao enviar um e-mail, sempre coloque no assunto o nome da sua empresa e o motivo (ex: "Dúvida Técnica - [Nome da sua Empresa] - [Nome da sua Solução]" ou "Solicitação de Acesso - [Nome da sua Empresa]") para agilizar o atendimento. |
...