É 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

Comments