${portal_url} e ${navigation_root_url} não são transformados após atualização do IDG 1.5.1 e o path interno do Plone site fica exposto se usar virtualhost

[idgserpro]

No IDG 1.0.5, tínhamos Plone 4.3.3 e plone.app.contenttypes 1.0:

@indexer(ILink)
def getRemoteUrl(obj):
    return obj.remoteUrl

Metadata no portal_catalog: getRemoteUrl = ${portal_url}/acesso-a-informacao/institucional

No IDG 1.5.1, temos Plone 4.3.15 e plone.app.contenttypes 1.1.5:

@indexer(ILink)
def getRemoteUrl(obj):
    return replace_link_variables_by_paths(obj, obj.remoteUrl)

Metadata no portal_catalog: getRemoteUrl = /consea/acesso-a-informacao/institucional

A viewlet 'servicos' do 'brasil.gov.portal' utiliza o método 'getURL' para preencher o href dos links. No Plone 4.3.3, utilizado no IDG 1.0.5, o 'getURL' retorna a url do objeto link, não considerando o valor de 'getRemoteUrl'. Ao clicar no item do menu de serviços, o usuário é direcionado ao objeto link que por sua vez tem como visão padrão 'link_redirect_view'. Uma vez acessando a 'link_redirect_view', caso o usuário não tenha permissão de editar o objeto link, é redirecionado automaticamente para o caminho indicado no campo 'remote_url', fazendo previamente o tratamento das variáveis ${portal_url} e ${navigation_root_url}.

Já no Plone 4.3.15, utilizado pelo IDG 1.5.1, o mesmo método 'getURL', passou a utilizar o valor armazenado em 'getRemoteUrl', quando o objeto é do tipo Link.

O método 'getURL' do portal_catalog não faz nenhum tratamento das variáveis ${portal_url} e ${navigation_root_url}. Acredito que faz isso pois espera que valor tivesse sido tratado antes de ser armarzenado no metadado 'getRemoteUrl'. O problema é que o 'getRemoteUrl' dos links criados ainda na versão 1.0 do plone.app.contenttypes continuam com ${portal_url} ou ${navigation_root_url}.

A solução para esse problema é reindexar os objetos do tipo 'Link'. Assim o metadado 'getRemoteUrl' seria atualizado conforme exemplo: de ${portal_url}/acesso-a-informacao/institucional para /consea/acesso-a-informacao/institucional. É necessário um upgradeStep que faça isso.

Caso você já tenha um site em produção com esse problema, pode rodar o update catalog (cuidado com essa ação se você tem muitos objetos no portal) ou criar um script na ZMI para reindexar apenas os objetos do tipo Link.

[hvelarde]

isso não deveria ser corrigido upstream também?

[idgserpro]

Não podemos corrigir isso upstream (namespace plone), e como é branch 1.1.x, não sei se vão chegar a atuar (chegamos a abrir https://github.com/plone/plone.app.contenttypes/issues/426 e https://github.com/plone/plone.app.contenttypes/issues/424 mas também está parado).

Colocamos aqui também porque existe o formato paliativo, assim mais gente que tiver esse problema pode resolver também em produção.

De qualquer forma, abrimos o relato em https://github.com/plone/plone.app.contenttypes/issues/468, inclusive como documentação do patch se ele for removido.

[hvelarde]

acho simples fazer o upgrade step; tem esse código aqui como referência:

https://github.com/collective/collective.nitf/blob/master/src/collective/nitf/upgrades/v2002/__init__.py

o ftw.upgrade tem também uns helpers que podem ajudar:

https://github.com/4teamwork/ftw.upgrade#upgrade-step-helpers

[idgserpro]

Análise realizada:

As variáveis ${portal_url} e ${navigation_root_url} são substituidas pelo path do Plone Site através do index geRemoteUrl presente em plone.app.contenttypes.indexers.py : def getRemoteUrl : 128, ao armazenar o valor de remote_url como metadado no portal_catalog. Ex: ${portal_url}/noticias/ultimas-noticias > /Plone/noticias/ultimas-noticias

Problema: O path do Plone Site fica presente na url dos links internos que utilizam as variáveis ${portal_url} ou ${navigation_root_url} quando o template utiliza o valor de getRemoteUrl capturado via portal_catalog (metadata). Apesar da navegação continuar funcionando, o ideal seria que o path do Plone Site não ficasse exposto quando utilizamos um domínio (URL / virtual host).

Tratamento: Ao realizar uma pesquisa por links no portal_catalog o valor retornado pelo getRemoteUrl precisa ser tratado para que os links internos tenham o path do Plone Site substituído pela URL do site conforme é feito em: plone.app.contenttypes.browser.link_redirect_view.py : def absolute_target_url : 59

---

IDG 1.5.2 - Plone 4.3.17 - plone.app.contenttypes 1.1.5

IDG 1.5.3 - Plone 4.3.18 - plone.app.contenttypes 1.1.6

---

Trechos que utilizam o metadado getRemoteUrl sem a transformação do path do Plone Site por sua URL:

- Portlet Navegação - brasil.gov.portal.browser.portlets.templates.navigation_recurse.pt (customização de plone.app.portlets.portlets.navigation_recurse.pt)

- Mapa do site - Products.CMFPlone.browser.templates.sitemap-item.pt

Ambos capturam o valor de getRemoteUrl em: Products.CMFPlone.browser.navtree.py : def decoratorFactory : 191

Necessário criação de patch na função decoratorFactory para tratamento da url conforme realizado em link_redirect_view.

- Menu de Serviços - brasil.gov.portal.browser.viewlets.templates.servicos.pt:21

Necessário alterar a viewlet servicos para tratamento da url conforme realizado em link_redirect_view ou utilizar o método getURL conforme já é feito na própria viewlet na linha 14 para links com o campo Descrição preenchido.

Obs.: O preenchimento da descrição dos links de serviço no Portal Consea poderia ser utilizado como solução temporária. O link seria o resultado do método getURL e não do getRemoteUrl. O link_redirect_view fica responsável pelo redirecionamento.

Trechos que utilizam o getRemoteUrl sem o tratamento das variáveis ${portal_url} e ${navigation_root_url}:

- Banner Tile - brasil.gov.tiles.tiles.banner.py : def getRemoteUrl : 101

Necessário alterar as funções para tratamento da url conforme realizado em link_redirect_view.

---

Nova branch criada para implementação de manutenção evolutiva: https://github.com/plonegovbr/brasil.gov.portal/tree/issue_463

[idgserpro]

Corrigido em brasil.gov.portal 1.5.5. (Demanda 1677380) Realizado merge do pull request https://github.com/plonegovbr/brasil.gov.portal/pull/567 para a branch 1.x. Branch issue_463 excluída.