Buscar
  • Blog Lampada

Construindo Visões Segmentadas do um Módulo no SugarCRM

É comum para as empresas utilizar o campo “Tipo de Conta” no módulo Contas para segmentar e estruturar seus cadastros e, eventualmente, até implementar Dependências como SetPanelVisibility, SetOptions, SetRequired etc a fim de automatizar e flexibilizar ações no cadastro.


Empresas mais engajadas em desenvolvimento no SugarCRM tendem a explorar os benefícios de Filters para restringir qual segmentação de Contas será listada em um determinado campo de Relacionamento, e tal prática agrega muito valor ao negócio!


Mas com todo esse bônus vem também um ônus:

Quando há a necessidade de criar uma Atividade (Ligação, Reunião, Tarefa, Nota) através do próprio módulo ou da respectiva opção no menu “Criação Rápida” e no formulário de criação selecionar uma determinada Conta no campo “Referente a”!

Como selecionar uma Conta com segmentação específica (Tipo de Conta) com o mínimo de cliques, ou seja, sem aplicar filtros na listagem exibida ao clicar em “Pesquisar e selecionar…”?


Pois é! Não é possível, não sem invocar um dos recursos mais poderosos e, surpreendentemente, mais subestimados do SugarCRM: Visibility Framework.


Visibility Framework é um “canivete suíço” no SugarCRM, permitindo modular de maneira estática ou dinâmica políticas de acesso a módulos com base em uma gama de parâmetros, tão vasta que seu detalhamento merece uma postagem exclusiva e extensa!


Como um exemplo de sua aplicação consideramos o módulo Contas, em inglês “Accounts”, segmentado entre “Partner”, “Customer” e “Location”. Tal implementação se faz ainda mais crucial se Partners, Customers e/ou Locations eventualmente compartilham o mesmo nome.


Etapa 1: Criação dos pseudomódulos “Partners”, “Customers” e “Locations”

Estes módulos são tão “pseudo” que quase não tem conteúdo, possuem apenas o Bean, vardefs, language e filter default.



O Bean é tão enxuto que nem parece funcionar:



O vardefs é ainda mais simples, mapeando apenas os campos que serão pesquisados junto ao próprio campo “Nome” da Conta:



O “pulo do gato” é o atributo “visibility” o qual define a classe de visibilidade personalizada que deverá ser invocada a fim de filtrar os registros deste módulo de acordo. Se não especificado tal atributo será invocada a super classe SugarVisibility. No caso estamos definindo a classe de visibilidade “FilterPartners”. Falaremos dela mais adiante.


O language é inexplicavelmente simples:



Por fim e não menos importante o filter default, o qual define apenas os campos a serem pesquisados no pseudo módulo, juntamente com o campo “Nome” da Conta:



Quanto à classe FilterPartners temos a seguinte estrutura:


FilterPartners → FilterAccounts → FilterPseudoModules → SugarVisibility

Ou seja, FilterPartners estende FilterAccounts que estende FilterPseudoModules que estende a superclasse SugarVisibility.


Esta “complexidade” favorece a aplicação da mesma estratégia para outros módulos os quais, da mesma forma, utilizam de segmentações.


Estas classes são salvas no diretório custom/data/visibility e seus conteúdos são descritos abaixo:


FilterPartners



FilterAccounts



FilterPseudoModules



A classe FilterPseudoModules é uma classe “coringa”, ou seja, implementa uma lógica sem definição estática de campo ou valor a serem injetados na query SQL compilada pelo SugarQuery.


A classe FilterAccounts define “account_type” como campo a ser filtrado pela SugarQuery.

A classe FilterPartners define “Partner” como valor do campo previamente definido na FilterAccounts.


Desta forma temos uma implementação elegante, reutilizável e escalonável.


A “cereja do bolo” é a construção de um tipo estendido de campo parent para desabilitar condicionalmente a opção “Pesquisar e selecionar…” caso seja selecionado um pseudomódulo:



A instalação do módulo é realizada através do seguinte Include:



A definição dos rótulos da aplicação são os seguintes:




Realizada esta customização será possível pesquisar por qualquer um destes pseudomódulos de modo a filtrar automaticamente pela sua correspondente segmentação, facilitando em muito a vida dos usuários! Pode-se pesquisar pelos campos “Name” e “GP Parent Card ID” do módulo Accounts, sendo que o segundo é um campo customizado.


Contribuiu neste post como Autor:


André Lopes @andopes



13 visualizações0 comentário

Posts recentes

Ver tudo

O foco no cliente 

é o principal elemento de todas

as atividades de negócio

Vamos conversar

Rua Sergipe, 475 - Higienópolis, São Paulo - SP

55 11 99269 2520 • CEP 01243-001

São Paulo • SP • BRASIL

  • Grey Twitter Icon