• Nenhum resultado encontrado

Fase III Iteração II

N/A
N/A
Protected

Academic year: 2021

Share "Fase III Iteração II"

Copied!
5
0
0

Texto

(1)

Fase III – Iteração II

Gerenciamento de Usuários e Workflow do Portal

1) Introdução

Para que um portal ofereça um eficiente gerenciamento de conteúdo é necessário que as  funções dos usuários e os processos usados para gerenciar seus objetos estejam bem definidos. Para  isto foi realizado, na fase de análise, o levantamento e mapeamento dos usuários e definição de um  outro Workflow para os tipos de conteúdo, que serão abordados neste relatório.

2) Usuários mapeados no portal

O Plone usa papéis para definir o que os usuários podem fazer no portal, acessar, quando e  onde. Estes papéis serão adicionados aos usuários cadastrados de acordo com sua função no portal.  Desta forma, o Plone tem segurança em todos os aspectos de sua operação. No levantamento realizado no início do projeto não foi mapeado nenhum papel além dos que  o Plone já apresenta por padrão. Os papéis do Plone contemplam todas as necessidades apresentadas  para gerenciamento do conteúdo e administração do portal. Abaixo serão comentadas as funções que serão atribuídas aos usuários bem como o que será  realizado por cada perfil. 2.1) Manager (Administrador) O papel de administrador do site deve ser dado apenas para pessoas que irão gerenciar o  portal e não o conteúdo do site. Pois o administrador: ● Terá acesso a Interface de Gerenciamento do Zope (ZMI); ● Alterará as propriedades do portal, se necessário; ● Instalará produtos quando necessário; ● Configurará o Webmail; ● Configurará novas portlets para o portal; ● Configurará novas notícias a serem mostradas no portal através do CMFSin; ● Configurará o workflow do produto de Ouvidoria, Ombudsman; ● Configurará os estilos do portal através do gerenciador de CSS, CSSManager; ● Visualizará todo o conteúdo do portal, até mesmo conteúdo privado; ● Poderá inserir, remover e publicar conteúdo no portal; ● Agendará tarefas no sistema de backup; ● Poderá desfazer ações realizadas no portal; ● Controlará os papéis atribuídos aos usuários cadastrados no portal;

(2)

● Atribuir papéis locais a usuários; ● Controlará grupos; ● Terá acesso ao log de erros; ● Configurará a previsão do tempo para sua cidade; ● Poderá inserir qualquer tipo de conteúdo no portal; ● Terá acesso às Configurações do Plone na Interface de Gerenciamento do Plone (PMI), ● Poderá modificar o layout do portal. 2.2) Member (Membro)

Dentre   todas   as   atribuições   do   administrador,   está   a   capacidade   de   atribuir   papéis   aos  usuários cadastrados no site. Quando os usuários são cadastrados já é atribuídos a eles papel de  membro. O membro poderá: ● Visualizar somente o conteúdo visível e publicado no portal; ● Adicionar conteúdo somente no local determinado pelo administrador e na sua pasta; ● Somente enviar para revisão o conteúdo que inserir no portal; ● Alterar apenas as suas configurações dentro do portal; ● Configurar sua conta de email, se estiver habilitada a funcionalidade de Webmail;

Nota:  Poderá   ser   atribuído,   pelo   administrador,   a   função   de   administrador   local,   em   uma  determinada pasta a qualquer membro do site. Dessa forma o membro poderá inserir, excluir, alterar  o conteúdo daquela pasta, até mesmo publicar os objetos. 2.3) Reviewer (Revisor) O papel de revisor será atribuído pelo administrador a qualquer membro do portal que: ● Poderá revisar e publicar o conteúdo em um determinado local ou no portal inteiro; ● Poderá inserir conteúdo em um determinado local ou no portal inteiro; ● Dará andamento ou não a uma solicitação realizada pelo usuário no sistema de Ouvidoria. 2.4) Anonymous (Anônimo) Todo o usuário que não estiver autenticado no portal será considerado um usuário anônimo.  Ele não poderá inserir conteúdo, nem editá­lo, salvo se o administrador do site permitir que o  Sistema de Ouvidoria seja aberto ao usuário anônimo. 2.5) Owner (Dono) Os membros têm a função de dono sobre todo o conteúdo que eles criam. Isto faz com que  eles editem o conteúdo, enviem ou retirem­no, ou façam dele privado.

(3)

3) Sistema de Segurança do Zope

As políticas de segurança do Zope controlam a autorização; elas definem quem pode fazer o  que. Políticas de segurança descrevem os papéis e suas respectivas permissões. Papéis identificam  classes de usuários, e as permissões protegem objetos. Assim, políticas de segurança definem quais  classes de usuários (papéis) podem fazer quais tipos de ações (permissões) numa dada parte do site. Mais do que dizer qual usuário específico pode tomar qual ação específica em qual objeto  específico, o Zope permite definir quais tipos de usuários podem tomar quais tipos de ação em  quais áreas do site. Esse tipo de generalização torna suas políticas de segurança mais simples e mais  poderosas.

