Problemas ao acessar catálogo externo no Catálogo de Endereços

[diorgenes]

Boa dia Senhores,

recentemente atualizei meu Expresso pelo SVN, baixei a revisão 658 e percebi os seguinte problemas em relação ao Catálogo de Endereços.

Estou utilizando o recurso de Catálogo Externo para acessar três catálogos externos, antes da atualização este recurso funcionava normalmente, porém, com a opção quicksearch desabilitada (devido ao bug, pois quando um dos catálogos externos estivesse fora do ar e um usuário fizesse uma busca pelo ExpressoMail com a tecla F9, o recurso entrava em um loop sem retornar um timeout, acabava travando o navegador do usuário).

Então, após a atualização, os três catálogos externos continuam acessíveis pelo ExpressoMail, mas no Catálogo de Endereço ao clicar em um deles a consulta não é realizada e a seguinte mensagem é retornada: Couldn't get the Catalogue Tree. Please contact the Administrator.*

Grato

Att.
Diorgenes Felipe Grzesiuk
Analista de Sistemas e Suporte
Prognus Software Livre
(45) 3576-7067

[diorgenes]

meu arquivo de configuração dos catalogos externos

[eduardoalex]

Esse erro é grave para nós visto que essa funcionalidade é fundamental dentro da nossa arquitetura. Mudei para o Milestone 2.0 e alterei a prioridade. O ticket já estaá atribuído a Diógenes.

[niltonneto]

Replying to eduardoalex:

Esse erro é grave para nós visto que essa funcionalidade é fundamental dentro da nossa arquitetura. Mudei para o Milestone 2.0 e alterei a prioridade. O ticket já estaá atribuído a Diógenes.

E aí, alguma previsão para o fechamento desse ticket?

[diogenesduarte]

Acredito que vai ser fechado hoje ou amanhã, mas primeiro temos que discutir umas coisinhas.
Bem, o problema surgiu após a revisão 383. Foram adicionadas 2 linhas nessa revisão(uma em bo_global_ldap_catalog e outra em bo_ldap_manager) com conteúdo muito parecido. Essas linhas, alteram a variável que contém o contexto do ldap à ser conectado, tirando tudo que tem DC=... e colocando o dn vindo duma outra variável. Apesar de não entender muito bem o intuito do que foi feito, acredito que isso não deve ser feito para catálogos externos ao expresso, por isso, no arquivo bo_ldap_manager eu coloquei para não passar por essa linha caso o catálogo seja externo.
Isso resolve o problema do ticket, mas isso não basta. A linha no arquivo bo_global_ldap_catalog faz com que as informações venham em branco ao listar as pessoas de uma OU. Comentei a linha e continuou vindo em branco, mas parece que agora decorrente de um erro que eu estou depurando. De qualquer forma, alguém saberia dizer o motivo da revisão 383? na descrição fala algo referente a referals, mas não tem ticket atribulado a ela.

[niltonneto]

Replying to diogenesduarte:

Acredito que vai ser fechado hoje ou amanhã, mas primeiro temos que discutir umas coisinhas.
Bem, o problema surgiu após a revisão 383. Foram adicionadas 2 linhas nessa revisão(uma em bo_global_ldap_catalog e outra em bo_ldap_manager) com conteúdo muito parecido. Essas linhas, alteram a variável que contém o contexto do ldap à ser conectado, tirando tudo que tem DC=... e colocando o dn vindo duma outra variável. Apesar de não entender muito bem o intuito do que foi feito, acredito que isso não deve ser feito para catálogos externos ao expresso, por isso, no arquivo bo_ldap_manager eu coloquei para não passar por essa linha caso o catálogo seja externo.
Isso resolve o problema do ticket, mas isso não basta. A linha no arquivo bo_global_ldap_catalog faz com que as informações venham em branco ao listar as pessoas de uma OU. Comentei a linha e continuou vindo em branco, mas parece que agora decorrente de um erro que eu estou depurando. De qualquer forma, alguém saberia dizer o motivo da revisão 383? na descrição fala algo referente a referals, mas não tem ticket atribulado a ela.

Diogenes, essa alteração foi necessária devido à estrutura de referrals LDAP aqui da Celepar. Existem referrals no LDAP principal que apontam diretamente para um DC de outros LDAPs. Sem essa alteração, eles não aparecem na árvore do catálogo geral. Portanto é essencial que continue assim. Ah, essa revisão não referencia nenhum ticket por se tratar de um commit antigo, da época em que não tínhamos ainda um padrão para o trabalho de colaboração.
Só tome cuidado para não impactar no código que não usa catálogo externo. Aguardamos o fechamento desse ticket então.

[diogenesduarte]

Replying to niltonneto:

Replying to diogenesduarte:

