Estou prestes a fazer uma mudança no organograma. Gostaria de salvar o nome do usuário no banco de dados, pra poder deletar usuários do ldap. Pelo que vocês conhecem do workflow, ldap, postgres, isso vale a pena ser feito? Existe algum outro modo de administrar isso?

Sobre o nome das pessoas no organograma, estamos passando pelo mesmo problema. Precisamos manter o nome das pessoas para efeito de histórico no organograma, mas o pessoal do ldap necessita excluir completamente as contas, para aumentar a segurança (evitando, por exemplo, que uma pessoa demissionária continue a ter acesso a áreas da rede). Já pensamos a respeito, e o jeito mais viável é realmente incluir o nome no orgamograma. Então, se você quiser tocar esta manutenção, ela será bem útil para o workflow. Você aceita? Quando estiver pronta, você nos manda os patches que a gente aplica no Cvs.

Enquanto eu respondia ao seu tópico, surgiu uma nova idéia a respeito, que foi colocada pelo Drovetto, que é uma das pessoas envolvidas com o desenvolvimento do workflow, Transcrevo a seguir o email que ele me mandou:

"...sobre essa alteração para incluir nome, na minha opinião, não deveria ser vinculada ao organograma. Já que nem todos os usuários estão cadastrados no Organograma (sefa e casa civil, por exemplo). Acredito que esta deva ser uma solução que contemple todos os usuários. Na minha opinião deveríamos utilizar um esquema de cache, salvando em uma tabela temporária." (por Sídnei Drovetto)

Bom, aceito fazer essa alteração, mas antes eu deveria entender a idéia de Sidnei...
Não entendi muito bem a idéia de Sidnei, mas vou dar minha opinião com base no que eu entendi.

Creio que da forma como está hoje a estrutura do banco de dados do organograma mais a estrutura do ldap de vocês (sem setores, certo?), o nome do usuário deve ser incluído na tabela do organograma e inserido assim que o administrador do workflow cadastra o funcionário no organograma.

Se não existissem as tabelas centro de custo, área, status do funcionário, status da área e etc, ou se esses dados estivessem no ldap, aí sim, no meu entender, poderíamos fazer um esquema de cache de forma que o usuário seria cadastrado sob demanda, ou seja, se ele participou de uma atividade em algum processo, esse usuário poderia ser cadastrado no organograma automaticamente caso ainda não tenha sido cadastrado. Seria eficiente porque só estariam cadastrados aqueles usuários que são ativos no workflow.

Criar uma outra tabela temporária com nomes de funcionários seria redundante, pois já existe uma tabela de funcionários pra isso. Sem contar que em termos de desempenho não seria tão interessante, pois nem todos os funcionários usam esse módulo.

um abraço,
Allan

Ainda não conversei com o Sídnei mais a fundo para explicitar os detalhes da idéia dele, mas vou colocar mais algumas informações para sua análise:

- Quando a gente começou a pensar no organograma, a primeira idéia que veio foi registrar as áreas, status de áreas, centro de custos, localidades, tudo no ldap. Daí fomos conversar com o pessoal mantenedor da árvore e eles alertaram que isto poderia gerar muita escrita no ldap e também quando uma pessoa trocasse de área, teríamos que mudá-la de ramo, implicando em mudança do dn. Em resumo, ficou difícil implementar no ldap. Por isso, resolvemos então, fazer tudo em banco de dados, exceto os dados básicos dos funcionários, como o nome, telefone, matrícula, etc.

- A idéia do Sídnei, a meu ver, tenta resolver o problema do nome para os usuários que não estão no organograma, mas participam de processos. Talvez não seja o seu caso, mas aqui na Celepar temos um processo que envolve outra organização (Secretaria da Fazenda), e esta não tem organograma registrado. Caso um funcionário da Sefa seja excluído precisamos manter o nome dele em algum lugar, para uso nas instâncias, que este usuário excluído participou.

Vamos tentar chegar a uma solução que atenda a todo mundo.

Um abraço.

Olá a todos,
Bem.. a minha idéia é a seguinte:
Ter uma cópia, como um cache, dos dados do ldap em uma tabela no banco de dados.
Fazer alterações na classe wf_ldap para que também faça consultas a esta tabela e não somente ao ldap.

As consultas à wf_ldap seriam feitas da seguinte maneira:
1- Desenvolvedor solicita à wf_ldap informações sobre o usuário XXXX;
2 - A busca é realizada em banco e, neste caso temos dois caminhos distintos
2.1 - O registro não é encontrado
2.1.1 - A busca é realizada no LDAP e os dados são armazenados na tabela de cache, associados ao timestamp atual
2.2 - O registro é encontrado:
2.2.1 - Verifica-se se o timestamp é muito antigo (por exemplo, mais de 10 dias)
2.2.1.1 - Caso seja muito antigo, faz-se uma busca no LDAP para atualizar os dados e, atribui-se um novo timestamp (data atual). Caso os dados não mais estejam disponíveis no LDAP, marca-se o registro como indisponível no LDAP e, nunca mais este registro será buscado no LDAP (inclusive para atualizações)
2.2.1.2 - Caso não seja muito antigo, retorna os dados do banco

Este esquema seria utilizado tanto por processos quanto pelo módulo em si. O interessante deste esquema é que não fica restrito Organograma, contemplando todos os usuários do módulo.
Esta seria, basicamente, a idéia da tabela de cache.
Esta é uma pendência antiga nossa, e é a próxima a ser resolvida.
Allan, caso você não tenha iniciado alguma implementação para resolver este problema e puder aguardar alguns dias, logo ela estará disponível para toda a comunidade através do nosso CVS Externo.

Um abraço,
Sídnei A. Drovetto Jr.