A   Figura   1   mostra   a   aba   Security   do   Zope,   onde   encontra­se   todo   o   mecanismo   de  segurança. Figura 1: Sistema de segurança do Zope O Workflow trabalha em conjunto com as permissões determinadas no Sistema de segurança  do Zope e suas funções. Nos estados do workflow está configurado um conjunto de permissões e  usuários que quando acionados modificam o estado das permissões do objeto. No capítulo 3.1 serão  abordadas que permissões trabalham com que usuários em quais estados. 3.1) Implementação do novo workflow do portal

O   workflow   utilizado   pelos   tipos   de   conteúdo   não   folderish   (pasta)   do   Plone   não   se  adequava às transições dos estados que foi  proposto pelo produto ILPortalCasas. Para isto foi  desenvolvido um novo workflow (portal_modelo_workflow) que substitui o  plone_workflow  na 

(4)

instalação do produto.

Ao  ser   instalado,  o   ILPortalCasas   configura,  no  portal_workflow,  o campo  Default  de  plone_workflow  para  portal_modelo_workflow. Assim, todos os tipos de conteúdo não folderish 

passam a respeitar este workflow. Os tipos folderish (Folder, Large Plone Folder, Topic) do Plone  continuam respeitando o folder_workflow. A imagem que o representa é a Figura 2. Figura 2: Workflow portal_modelo_workflow Nota: Os tipos de conteúdo de Fórum (Ploneboard), Ouvidoria (Ombudsman) implementam seus  próprios workflows. O workflow do Sistema de Ouvidoria será tratado no relatório sobre este  sistema. Os tipos de conteúdo que respeitam o portal_modelo_workflow são: windowZ, Document, 

Event,   Favorite,   File,   Image,   Link,   News   Item,   Newsletter,   NewsletterTheme,   PlonePopoll,  PloneImapClient, Subscriber. O funcionamento do portal_modelo_workflow dá­se da seguinte maneira: 3.1) Estado private (privado) Quando um tipo de conteúdo, dos citados acima, for criado, ele estará no estado inicial do  workflow private (privado). Neste estado o Manager e o Owner podem: ● Visualizar e acessar o objeto; ● Modificar o estado do workflow; ● Editar o objeto;

(5)

Deste  estado ele pode ir para o estado  visible (visível), com a transição  show, onde o  Anônimo e o Revisor podem: ● Visualizar e acessar o objeto; E o Manager e Owner podem: ● Visualizar e acessar o objeto; ● Modificar o estado do workflow; ● Editar o objeto; Ou pode ir para o estado pending (pendente), com a transição submit, onde o Manager e o  Revisor podem: ● Visualizar e acessar o objeto; ● Modificar o estado do workflow; ● Editar o objeto; Ou ir para o estado published (publicado), com a transição publish. Onde o Manager pode: ● Visualizar e acessar o objeto; ● Modificar o estado do workflow; ● Editar o objeto; 3.2) Estado published (publicado) Quando o objeto é aceito e já pode ser publicado ele é transitado para o estado published  (publicado). Deste estado ele somente pode voltar para o estado private (privado), com a transição  hide. 3.3) Estado visible (visível)

Quando   o   objeto   não   ficará   no   estado  published   (publicado)  nem   no   estado  private  (privado), ele ficará somente visível, portanto no estado  visible (visível). Deste estado somente  poderá voltar ao estado private (privado), com a transição hide. 3.4) Estado pending (pendente) Quando um objeto ficará no estado à espera de publicação ou rejeição, ele estará no estado  pending (pendente). Dele poderá ir para os estados published (publicado), com a transição publish,  se aceito, e private (privado) com a transição hide, se rejeitado.

Referências

Documentos relacionados

[r]

Quando acalentamos, nos anos 80, a ideia de criar a Escola Superior de Teologia e Espiritualidade Franciscana, sonha- mos com uma comunidade WHROyJLFD, isto é, uma comunidade

a) Estou ciente de que se trata de uma corrida de rua com distância de 10km. b) Estou em plenas condições físicas e psicológicas de participar desta CORRIDA e

Contudo, no presente estudo, considerando a possibilidade do equipamento e a relação com as funções orais, foram utilizadas três provas para mensurar a força da

Gestão de Recursos Humanos 65173 Sofia Leal Custódio dos Santos A História Moderna e Contemporânea 64946 Pedro Miguel Ferreira Rios Pinto A. História Moderna e Contemporânea

As infecções relacionadas a assistência à saúde são complicações freqüentes em pacientes hospitalizados, são consideradas graves, pois estão relacionadas com o

No presente inventário, por ainda não existirem dados disponíveis no clube sobre o consumo de recursos de cada esporte, respeitamos este fator de alocação, considerando 55,5%

Com a criação da Fundação de Previdência Complementar do Servidor Público Federal (Funpresp), o valor das aposentadorias e pensões no serviço público civil deixará de ser