Site da SuiteCRM
O site suitecrm.com do SuiteCRM tem muitos recursos excelentes, incluindo:
– Fóruns da comunidade SuiteCRM – Venha e diga oi!
– SuiteCRM Blog

Recursos externos do SuiteCRM
SuiteCRM GitHub – O código-fonte SuiteCRM está hospedado no GitHub. Aqui você pode obter alterações de código de ponta e até contribuir com código.

Recursos SugarCRM
SuiteCRM tem se esforçado para permanecer compatível com a edição da comunidade SugarCRM e grande parte da documentação ainda é válida. A versão apropriada para informações do SuiteCRM é 6.5. Versões de documentação superiores a esta (ou seja, 7) provavelmente não serão relevantes.
Docs do desenvolvedor do SugarCRM versão 6.5
SugarCRM Developer Blog

Links Técnicos
PHP – a principal linguagem usada pelo SuiteCRM.
Smarty – A linguagem de templates usada em todo o SuiteCRM.
XDebug – extensão de depuração / criação de perfil para PHP.
Git – Sistema de controle de versão distribuído.
YUI – Biblioteca Javascript legada usada no SuiteCRM.
JQuery – biblioteca Javascript usada no SuiteCRM – preferível ao YUI.
Biblioteca de e-mail do PHPMailer usada no SuiteCRM.
APC – Cache Alternativo de PHP. Cache de Opcode PHP compatível com SuiteCRM
WinCache – cache de PHP do Windows. Cache de Opcode PHP compatível com SuiteCRM
PHPStorm – PHP IDE (pago).
Eclipse PHP Development Tools – PHP IDE (gratuito e de código aberto).

Outros Links
SalesAgility – A empresa por trás do SuiteCRM.
Jim Mackin – Site pessoal do autor original deste Guia do Desenvolvedor.

The post Recursos Adicionais first appeared on Documentação.

Princípios gerais e exemplos de consultas SQL

Identificadores únicos
SuiteCRM usa UUIDs para seus identificadores únicos. Eles têm a seguinte aparência: 46c35607-bcad-c7f1-1745-558d6b858b27. Eles podem ser gerados em SQL e inseridos em outras consultas como uma sub-seleção:
UPDATE some_table SET id=(SELECT uuid());

Historicamente, desde os dias do SugarCRM, esses ids seguiram este formato, mas na prática qualquer formato era permitido, numérico, string, etc., desde que fosse único. Isso às vezes facilita muito as importações, permitindo que os esquemas de numeração anteriores sejam mantidos.

Os campos personalizados
Os campos personalizados são salvos em tabelas com o mesmo nome do módulo em que são definidos, mas com um sufixo _cstm anexado. Cada campo personalizado terá o nome que você inseriu no Studio, com um sufixo _c. Aqui está um exemplo de consulta para unir a tabela de um módulo com alguns campos personalizados (neste caso, um campo chamado idade quando criado no Studio):
SELECT first_name, last_name, contacts_cstm.age_c
FROM contacts
LEFT JOIN contacts_cstm
ON contacts.id = contacts_cstm.id_c

Liste registros órfãos de contacts_cstm, onde o registro base não está presente, mas uma linha para ele ainda existe na tabela personalizada:
SELECT * — DELETE ChildTable
FROM contacts_cstm ChildTable
LEFT JOIN contacts ParentTable
ON ChildTable.id_c = ParentTable.id
WHERE ParentTable.id IS NULL

Essa consulta é um SELECT, mas se você alterar a primeira linha para o que está depois do comentário (-), ele excluirá essas linhas. Leia o aviso acima e decida com responsabilidade.

Relacionamentos
O SuiteCRM não depende do mecanismo de banco de dados para impor relacionamentos (restrições de chave estrangeira, etc.). Todas essas coisas são tratadas no nível do aplicativo em nosso próprio código PHP. Em geral, SuiteCRM também não faz nenhuma atualização ou exclusão em cascata, há apenas algumas exceções para alguns casos específicos. Isso significa que você pode precisar de alguma limpeza periódica do banco de dados.
Há um trabalho agendado “Prune banco de dados no primeiro dia do mês” que lida com algumas dessas tarefas, mas você precisa avaliar seu próprio caso para decidir sobre as tarefas de limpeza adequadas. Não existe uma solução “tamanho único” para isso, portanto, cada implementação deve seguir as etapas necessárias para seu próprio caso.
Existe uma tabela chamada relacionamentos que contém informações de metadados recuperadas dos vardefs.

Maneiras típicas de JOIN tabelas
Alguns exemplos de consultas devem ser suficientes para dar uma ideia de como as tabelas SuiteCRM normalmente se referem umas às outras:

1. A consulta para obter dados de um campo personalizado fornecido acima; Atravessar um campo Flex Relate onde vários tipos de registros conectados são permitidos.
2. O campo parent_type contém o nome do módulo relacionado, enquanto o parent_id é uma chave estrangeira para a tabela desse módulo
SELECT accounts.name, calls.name, calls.status
FROM accounts
INNER JOIN calls ON
calls.parent_type = ‘Accounts’ AND
calls.parent_id = accounts.id AND
calls.deleted = 0
WHERE accounts.deleted = 0

3. Uma consulta para percorrer um relacionamento muitos para muitos usando uma tabela intermediária. Neste exemplo, uma lista de nomes de contas e contatos vinculados:

SELECT accounts.name, contacts.first_name, contacts.last_name
FROM accounts
INNER JOIN accounts_contacts
ON (accounts.id = accounts_contacts.account_id AND accounts_contacts.deleted = 0)
INNER JOIN contacts
ON (contacts.id = accounts_contacts.contact_id AND contacts.deleted = 0)
WHERE accounts.deleted = 0
ORDER BY accounts.name

Atravessar o relacionamento email_addresses para obter os endereços de e-mail dos usuários (facilmente adaptável para outros módulos, como Contatos, Leads, etc).
SELECT users.user_name,
email_address
FROM users
LEFT JOIN email_addr_bean_rel
ON email_addr_bean_rel.bean_id=users.id
AND email_addr_bean_rel.bean_module = ‘Users’
AND email_addr_bean_rel.primary_address = 1
AND email_addr_bean_rel.deleted = 0
LEFT JOIN email_addresses
ON email_addresses.id = email_addr_bean_rel.email_address_id
AND email_addresses.deleted = 0

Limpando relacionamentos com registros excluídos
Quando você apaga um registro de um módulo, em muitos casos o SuiteCRM não apaga todos os registros associados, porque é impossível decidir quais devem ou não ser removidos sem conhecer as especificidades de cada negócio. Não excluir é genericamente a abordagem sensata e conservadora. Mas se você decidir no seu caso que precisa remover algumas sobras de registros existentes anteriormente, o seguinte deve ajudá-lo.

Aqui está um exemplo de consulta para procurar registros órfãos, neste caso entradas de grupos de segurança que se referem a registros ausentes:
SELECT record_id, module, s.deleted, c.last_name, c.deleted
FROM securitygroups_records s
LEFT JOIN contacts c
ON s.record_id = c.id
WHERE c.id IS NULL AND
s.module=’Contacts’

Esta consulta pode ser facilmente transformada em um DELETE para remover esses registros.

Você também pode fazer uma exclusão mais simples de linhas onde excluído = ‘1’, onde o próprio relacionamento foi excluído, mesmo se o record_id ainda existir:
SELECT record_id, module, deleted
FROM securitygroups_records
WHERE module=’Contacts’ AND deleted=’1′

The post Esquema de banco de dados first appeared on Documentação.

Uso
/ example string definition (only for understanding the next examples):
$app_strings[‘LBL_EXAMPLE_APP_STR’] = ‘Example Application String’;
$mod_strings[‘LBL_EXAMPLE_MOD_STR’] = ‘Example string for a specified module’;
$mod_strings[‘LBL_EXAMPLE_VARIABLE’] = ‘Example string to use value of {foo}’;
// Using translation for any strings
$text = new LangText(‘LBL_EXAMPLE_APP_STR’);
echo $text;
// Using translation for any strings with replaced strings values
$text = new LangText(‘LBL_EXAMPLE_VARIABLE’, [‘foo’ => ‘bar’]);
echo $text; // output: Example string to use value of bar
// Using translation only for Module Strings
$text = new LangText(‘LBL_EXAMPLE_MOD_STR’, null, LangText::USING_MOD_STRINGS);
echo $text;
// Using translation only for Application Strings
$text = new LangText(‘LBL_EXAMPLE_APP_STR’, null, LangText::USING_APP_STRINGS);
echo $text;

The post Traduzindo Strings first appeared on Documentação.

Por exemplo. se o /path/to/Example.php contém uma classe Example, o teste relacionado deve estar em tests / path / to / ExampleTest.php:

Exemplo para um teste PHPUnit
conteúdo de testes / caminho / para / ExampleTest.php:
use SuiteCRM\Test\SuitePHPUnitFrameworkTestCase;
// note: SuitePHPUnitFrameworkTestCase extends SuiteCRM\TestCaseAbstract, which extends PHPUnit_Framework_TestCase. class ExampleTest extends SuitePHPUnitFrameworkTestCase { public function testDoingSomething() { $example = new Example(); $results = $example->doSomething(); $this->assertSame(‘expected value’, $results); } }

Veja mais sobre os testes PHPUnit em https://phpunit.readthedocs.io

Aulas de teste:
– classe abstrata SuiteCRM \ TestCaseAbstract
Implementação de um caso de teste abstrato, essa classe substitui os métodos setUp () e tearDown () para lidar com a criação e reversão da transação do banco de dados.

Testes de segurança de estado
Anteriormente, tínhamos ajudantes StateSaver e StateChecker para tornar mais fácil escrever testes seguros de estado. Isso se provou lento e complexo, então nós o substituímos por um sistema mais padrão envolvendo transações de banco de dados que são revertidas após cada teste de unidade individual.
– Mantenha o estado do ambiente global do sistema limpo, especialmente em testes.
– Se um teste deixar alguns dados extras no banco de dados, sistema de arquivos, superglobais, etc., isso pode alterar o comportamento dos outros testes executados posteriormente. Ao escrever um novo teste, certifique-se de que é seguro para o estado, o que significa que os testes não devem deixar nenhum dado “lixo” no estado do ambiente de teste.
– Para garantir que o estado permaneça inalterado quando um teste de unidade é executado, existem algumas coisas que você deve ter em mente:
– Estado do banco de dados, isso é tratado automaticamente pelo sistema de reversão da transação do banco de dados. No entanto, se você criar explicitamente uma transação de banco de dados em seu teste, precisará certificar-se de que o teste usa a estratégia de limpeza de truncamento em vez da estratégia de transação padrão.
– Mudanças em arquivos no sistema de arquivos, atualmente não fazemos isso.
– Nível de erro, se o seu teste depende de um nível de erro específico, você deve salvar o nível de relatório de erro que existe no início do teste, alterar o nível de erro e restaurá-lo no final do teste.
– Variáveis ​​globais do PHP, elas podem ser manipuladas pelo próprio PHPUnit, embora atualmente não usemos essa funcionalidade.
– Mudanças no PHP INI, elas precisam ser tratadas manualmente da mesma forma que os níveis de erro

