Re: [Zope-pt] Workflow c/ permissões apenas p/ alguns estados - AGX

Sun, 11 Dec 2005 06:50:32 -0800

Xirú,

Obrigado pelas explicações e gostei das sugestões. Vou tentar implementá-las.

Muito obrigado.

[ ],
--
JJ (|´:¬{)»
---------------------------------------------
"Eu sou a ressurreição e a vida. Quem crê em mim, ainda que morra, viverá; e todo o que vive e crê em mim não morrerá, eternamente. Crês isto?"
O Senhor, Jesus Cristo - Jo.11:25-26
---------------------------------------------

Em 11/12/05, xiru <[EMAIL PROTECTED]> escreveu:


On 12/11/05, JJ (Arnaldo Janz Júnior) < [EMAIL PROTECTED]> wrote:
Olá, pessoALL! (|':¬{D>

Estou desenvolvendo um cadastro de usuários via AGX em um site que estou trabalhando. É minha primeira experiência c/ AGX (e não muito mais do que isso c/ AT). Tenho quase tudo já modelado exceto uma parte, que, sinceramente, ArchGenXML - Getting started (em plone.org), apesar de muito bom e útil em muitas outras coisas, não me deu idéia de como fazer.
Se puder contar c/ a ajuda de vcs (q seja c/ referências onde possa aprender o que preciso e/ ou trocar uma idéia - mesmo q em PVT, quem quiser - ), agradeço muito.
A idéia é essa:
1- Member (derivado de CMFMember) possui um campo (['SIM','NÃO']) onde responde se quer ser voluntário do site. APENAS se responder SIM, ele pode preencher seu currículo, que implementei pela agregação de uma classe Curriculo (+ schemata) ao member (mas essa implementação pode mudar de acordo c/ a sugestão). Como representar essa possibilidade (ou não) de prencher seu currículo, dependendo do valor do campo?


Bem... eu modelaria assim.

Criaria uma classe para o Member, com o esteriotipo member e com o campo adicional curriculo que seria uma referencia para um objeto curriculo. Se a referencia nao aponta para nenhum objeto curriculo, esse member nao tem curriculo. Como voce vai fazer isso na UI nao depende muito do modelo, mas acho que se voce implementar como eu disse e colocar a opcao de add no reference field, fica aceitavel.


2- Após preencher esse currículo (e toda vez que modificá-lo), um e-mail deve ser enviado ao gestor, p/ que lhe atribua funções, que implementei por referências a uma classe Função (e isso tb pode variar à sugestão). Também não consegui imaginar como representar isso.


Mandar email é coisa que gosto de fazer em transicoes de workflow. O que voce poderia fazer é criar uma transicao automatica que verifica se o conteudo do objeto mudou e colocar nessa transicao o envio do email.
 
3- APENAS após a atribuição dessa função, um e-mail deve ser enviado ao voluntário p/ que continue seu cadastro (dados profissionais, dados pessoais, ..., tb classes + schematas).


Mesmo esquema aqui. Definir o fluxo do workflow e colocar scripts nas transicoes.
 

Acredito que a solução p/ os 2 primeiros deve resolver isso aqui.
Tinha pensado em representar todas as agregações e relacionamentos/referências no diagrama de classes e dar as permissões de adicionar o determinado tipo p/ os estados de workflow.


Nao é má ideia, mas seria legal proteger o field (write_permission) com uma permissao tambem (alem da permissao de add do objeto).
 

Assim:
Tinha pensado em resolver a 1ª como se o Member fosse criado num estado inicial de workflow (novo, criado, sei lá) e só fizesse a transição p/ um próximo (CandidatoAVoluntario ou coisa parecida) se preenchesse SIM. Esse estado teria de ser mudado via script, que o faria de acordo c/ a resposta. Apenas esse estado, CandidatoAVoluntario, teria permissão p/ criar Curriculo.


Nao gosto muito da modelagem, mas parece que atenderia sua necessidade.
 

Contudo, tb ainda não sei como fazer uma transição de workflow quando um objeto é salvo (ou como disparar um script que o faça quando o objeto é salvo). Alguém pode ajudar?

Tens que criar uma transicao com trigger automatico (zero se nao me engano é automatico, tem que olhar umas constantes no DCWorkflow). Ai, basta voce definir um script que consiga detectar o comportamento que voce quer que seja o causador da transicao e coloca-lo num script que é invocado na expressao da transicao. Disparar um script quando um objeto é salvo nao é uma implementacao perfeita (apesar de funcionar) pq o objeto pode ser salvo vazio ou com os mesmo dados que estavam antes de ele ser editado. Se fosse fazer assim, seria apenas meter um hook (sobreescrever) o metodo manage_afterAdd ou asemelhados, por exemplo.

A 2ª pensei que, semelhante ao acima, assim que ele preencher o currículo, esse último estaria num estado inicial de workflow (tipo, Preenchido) onde, após transição, execute um script que envie o e-mail p/ o gestor. Apenas o gestor (que é um role) teria permissão p/ fazer a referência.

OK 

A 3ª pensei que, após fazer a(s) referência(s) do Member p/ a(s) Função(ões), faria uma transição no workflow do Member, de CandidatoAVoluntario p/ Voluntario, por exemplo, e, após ela, executaria um script p/ enviar o e-mail p/ o Voluntário. Apenas esse estado, Voluntário, teria permissão p/ criar Dados Pessoais, Dados Profissionais, ...

De fato, permissoes é a forma mais adequada de controlar essas coisas.

Bom, além de tudo, a idéia tá boa? É por aí? Ou tem jeito mais simples? É minha primeira experiência c/ AGX e as sugestões são muito bem vindas.

Desculpem pela mensagem tão grande ...

Muito obrigado, de antemão.

[ ],
--
JJ (|´:¬{)»
---------------------------------------------
"Eu sou a ressurreição e a vida. Quem crê em mim, ainda que morra, viverá; e todo o que vive e crê em mim não morrerá, eternamente. Crês isto?"
O Senhor, Jesus Cristo - Jo.11:25-26
---------------------------------------------

Para enviar uma mensagem: zope-pt@yahoogrupos.com.br
Para desistir envie uma mensagem em branco para: [EMAIL PROTECTED]


Yahoo! Grupos, um serviço oferecido por:
PUBLICIDADE

Links do Yahoo! Grupos



--
Fabiano Weimar dos Santos
Plone Developer and Consultant


Para enviar uma mensagem: zope-pt@yahoogrupos.com.br
Para desistir envie uma mensagem em branco para: [EMAIL PROTECTED]


Links do Yahoo! Grupos

Responder a