Acredito que vai ser fechado hoje ou amanhã, mas primeiro temos que discutir umas coisinhas.
Bem, o problema surgiu após a revisão 383. Foram adicionadas 2 linhas nessa revisão(uma em bo_global_ldap_catalog e outra em bo_ldap_manager) com conteúdo muito parecido. Essas linhas, alteram a variável que contém o contexto do ldap à ser conectado, tirando tudo que tem DC=... e colocando o dn vindo duma outra variável. Apesar de não entender muito bem o intuito do que foi feito, acredito que isso não deve ser feito para catálogos externos ao expresso, por isso, no arquivo bo_ldap_manager eu coloquei para não passar por essa linha caso o catálogo seja externo.
Isso resolve o problema do ticket, mas isso não basta. A linha no arquivo bo_global_ldap_catalog faz com que as informações venham em branco ao listar as pessoas de uma OU. Comentei a linha e continuou vindo em branco, mas parece que agora decorrente de um erro que eu estou depurando. De qualquer forma, alguém saberia dizer o motivo da revisão 383? na descrição fala algo referente a referals, mas não tem ticket atribulado a ela.

Diogenes, essa alteração foi necessária devido à estrutura de referrals LDAP aqui da Celepar. Existem referrals no LDAP principal que apontam diretamente para um DC de outros LDAPs. Sem essa alteração, eles não aparecem na árvore do catálogo geral. Portanto é essencial que continue assim. Ah, essa revisão não referencia nenhum ticket por se tratar de um commit antigo, da época em que não tínhamos ainda um padrão para o trabalho de colaboração.
Só tome cuidado para não impactar no código que não usa catálogo externo. Aguardamos o fechamento desse ticket então.

Nilton, minha preocupação é justamente essa, não impactar nos demais catálogos, só que após corrigir esse encontrei mais um, agora válido para tudo referente à ldap. Mesmo o catálogo geral na revisão atual não está funcionando. A árvore aparece certinha, mas as linhas com informações dos contatos aparecem em branco. Isso acontece devido à revisão 1411, referente ao ticket #611, mais precisamente por causa da linha abaixo:

$final[3][$i][1] = $contact['names_ordered'] ? urldecode( $contact['names_ordered'] ) : 'none';

quando o catalogo atual é do tipo ldap $contactnames_ordered? é um array, aí urldecode nele dá pau. Já estamos corrigindo isso e vamos comitar tudo de vez, assim acabamos com dois bugs de uma vez só.

[niltonneto]

Replying to diogenesduarte:

Replying to niltonneto:

Replying to diogenesduarte:

Acredito que vai ser fechado hoje ou amanhã, mas primeiro temos que discutir umas coisinhas.
Bem, o problema surgiu após a revisão 383. Foram adicionadas 2 linhas nessa revisão(uma em bo_global_ldap_catalog e outra em bo_ldap_manager) com conteúdo muito parecido. Essas linhas, alteram a variável que contém o contexto do ldap à ser conectado, tirando tudo que tem DC=... e colocando o dn vindo duma outra variável. Apesar de não entender muito bem o intuito do que foi feito, acredito que isso não deve ser feito para catálogos externos ao expresso, por isso, no arquivo bo_ldap_manager eu coloquei para não passar por essa linha caso o catálogo seja externo.
Isso resolve o problema do ticket, mas isso não basta. A linha no arquivo bo_global_ldap_catalog faz com que as informações venham em branco ao listar as pessoas de uma OU. Comentei a linha e continuou vindo em branco, mas parece que agora decorrente de um erro que eu estou depurando. De qualquer forma, alguém saberia dizer o motivo da revisão 383? na descrição fala algo referente a referals, mas não tem ticket atribulado a ela.

Diogenes, essa alteração foi necessária devido à estrutura de referrals LDAP aqui da Celepar. Existem referrals no LDAP principal que apontam diretamente para um DC de outros LDAPs. Sem essa alteração, eles não aparecem na árvore do catálogo geral. Portanto é essencial que continue assim. Ah, essa revisão não referencia nenhum ticket por se tratar de um commit antigo, da época em que não tínhamos ainda um padrão para o trabalho de colaboração.
Só tome cuidado para não impactar no código que não usa catálogo externo. Aguardamos o fechamento desse ticket então.

Nilton, minha preocupação é justamente essa, não impactar nos demais catálogos, só que após corrigir esse encontrei mais um, agora válido para tudo referente à ldap. Mesmo o catálogo geral na revisão atual não está funcionando. A árvore aparece certinha, mas as linhas com informações dos contatos aparecem em branco. Isso acontece devido à revisão 1411, referente ao ticket #611, mais precisamente por causa da linha abaixo:

$final[3][$i][1] = $contact['names_ordered'] ? urldecode( $contact['names_ordered'] ) : 'none';

quando o catalogo atual é do tipo ldap $contactnames_ordered? é um array, aí urldecode nele dá pau. Já estamos corrigindo isso e vamos comitar tudo de vez, assim acabamos com dois bugs de uma vez só.

Maravilha. Mas vocês conseguem corrigir sem impactar na correção feita nesse ticket #611, certo?

[diogenesduarte]

Replying to niltonneto:

Replying to diogenesduarte:

Replying to niltonneto:

Replying to diogenesduarte:

Acredito que vai ser fechado hoje ou amanhã, mas primeiro temos que discutir umas coisinhas.
Bem, o problema surgiu após a revisão 383. Foram adicionadas 2 linhas nessa revisão(uma em bo_global_ldap_catalog e outra em bo_ldap_manager) com conteúdo muito parecido. Essas linhas, alteram a variável que contém o contexto do ldap à ser conectado, tirando tudo que tem DC=... e colocando o dn vindo duma outra variável. Apesar de não entender muito bem o intuito do que foi feito, acredito que isso não deve ser feito para catálogos externos ao expresso, por isso, no arquivo bo_ldap_manager eu coloquei para não passar por essa linha caso o catálogo seja externo.
Isso resolve o problema do ticket, mas isso não basta. A linha no arquivo bo_global_ldap_catalog faz com que as informações venham em branco ao listar as pessoas de uma OU. Comentei a linha e continuou vindo em branco, mas parece que agora decorrente de um erro que eu estou depurando. De qualquer forma, alguém saberia dizer o motivo da revisão 383? na descrição fala algo referente a referals, mas não tem ticket atribulado a ela.

Diogenes, essa alteração foi necessária devido à estrutura de referrals LDAP aqui da Celepar. Existem referrals no LDAP principal que apontam diretamente para um DC de outros LDAPs. Sem essa alteração, eles não aparecem na árvore do catálogo geral. Portanto é essencial que continue assim. Ah, essa revisão não referencia nenhum ticket por se tratar de um commit antigo, da época em que não tínhamos ainda um padrão para o trabalho de colaboração.
Só tome cuidado para não impactar no código que não usa catálogo externo. Aguardamos o fechamento desse ticket então.

Nilton, minha preocupação é justamente essa, não impactar nos demais catálogos, só que após corrigir esse encontrei mais um, agora válido para tudo referente à ldap. Mesmo o catálogo geral na revisão atual não está funcionando. A árvore aparece certinha, mas as linhas com informações dos contatos aparecem em branco. Isso acontece devido à revisão 1411, referente ao ticket #611, mais precisamente por causa da linha abaixo:

$final[3][$i][1] = $contact['names_ordered'] ? urldecode( $contact['names_ordered'] ) : 'none';

quando o catalogo atual é do tipo ldap $contactnames_ordered? é um array, aí urldecode nele dá pau. Já estamos corrigindo isso e vamos comitar tudo de vez, assim acabamos com dois bugs de uma vez só.

Maravilha. Mas vocês conseguem corrigir sem impactar na correção feita nesse ticket #611, certo?

A intenção é essa...

[diogenesduarte]

Resolvido em [1419].

Como eu disse, aqui foram resolvidos dois problemas. O primeiro era decorrente da utilização de uma rotina implementada em [383] que gerava problemas quando executada na renderização de informações de catálogos externos. Na revisão 1419, eu pergunto se o catálogo é externo antes de executar as rotinas da revisão 383. Quanto ao outro problema, decorrente da revisão 1411, afetava todos os catálogos de ldap, como já havia dito, pois contatos de ldap vinham com a posição names_ordered como array, e dava problema ao usar urldecode nele. Pra resolver usei o urldecode apenas caso o catálogo não seja do tipo bo_global_ldap_catalog.

[niltonneto]

Replying to diogenesduarte:

Resolvido em [1419].

Como eu disse, aqui foram resolvidos dois problemas. O primeiro era decorrente da utilização de uma rotina implementada em [383] que gerava problemas quando executada na renderização de informações de catálogos externos. Na revisão 1419, eu pergunto se o catálogo é externo antes de executar as rotinas da revisão 383. Quanto ao outro problema, decorrente da revisão 1411, afetava todos os catálogos de ldap, como já havia dito, pois contatos de ldap vinham com a posição names_ordered como array, e dava problema ao usar urldecode nele. Pra resolver usei o urldecode apenas caso o catálogo não seja do tipo bo_global_ldap_catalog.

Efetuado teste para avaliar o impacto dessa alteração no funcionamento do catálogo normal. Funcionou corretamente sem problemas. Acho que podemos finalizar então, correto?