Um exemplo de restauração do nível de relatório de erro em um teste:

<?php

use SuiteCRM\Test\SuitePHPUnitFrameworkTestCase;

class somethingTest extends SuitePHPUnitFrameworkTestCase {
public function testSomething() {
// Store the current error level and then set the reporting level to 0 for the test.
$errorLevelStored = error_reporting();
error_reporting(0);

    // Do test stuff

    // Restore error reporting level.
    error_reporting($errorLevelStored);
}

Como: Testar Imap
Desenvolvedores capazes de escrever teste IMAP (testes de unidade e de aceitação).

Se o modo de desenvolvedor definido e o nível de logger forem depurados, a classe ImapHandler registra cada chamada de imap, então cada chamada de método de imap registrada com o parâmetro chamado e os valores de retorno para que os desenvolvedores e testadores possam ver exatamente o que está acontecendo em segundo plano. Se imap_test definido, o sistema usa chamadas falsas por parâmetros de método predefinidos e valores de retorno em ImapHandlerFakeCalls.php para que os desenvolvedores possam adicionar mais testes para qualquer funcionalidade de e-mail, mesmo que precise de um recurso imap válido.

– ImapHandler: classe Wrapper para funções de extensão integrada de PHP IMAP.
– ImapHandlerFacotry: recupera um ImapHandlerInterface. Pode ser ImapHandler ou ImapHandlerFake. Use $ sugar_config [‘imap_test’] = true em config_override.php para ativar o modo de teste.
– ImapHandlerFake: classe Wrapper para funções de extensão integrada de PHP IMAP. (apenas testes)
– ImapHandlerFakeCalls.php: descreve os valores de retorno de funções imap falsas para cada chamada de função com parâmetros específicos em cada cenário de teste.
– ImapHandlerFakeData: Apenas para testes, ele lida com valores de retorno falsos para chamadas falsas em um wrapper IMAP.
– ImapHandlerInterface: Wrappers IMAP precisam implementar para que o sistema possa usá-lo como um manipulador IMAP.
– ImapTestSettingsEntry.php: para um ponto de entrada para definir o cenário de teste atual em qualquer teste de aceitação pode chamá-lo. (exemplo de ponto de entrada: index.php? entryPoint = setImapTestSettings & imap_test_settings = [índice da matriz em ImapHandlerFakeCalls.php])

Exemplo de uso em testes de unidade:
primeiro precisa incluir os seguintes arquivos:
include_once DIR . ‘/../../../../../include/Imap/ImapHandlerFakeData.php’;
include_once DIR . ‘/../../../../../include/Imap/ImapHandlerFake.php’;

Exemplo de teste de unidade para conexão imap (usando dados imap falsos)

public function testConnectMailserverUseSsl()
 {

     // using fake imap handler behaviour in test
     $fake = new ImapHandlerFakeData();

     // set up the fake handler behaviour
     $fake->add('isAvailable', null, [true]);
     $fake->add('setTimeout', [1, 60], [true]);
     $fake->add('setTimeout', [2, 60], [true]);
     $fake->add('setTimeout', [3, 60], [true]);
     $fake->add('getErrors', null, [false]);
     $fake->add('getConnection', null, [function () {
         // the current crm code needs a valid resource to an imap server
         // but also will accept a file resource
         return fopen('fakeImapResource', 'w+');
     }]);
     $fake->add('getMailboxes', ['{:/service=/notls/novalidate-cert/secure}', '*'], [[]]);
     $fake->add('ping', null, [true]);
     $fake->add('reopen', ['{:/service=}', 32768, 0], [true]);

     // instantiate a fake imap handler
     $imap = new ImapHandlerFake($fake);

     $_REQUEST['ssl'] = 1;

     // using fake imap in InboundEmail class (only for testing)
     $ie = new InboundEmail($imap);

     // test connection, it should pass
     $ret = $ie->connectMailserver();
     $this->assertEquals('true', $ret);
 }

variáveis ​​de configuração úteis:
$sugar_config[‘imap_test’] = true;
$sugar_config[‘logger’][‘level’] = ‘debug’;
$sugar_config[‘stack_trace_errors’] = false; // set to true for more details
$sugar_config[‘developerMode’] = true;
$sugar_config[‘show_log_trace’] = false; // set to true for more details

The post Escrevendo testes first appeared on Documentação.

Configure o ambiente de teste (bash):
Abra o terminal e execute o Robô:
./vendor/bin/robo configurar: testes

Configure o ambiente de teste (prompt de comando):
Abra o prompt de comando e execute o Robô:
. \ vendor \ bin \ robo configure: testes

The post Configurar ambiente de teste first appeared on Documentação.

Suites de teste
SuiteCRM oferece quatro suítes de teste diferentes.

Estabelecer Este guia assume que você já instalou e configurou uma versão compatível do PHP, MySQL 5.7 e Composer. Você pode configurar o CRM para teste com estas etapas:

1. Em seu emulador de terminal ou prompt de comando: caminho do cd / para / suitecrm / instância.
2. Instale dependências com o Composer: instalação do composer.
3. Crie um banco de dados MySQL chamado Automa_tests, junto com um usuário chamado Automa_tests e a senha Automated_tests. Na interface de linha de comando do MySQL:
4. mysql -e “CRIAR BANCO DE DADOS automatic_tests CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;”
5. mysql -u root -p -e “CRIAR USUÁRIO ‘Automated_tests’ @ ‘localhost’ IDENTIFICADO POR ‘Automated_tests’;”
6. mysql -u root -p -e “GRANT ALL PRIVILEGES ON Automated_tests. * TO ‘Automated_tests’ @ ‘localhost’;”
7. Configure as variáveis ​​de ambiente, consulte a seção de variáveis ​​de ambiente abaixo para obter mais informações.
8. Configure seu servidor Apache para que o servidor SuiteCRM esteja disponível em http: // localhost (ou qualquer URL de instância que você configurou na etapa anterior).
9. Instale o ChromeDriver para que você possa usá-lo para automatizar o navegador Chrome (você também precisará do Chrome ou Chromium instalado): ./vendor/bin/robo chromedriver: instalar Você também precisará de uma instância do ChromeDriver em execução em segundo plano para o conjunto de testes usar. Você pode usar ./vendor/bin/robo chromedriver: run para executar uma instância do ChromeDriver. Isso é necessário para os pacotes de instalação e aceitação.
10. Você pode atualizar sua versão do ChromeDriver, se necessário, com ./vendor/bin/robo chromedriver: install –reinstall.
11. Crie dependências de teste com ./vendor/bin/codecept build.
12. Configure o ambiente de codecepção personalizado para permitir a execução dos testes de instalação e aceitação localmente.
13. Consulte “Configurando o ambiente de teste” abaixo.
14. Instale o SuiteCRM.
15. Isso pode ser feito executando o pacote de instalação ou passando pelo processo de instalação em seu navegador. Ele deve estar disponível em http: //localhost/install.php.
16. Preencha o banco de dados com dados de teste para o conjunto de testes da API. Substitua DATABASE_NAME pelo nome do banco de dados MySQL configurado, provavelmente automatic_tests se você seguiu as instruções acima.
17. mysql -u root -p -D DATABASE_NAME -v -e “source tests / _data / api_data.sql”
18. mysql -u root -p -D DATABASE_NAME -v -e “source tests / _data / demo_users.sql”

Com isso, você deve ser capaz de executar as suítes de teste – observe que os testes de instalação só podem ser executados uma vez atualmente.

Variáveis ​​ambientais
Este é o método preferido para armazenar informações confidenciais, pois evita que as informações de segurança sejam enviadas para o repositório git. Você pode automatizar diferentes ambientes de desenvolvimento usando variáveis ​​de ambiente.

Variáveis ​​de ambiente do conjunto de testes

Instale o Test Suite:

Aceitação, API e pacotes de teste de instalação:

Suítes de teste de API:

Configurar variáveis ​​de ambiente com tarefa Robô
Abra o terminal e execute o Robô:
./vendor/bin/robo configurar: testes (Bash)

. \ vendor \ bin \ robo configure: testes (prompt de comando)

Isso adicionará interativamente as variáveis ​​de ambiente necessárias ao seu arquivo ~ / .bash_aliases. Você precisa reiniciar seu terminal / prompt de comando para obter as alterações. No macOS / Linux, você pode usar env para ver as variáveis ​​de ambiente atuais.

Observe que essas variáveis ​​se aplicam a todo o dispositivo, portanto, se você tiver mais de um CRM configurado localmente, todos usarão a mesma configuração.

Configurando o ambiente de teste
É recomendável que você execute o conjunto de testes com um ambiente personalizado configurado, para garantir que o conjunto de testes saiba onde está a instância de CRM e para permitir que você personalize o ambiente para suportar depuração, se necessário. Copie tests / _envs / custom.dist.yml para tests / _envs / custom.yml e leia os comentários do arquivo para configurar seu ambiente. custom.yml não será rastreado pelo git, então pode ser customizado para funcionar com seu ambiente local sem ser reiniciado ou acidentalmente confirmado.

Você pode executar testes de codecepção em um determinado ambiente, como: ./vendor/bin/codecept executar aceitação –env custom

Observe que o ambiente personalizado deve ser usado apenas com os conjuntos de teste de aceitação e instalação. Há também o ambiente travis-ci-hub.yml, que serve para executar os testes no Travis CI.

Consulte a documentação do Codeception para obter mais informações sobre a configuração do ambiente.

Executando as suítes de teste
Depois de configurados, você pode executar os conjuntos de testes com os seguintes comandos Robô:

Algumas coisas a serem observadas:
– Esses comandos usarão automaticamente o ambiente definido em tests / _envs / custom.yml para os conjuntos de teste de instalação e aceitação.
– Cada um desses comandos leva estes sinalizadores:
–debug: Imprime mais informações durante as execuções de teste, bom para depuração.
–fail-fast: interrompe a execução do conjunto de testes após a primeira falha.

– Cada um deles também pode ser passado para um diretório ou pasta específica se você quiser executar apenas alguns testes específicos, por exemplo, ./vendor/bin/robo tests: unit ./tests/unit/phpunit/modules/.
– A suíte de teste de instalação só pode ser executada uma vez atualmente, e todas as outras suítes de teste dependem do CRM que está sendo instalado.
– Os conjuntos de testes de instalação e aceitação usam testes automatizados de navegador com o Chrome e exigem que o usuário execute um processo ChromeDriver separado simultaneamente com o conjunto de testes. Como alternativa, você ativa a extensão ChromeDriver RunProcess fornecida em custom.dist.yml para que o ChromeDriver inicialize automaticamente sempre que os testes precisarem.

Outras opções de configuração

Docker
Você também pode executar o conjunto de testes usando o Docker, se preferir.

Variáveis ​​de ambiente de configuração (Docker Compose):
Você pode adicionar um arquivo .env à configuração do Docker Compose:
DATABASE_DRIVER=MYSQL
DATABASE_NAME=automated_tests
DATABASE_HOST=localhost
DATABASE_USER=automated_tests
DATABASE_PASSWORD=automated_tests
INSTANCE_URL=http://path/to/instance
INSTANCE_ADMIN_USER=admin
INSTANCE_ADMIN_PASSWORD=admin
INSTANCE_CLIENT_ID=suitecrm_client
INSTANCE_CLIENT_SECRET=secret

em seguida, faça referência a ele em seu contêiner php (docker-compose.yml):

version: '3'
 services:
   php:
       image: php:7.0-apache
       restart: always
       ports:
         - 9001:80
       environment:
        - DATABASE_DRIVER: $DATABASE_DRIVER
        - DATABASE_NAME: $DATABASE_NAME
        - DATABASE_HOST: $DATABASE_HOST
        - DATABASE_USER: $DATABASE_USER
        - DATABASE_PASSWORD: $DATABASE_PASSWORD
        - INSTANCE_URL: $INSTANCE_URL
        - INSTANCE_ADMIN_USER: $INSTANCE_ADMIN_USER
        - INSTANCE_ADMIN_PASSWORD: $INSTANCE_ADMIN_PASSWORD
        - INSTANCE_CLIENT_ID: $INSTANCE_CLIENT_ID
        - INSTANCE_CLIENT_SECRET: $INSTANCE_CLIENT_SECRET

Usando Docker Compose com o Selenium Hub
Em seu ambiente de desenvolvimento de selênio, é recomendável que você empregue docker compose para configurar um hub de selênio com um nó de selênio. Isso garantirá que sua versão do Chrome ou Firefox seja mantida atualizada com a versão mais recente. Além disso, você também pode executar várias versões do PHP na mesma máquina host.

Você pode configurar o selênio usando docker compose. Certifique-se de ter o seguinte em seu arquivo docker-compose.yml.

version: '3'
 services:
     selenium-hub:
       image: selenium/hub
       restart: always
       ports:
         - 4444:4444
     selenium-node-chrome:
       image: selenium/node-chrome-debug
       restart: always
       ports:
         - 5900:5900
       links:
         - selenium-hub:hub
       environment:
               - "HUB_PORT_4444_TCP_ADDR=selenium-hub"
               - "HUB_PORT_4444_TCP_PORT=4444"
     selenium-node-firefox:
       image: selenium/node-firefox-debug
       restart: always
       ports:
         - 5901:5900
       links:
         - selenium-hub:hub
       environment:
               - "HUB_PORT_4444_TCP_ADDR=selenium-hub"
               - "HUB_PORT_4444_TCP_PORT=4444"

Nota: você também pode escolher imagens diferentes para os nós, por exemplo, os nós sem suporte de vnc

Outras dicas
Adicione fornecedor / bin ao seu PATH
Isso tornará mais fácil executar o codeception e os outros comandos que residem no diretório vendor / bin /. Você pode adicionar a localização do fornecedor / bin à sua variável de ambiente PATH.

Adicionando fornecedor / bin ao PATH (Bash):
exportar PATH = $ PATH: / path / to / instance / vendor / bin
Adicionando fornecedor / bin ao PATH (Prompt de Comando):
defina PATH =% PATH%; C: \ path \ to \ instance \ vendor \ bin

Isso permite que você chame os comandos codecept e robo sem precisar prefixar o comando com sua localização. Ao executar qualquer um deles, você deve se certificar de que seu diretório de trabalho atual é o mesmo que sua instância SuiteCRM.

cd / caminho / para / suitecrm / instância /

aceitação de execução de codecept ou testes robô: aceitação

The post Teste Automatizado first appeared on Documentação.

Exemplo de pesquisa simulada
O exemplo abaixo mostra um mecanismo de busca que, independente de sua consulta de pesquisa, retornará o Administrador.
use SuiteCRM\Search\SearchEngine;
use SuiteCRM\Search\SearchQuery;
use SuiteCRM\Search\SearchResults;

class FakeSearch extends SearchEngine
{
public function search(SearchQuery $query)
{
return new SearchResults([
‘Users’ => [1]
]);
}
}

Exemplo de pesquisa de cidade
O exemplo acima é perfeitamente válido e funcionaria, mas é bastante inútil. Vamos tentar fazer um mecanismo de pesquisa simples que procura contas que têm o endereço em uma determinada cidade.
use SuiteCRM\Search\SearchEngine;
use SuiteCRM\Search\SearchQuery;
use SuiteCRM\Search\SearchResults;
class CitySearch extends SearchEngine
{
public function search(SearchQuery $query)
{
$sql = “SELECT id FROM accounts WHERE billing_address_city = ‘%s’ OR shipping_address_city = ‘%s’ LIMIT %d OFFSET %d”;

 // Format the query with the values
    $sql = sprintf(
        $sql, // SQL Query above
        $query->getSearchString(), // First equals
        $query->getSearchString(), // Second equals
        $query->getSize(), // LIMIT
        $query->getFrom() // OFFSET
    );

    // Get an instance of the dabatabase manager
    $db = DBManagerFactory::getInstance();
    // Perform the query
    $rows = $db->query($sql);
    // Initialize an array with the results
    $results = ['Accounts' => []];

    // Fetch the row and push the id in the results array
    while ($row = $db->fetchRow($rows)) {
        $results['Accounts'][] = $row['id'];
    }

    // Make a new SearchResults object with the results array and return
    return new SearchResults($results);
}

Exemplo de personalização de visualização
É possível personalizar como o mecanismo de pesquisa constrói a interface substituindo os métodos displayForm () e displayResults (). Se precisar de um grau mais alto de controle, você pode substituir o método searchAndDisplay () inteiramente.

Por padrão, displayForm () (exibindo a barra de pesquisa) e displayResults () (exibindo resultados e erros) chamam SearchFormController e SearchResultsController respectivamente para criar as visualizações. Essas duas classes devem ser usadas e personalizadas por mecanismos de pesquisa personalizados.

No exemplo abaixo, iremos substituir o método displayResults () para a classe acima e dizer ao mecanismo para carregar um arquivo de modelo diferente. O arquivo de modelo é um arquivo personalizado colocado na mesma pasta do mecanismo e mostrará uma visualização de tabela com três colunas: nome do bean, endereço de entrega e endereço de cobrança. O referido arquivo de modelo smarty pode ser encontrado logo após o código da classe.

use SuiteCRM\Search\SearchEngine;
use SuiteCRM\Search\SearchQuery;
use SuiteCRM\Search\SearchResults;
use SuiteCRM\Search\UI\SearchResultsController;

class CitySearchWithView extends SearchEngine
{
public function search(SearchQuery $query) { // Same as example above. }

public function displayResults(SearchQuery $query, SearchResults $results)
{
    // Override the displayResults() method to change how the `SearchWrapper` will show the results.

    // I have used an anonymous class just for simplicity in the example.
    // The extended controller can be normally placed in a separate file.
    $controller = new class($query, $results) extends SearchResultsController
    {
        public function __construct(SearchQuery $query, SearchResults $results)
        {
            parent::__construct($query, $results);
            // Let us load a custom template file.
            $this->view->setTemplateFile(__DIR__ . '/citysearch.tpl');
        }
    };

    // Finally ask the Controller to render the view.
    $controller->display();
}

citysearch.tpl

Exemplo de personalização de visualização
É possível personalizar como o mecanismo de pesquisa constrói a interface substituindo os métodos displayForm () e displayResults (). Se precisar de um grau mais alto de controle, você pode substituir o método searchAndDisplay () inteiramente.

Por padrão, displayForm () (exibindo a barra de pesquisa) e displayResults () (exibindo resultados e erros) chamam SearchFormController e SearchResultsController respectivamente para criar as visualizações. Essas duas classes devem ser usadas e personalizadas por mecanismos de pesquisa personalizados.

No exemplo abaixo, iremos substituir o método displayResults () para a classe acima e dizer ao mecanismo para carregar um arquivo de modelo diferente. O arquivo de modelo é um arquivo personalizado colocado na mesma pasta do mecanismo e mostrará uma visualização de tabela com três colunas: nome do bean, endereço de entrega e endereço de cobrança. O referido arquivo de modelo smarty pode ser encontrado logo após o código da classe.

Se você deseja mostrar diretamente uma mensagem de erro ao usuário, pode lançar uma SearchUserFriendlyException. Lembre-se de usar a estrutura de tradução se quiser que o erro seja localizado e nunca mostre detalhes que sejam (muito) técnicos.

Exemplo de envio de uma mensagem de erro amigável:
throw new SearchUserFriendlyException(translate(‘LBL_ERROR_MESSAGE_INVALID_QUERY’));

Conclusões
Para aprender mais sobre o Search Framework, não tenha medo de olhar o código em lib \ Search. Pretende ser simples, legível e bem documentado.

The post Criação de um mecanismo de pesquisa personalizado first appeared on Documentação.

Seus componentes residem no lib \ Search. Uma visão geral da estrutura do arquivo seguirá:

lib\Search
├── Exceptions
│   ├── SearchEngineNotFoundException.php
│   ├── SearchException.php
│   ├── SearchInvalidRequestException.php
│   └── SearchUserFriendlyException.php
├── UI
│   ├── MVC
│   │   ├── Controller.php
│   │   └── View.php
│   ├── templates
│   │   ├── search.form.tpl
│   │   └── search.results.tpl
│   ├── SearchFormController.php
│   ├── SearchFormView.php
│   ├── SearchResultsController.php
│   ├── SearchResultsView.php
│   └── SearchThrowableHandler.php
├── SearchEngine.php
├── SearchQuery.php
├── SearchResults.php
└── SearchWrapper.php

Classes Principais

SearchWrapper
A principal classe do Search Framework que permite realizar pesquisas facilmente usando métodos estáticos.

Motor de busca
Classe abstrata que contém utilitários para classes que a implementam. Os métodos integrados cuidam de mostrar os resultados e a visualização da pesquisa e podem ser substituídos, se necessário. As subclasses são necessárias apenas para implementar o método search (SearchQuery $ query), embora seja recomendado substituir o método validateQuery (SearchQuery $ query) também.

Consulta de pesquisa
O objeto SearchQuery envolve todos os parâmetros usados ​​pelo SearchWrapper e SearchEngine.

Possui um conjunto de métodos de fábrica para preencher os parâmetros de maneira padrão.

Ele contém os seguintes campos (disponíveis por meio de getters):
$query ─ uma string contendo a consulta de pesquisa. Quando vazio, nenhuma pesquisa será realizada.

$size ─ Um int especificando quantos resultados são solicitados. O padrão é 10.

$from ─ Um int usado para paginação, efetivamente um deslocamento. O padrão é 0.

$engine ─ uma string contendo o nome da classe SearchEngine a ser usada. Padrões de acordo com a configuração.

$options ─ uma matriz contendo opções que podem ser necessárias para SearchEngines personalizados.

Procurar Resultados
A classe SearchResults contém os resultados de uma pesquisa, junto com metadados como o tempo da pesquisa, o número total de ocorrências e a pontuação dos resultados.

Ele contém os seguintes campos (disponíveis por meio de getters):
$hits ─ uma matriz contendo os resultados da pesquisa. Os resultados são aninhados por módulo.

$scores ─ uma matriz com índices correspondentes aos de $ hits, contendo um float especificando os resultados.

$options ─ uma matriz contendo opções personalizadas para serem usadas pelos mecanismos.

$searchTime ─ um float com a quantidade de segundos que levou para realizar a pesquisa.

$total ─ Um int com o número total de ocorrências (sem paginação).

$groupedByModule ─ Sinalizador que especifica se o array $ hits é agrupado por módulo.

Diagrama de Comunicação
O diagrama abaixo ilustra como funciona o processo de pesquisa, quando um usuário realiza uma pesquisa.

A classe Search está localizada em modules / Home / e é efetivamente o controlador que lida com a solicitação do navegador.

The post Quadro de pesquisa first appeared on Documentação.

Servidor
O servidor no qual o SuiteCRM é executado é, obviamente, muito importante quando se trata do tipo de desempenho que você pode esperar. Um guia completo sobre configuração de servidor está fora do escopo deste livro. No entanto, existem algumas coisas que você pode fazer para garantir o melhor desempenho do SuiteCRM.

PHP
A instalação de um cache opcode PHP aumentará o desempenho de todos os arquivos PHP. Eles funcionam armazenando em cache a compilação de arquivos PHP, resultando em menos trabalho em cada solicitação. Além disso, o SuiteCRM usará a API de cache de alguns aceleradores de PHP, o que aumentará ainda mais o desempenho. Se você estiver usando Linux, APC é a escolha usual. Os usuários do Windows devem verificar o WinCache.

MySQL
O MySQL é conhecido por ter pequenas configurações padrão. A otimização total do MySQL está fora do escopo deste livro (entretanto, verifique mysqltuner.pl para um script Perl útil que fornecerá recomendações de configuração – observe que você deve ter cuidado ao executar arquivos de uma fonte desconhecida). Uma pequena mudança que pode fazer uma grande diferença é aumentar o innodb_buffer_pool_size.

Se você migrou ou importou uma quantidade significativa de dados, é possível que algumas tabelas fiquem fragmentadas. Executar OPTIMIZE TABLE tablename pode aumentar o desempenho.

Índices
Adicionar índices nos campos dos módulos pode melhorar o desempenho do banco de dados. Os módulos principais geralmente possuem campos importantes indexados. No entanto, se você criou um novo módulo ou adicionou novos campos frequentemente pesquisados ​​a um módulo, esses campos podem se beneficiar com a indexação. Veja o capítulo Vardef para adicionar índices.

Mudanças de configuração
A seguir estão algumas configurações que podem ser usadas para melhorar o desempenho. Observe que, na maioria dos casos, você obterá melhores ganhos de desempenho seguindo primeiro as etapas das seções anteriores. Essas configurações devem ser definidas no arquivo config_override.php. Consulte o capítulo sobre os arquivos de configuração para obter mais informações.

$sugar_config[‘developerMode’] = false;
A menos que você esteja desenvolvendo ativamente em uma instância, o developerMode deve estar desligado. Caso contrário, cada solicitação de página fará com que os arquivos em cache sejam recarregados.

$sugar_config[‘disable_count_query’] = true;
Para sistemas com grandes quantidades de dados, as consultas de contagem nos subpainéis usados ​​para os controles de paginação podem se tornar lentas, fazendo com que a página seja lenta ou completamente lenta para carregar. Desativar essas consultas pode melhorar drasticamente o desempenho em algumas páginas.

$sugar_config[‘disable_vcr’] = true;
Por padrão, abrir a exibição de detalhes de um registro na exibição de lista também carregará os outros registros na lista para permitir uma movimentação fácil pelos registros. Se você não usar este recurso ou se o carregamento da visualização de detalhes para alguns registros estiver lento, você pode desativar este recurso.

$sugar_config[‘list_max_entries_per_page’] = ’10’;
O número de registros mostrado em cada página da exibição de lista pode ser diminuído. Isso resultará em um ligeiro aumento no desempenho nas páginas de exibição de lista.

$sugar_config[‘logger’][‘level’] = ‘fatal’;
Reduzir o nível de log significa que haverá menos mensagens de log para gravar no disco em cada solicitação. Isso aumentará ligeiramente (muito ligeiramente) o desempenho.

The post Ajuste de desempenho first appeared on Documentação.

Controle de versão
Ao desenvolver personalizações, é prudente usar alguma forma de controle de versão. O controle de versão permite rastrear alterações em sua base de código, além de reverter as alterações. Existem muitos sistemas de controle de versão disponíveis. SuiteCRM usa Git, embora eu também goste de Mercurial.

Se você estiver usando uma instância de desenvolvimento (como mencionado acima), o Controle de Versão geralmente permite que você envie alterações para outras versões ou para liberar tags. Isso fornece uma maneira de enviar alterações para instâncias ativas ou de teste com segurança. Crucialmente, também significa que, caso haja problemas graves com uma versão, isso pode ser facilmente revertido.

Cópia de segurança
SuiteCRM foi desenvolvido para ser personalizável. No entanto, erros, bugs e outras coisas desagradáveis ​​podem (e graças à lei de Murphy, vão) acontecer. Antes de fazer qualquer alteração, você deve sempre se certificar de que possui um backup de todos os arquivos e do banco de dados.

Para fazer backup dos arquivos, você pode simplesmente criar um arquivo zip do diretório SuiteCRM e copiá-lo para um local seguro. Em sistemas Linux, isso pode ser realizado usando o seguinte:
Exemplo 17.1: backup de arquivo
tar -czvf suitecrmfilebackup.tar.gz /path/to/suitecrm

O backup do banco de dados SuiteCRM irá variar dependendo de qual banco de dados você está usando. No entanto, os backups do MySQL podem ser executados usando o comando mysqldump no Linux, como visto aqui:
Exemplo 17.2: backup do banco de dados MySQL
mysqldump suitecrmdatabase -u databaseuser -p | gzip -c | cat> suitecrm.sql.gz

Seja um upgrade seguro
A menos que você esteja fazendo alterações em um módulo personalizado, você deve se esforçar em todos os casos para usar a estrutura personalizada e fazer alterações na pasta personalizada. Isso garante que, caso você cometa um erro, retificá-lo seja tão simples quanto remover a personalização.

No entanto, a principal vantagem de usar o personalizado é que, quando você atualizar o SuiteCRM no futuro, você não terá suas alterações sobrescritas pelos arquivos do SuiteCRM atualizados. Consulte o capítulo Extensões para obter mais informações.

Use níveis de registro apropriados
O uso de níveis de registro apropriados (consulte o capítulo sobre Registro) torna mais fácil rastrear problemas. Você não quer que mensagens muito importantes sejam registradas como depuração, pois isso dificultará sua localização. Da mesma forma, você não quer mensagens de registro sem importância bagunçando a saída do registro fatal.

Ganchos lógicos de longa duração
Se uma tarefa de gancho lógico é de longa execução, você deve colocá-la na fila de trabalhos (consulte os capítulos Ganchos Lógicos e Tarefas Agendadas).

Minimize SQL
Sempre que possível, você deve se esforçar para usar os métodos fornecidos pelo SuiteCRM para acessar dados. Isso inclui o uso de beans e da BeanFactory onde possível (consulte o capítulo Trabalhando com beans). Existem algumas razões para isso. A primeira é que o SQL geralmente é codificado ou deve ser construído dinamicamente. No caso em que o SQL está codificado, isso significa que as alterações nos campos não serão refletidas, tornando o código mais frágil.

O SQL dinâmico é melhor porque pode reagir às mudanças de campo e geralmente ser adaptado para se ajustar à situação. No entanto, isso requer a adição de código extra, muitas vezes complexo. Pode ser difícil explicar todas as situações (isso pode ser especialmente problemático ao tentar atravessar relacionamentos dinamicamente).

Outro problema é que, normalmente, o SQL acabará sendo específico do Banco de Dados (consulte o próximo ponto para atenuar isso, no entanto).

Finalmente, qualquer lógica customizada (como Logic Hooks) que normalmente seria disparada para salvar beans ou relacionamentos não será disparada para consultas SQL.

Uso de SQL
Em alguns casos, o uso de SQL bruto é inevitável. Se for esse o caso, você deve se esforçar para usar o SQL compatível com o padrão. Se recursos específicos do mecanismo de banco de dados precisam ser usados ​​e você deseja direcionar outros mecanismos de banco de dados, pode verificar o tipo de banco de dados. Por exemplo:
Exemplo 17.1: Verificando o mecanismo de banco de dados

function getSomeSQLQuery(){
      global $sugar_config;
      switch($sugar_config['dbconfig']['db_type']){
          case 'mssql':
              $sql = 'MSSQL specific SQL';
              break;
          case 'mysql':
          default:
              $sql = 'MySQL specific SQL';
              break;
      }
      return $sql;
 }

Verificação de entrada
A maioria dos arquivos SuiteCRM começará com alguma variação da seguinte linha:

Exemplo 17.2: Verificação de entrada
if (! defined (‘sugarEntry’) ||! sugarEntry) die (‘Não é um ponto de entrada válido’);

Isso evita o acesso direto ao arquivo garantindo que o SuiteCRM foi carregado por meio de um ponto de entrada válido (ou seja, foi carregado por meio de index.php, cron.php ou um ponto de entrada personalizado).

Redirecionar após a postagem
Às vezes, você pode ter ações de controlador personalizadas (consulte a seção de controladores) ou pontos de entrada personalizados (consulte o capítulo Pontos de entrada). Essas ações e pontos de entrada ou outras páginas geralmente são acessados ​​usando POST. Após uma solicitação POST, é uma prática recomendada da web redirecionar para uma página diferente, especialmente se sua página fizer alterações. Isso evita que o usuário atualize a página e cause uma ação duplicada. No SuiteCRM, é melhor usar o método SugarApplication :: redirect para redirecionar. Isso simplesmente aceita um URL. Do seguinte modo:
Exemplo 17.3: Redirecionando dentro do SuiteCRM
SugarApplication :: redirect (‘index.php? Module = ‘);

The post Melhores Práticas first appeared on Documentação.