Re: [Zope-pt] Workflow c/ permissões apenas p/ alguns estados - AGX
Ôps! ...
Foi malz ... Bom, não tinha testado nada, só fui olhar o taggedvaluessupport.py e não tinha pensado nisso ...
Ôw! ... Muito melhor! ...
Valewz, Jean!
[ ]ã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
-Em 14/12/05, Jean Rodrigo Ferri <[EMAIL PROTECTED]
> escreveu:
JJ (Arnaldo Janz Júnior) wrote:
> E aí, Dorneles?
>
> É ... Parece q no AGX (1.4.0-final) não vai rolar (pelo menos, no
> TaggedValuesSupport não tem) (|':¬{(»
> Mas, se for o caso, vai na mão, mesmo! ...
>
> Muito obrigado pelas dicas e pelas fontes! ...
Funciona sim rapá, já tentou o tv 'widget:addable = python:1'? Se a
propriedade não está registrada no ArchGenXML ele deixa passar o que
você inseriu.
Tempos atrás eu postei aqui um modelo simples[1] de associação no
ArchGenXML pois uma pessoa estava com dúvidas, e implementa o addable
também.
[1] http://www.tchezope.org/Members/jean/arquivos/ExemploAssociacao.tgz/view
--
Jean Ferri
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
Para visitar o site do seu grupo na web, acesse:http://br.groups.yahoo.com/group/zope-pt/
Para sair deste grupo, envie um e-mail para:[EMAIL PROTECTED]
O uso que você faz do Yahoo! Grupos está sujeito aos Termos do Serviço do Yahoo!.
Re: [Zope-pt] Workflow c/ permissões apenas p/ alguns estados - AGX
JJ (Arnaldo Janz Júnior) wrote:
> E aí, Dorneles?
>
> É ... Parece q no AGX (1.4.0-final) não vai rolar (pelo menos, no
> TaggedValuesSupport não tem) (|':¬{(»
> Mas, se for o caso, vai na mão, mesmo! ...
>
> Muito obrigado pelas dicas e pelas fontes! ...
Funciona sim rapá, já tentou o tv 'widget:addable = python:1'? Se a
propriedade não está registrada no ArchGenXML ele deixa passar o que
você inseriu.
Tempos atrás eu postei aqui um modelo simples[1] de associação no
ArchGenXML pois uma pessoa estava com dúvidas, e implementa o addable
também.
[1] http://www.tchezope.org/Members/jean/arquivos/ExemploAssociacao.tgz/view
--
Jean Ferri
Para enviar uma mensagem: zope-pt@yahoogrupos.com.br
Para desistir envie uma mensagem em branco para: [EMAIL PROTECTED]
Links do Yahoo! Grupos
<*> Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/zope-pt/
<*> Para sair deste grupo, envie um e-mail para:
[EMAIL PROTECTED]
<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
http://br.yahoo.com/info/utos.html
Re: [Zope-pt] Workflow c/ permissões apenas p/ alguns estados - AGX
E aí, Dorneles?
É ... Parece q no AGX (1.4.0-final) não vai rolar (pelo menos, no TaggedValuesSupport não tem) (|':¬{(»
Mas, se for o caso, vai na mão, mesmo! ...
Muito obrigado pelas dicas e pelas fontes! ...
[ ],
--
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 14/12/05, Dorneles Treméa <[EMAIL PROTECTED]> escreveu:
Opa JJ,
> Agora, uma coisa que fiquei em curioso: Vc se refere a uma opção de Add
> no reference field ... Como assim? Isso quer dizer que o reference field
> me permitiria adicionar o tipo, caso ele não estivesse listado? Se é
> isso, que opção é essa (e, se tiver algo mais a fazer p/ isso, como é)?
é isso mesmo, basta adicionar o atributo 'addable = True' no widget
do ReferenceField.
Para ativar isso via ArchGenXML, bastaria definir um novo tagged value
no field em questão: widget:addable, com um valor verdadeiro. Mas como
eu não uso ele, não sei se o suporte está implementado... ;-)
Vale a pena dar uma sapeada nas propriedades adicionais que cada
Field e Widget disponibilizam. O melhor lugar para ver isso é no
próprio fonte:
http://trac.plone.org/archetypes/browser/Archetypes/branches/release-1_3-branch/Field.py#L1500
http://trac.plone.org/archetypes/browser/Archetypes/branches/release-1_3-branch/Widget.py#L178
HTH,
--
Dorneles Treméa
X3ng Web Technology
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
Para visitar o site do seu grupo na web, acesse:http://br.groups.yahoo.com/group/zope-pt/
Para sair deste grupo, envie um e-mail para:[EMAIL PROTECTED]
O uso que você faz do Yahoo! Grupos está sujeito aos Termos do Serviço do Yahoo!.
Re: [Zope-pt] Workflow c/ permissões apenas p/ alguns estados - AGX
Opa JJ, > Agora, uma coisa que fiquei em curioso: Vc se refere a uma opção de Add > no reference field ... Como assim? Isso quer dizer que o reference field > me permitiria adicionar o tipo, caso ele não estivesse listado? Se é > isso, que opção é essa (e, se tiver algo mais a fazer p/ isso, como é)? é isso mesmo, basta adicionar o atributo 'addable = True' no widget do ReferenceField. Para ativar isso via ArchGenXML, bastaria definir um novo tagged value no field em questão: widget:addable, com um valor verdadeiro. Mas como eu não uso ele, não sei se o suporte está implementado... ;-) Vale a pena dar uma sapeada nas propriedades adicionais que cada Field e Widget disponibilizam. O melhor lugar para ver isso é no próprio fonte: http://trac.plone.org/archetypes/browser/Archetypes/branches/release-1_3-branch/Field.py#L1500 http://trac.plone.org/archetypes/browser/Archetypes/branches/release-1_3-branch/Widget.py#L178 HTH, -- Dorneles Treméa X3ng Web Technology Para enviar uma mensagem: zope-pt@yahoogrupos.com.br Para desistir envie uma mensagem em branco para: [EMAIL PROTECTED] Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/zope-pt/ <*> Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
Re: [Zope-pt] Workflow c/ permissões apenas p/ alguns estados - AGX
Xirú (e/ou quem mais souber),
Primeiro, obrigado pelas idéias. Não consegui implementar completamente
o que vc sugeriu mas as sugestões me deram alumas idéias e melhorou
bastante ...
Agora, uma coisa que fiquei em curioso: Vc se refere a uma opção de Add
no reference field ... Como assim? Isso quer dizer que o reference
field me permitiria adicionar o tipo, caso ele não estivesse listado?
Se é isso, que opção é essa (e, se tiver algo mais a fazer p/ isso,
como é)?
Agradeço pela ajuda (estou aprendendo e preciso de toda que puder ter)
... Se tiver links sobre o assunto, é muito bem vindo! O que tenho mais
completo até agora (o que não é muito) sobre o AGX foi o ArchGenXML -
Getting Started [1] mas, às vezes, ele me deixa na mão (não tem algumas
coisas) e uso um pouco o Archetypes Developers Guide [2] p/ consulta
rápida sobre widgets ...
[1] http://plone.org/documentation/tutorial/archgenxml-getting-started/
[2] http://plone.org/products/archetypes/documentation/old/ArchetypesDeveloperGuide
[ ],
--
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 funcio
Re: [Zope-pt] Workflow c/ permissões apenas p/ alguns estados - AGX
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 contr
Re: [Zope-pt] Workflow c/ permissões apenas p/ alguns estados - AGX
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
[Zope-pt] Workflow c/ permissões apenas p/ alguns estados - AGX
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?
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.
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). 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.
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. 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?
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.
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, ...
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
Para visitar o site do seu grupo na web, acesse:http://br.groups.yahoo.com/group/zope-pt/
Para sair deste grupo, envie um e-mail para:[EMAIL PROTECTED]
O uso que você faz do Yahoo! Grupos está sujeito aos Termos do Serviço do Yahoo!.
