As permissões mais comuns são 'View', 'Modify portal content', 'Access contents information' e 'List folder contents'. Estas (junto com algumas outros, como 'Manage portal') são conhecidas como as "CMF Core permissions", localizadas no arquivo 'Products/CMFCore/CMFCorePermissions.py' em variáveis como 'View' e 'ModifyPortalContent'. Em geral, a maioria dos tipos de conteúdo usam essas permissões para acessar e modificar dados. Você pode achar um pouco estranho no início, mas depois verá como o workflow é usado para obter um controle preciso sobre tais permissões.

Permissões são atribuídas a papéis de usuários (user roles), não a usuários individualmente. Logo, costuma-se dizer que, na pasta X, qualquer usuário com 'RandomRole' tem permissão para 'Modify Portal Content', isto é, pode modificar o conteúdo do portal. Os papéis padrões são: 'Member', 'Manager' e 'Reviewer'. Existem também alguns papéis "automáticos", como 'Owner' e 'Anonymous'. O papel 'Anonymous' é atribuído a todo usuário que não está autenticado. A maioria dos membros de um portal possui o papel de 'Member', mas isso não é garantido. 'Owner' somente se aplica quando o atual usuário é o dono de um determinado conteúdo.

Na Interface de Gerenciamento do Zope (em inglês, ZMI), quase todos os objetos possuem uma aba 'Security' (segurança). Nela podemos verificar uma longa listagem de permissões atribuídas a papéis. A maioria delas está marcada com 'Acquire permission settings', significando que as permissões concedidas a estes papéis são as mesmas do objeto pai. Definições de segurança no Zope são aditivas, logo se você mantiver a opção 'Acquire' marcada e adicionar outros papéis, você obterá os papéis configurados para os níveis superiores (objeto pai) somados aos papéis configurados neste nível. Você pode parar essa aquisição hereditária de regras desmarcando a opção 'Acquire'.

Na maioria dos casos, você não irá modificar permissões dessa forma, exceto ao configurar padrões globais para permissões diferentes das permissões centrais acima. Um exemplo comum é restringir a permissão de 'Add portal member' (adicionar membro do portal) apenas para administradores de nível raiz (root) com o objetivo de privar seu portal de cadastros públicos. Por padrão, essa permissão é dada para o papel 'Anonymous', o que significa que qualquer um pode se cadastrar no site (assim criando um novo membro no portal). Entretanto, seu primeiro ponto de chamadas deve ser sempre oworkflow.

Você pode livremente adicionar papéis conforme sua necessidade. Como membros podem possuir mais de um papel simultaneamente, você provavelmente só precisa se preocupar com um subconjunto de permissões quando se trata de atribui-las para um novo papel. Use o formulário na parte inferior da guia 'Security' na raiz do portal para adicionar e remover papéis.

Usuários podem ser associados a papéis manualmente usando a pasta de usuários 'acl_users' na raiz de sua instância Plone (não a que se encontra na raiz do Zope). Entretanto, é mais comum atribuir papéis a grupos e então adicionar usuários nos grupos, como descrito na proxima seção.

Users can be in groups - managed via users and groups administration in plone setup. Groups can be given particular roles if need be - all users in that group will gain the given role.

Usuários podem estar em grupos - gerenciados por meio da tela de administração de usuários e grupos nas Configurações do Site. Papéis podem ser atribuídos a grupos de acordo com a necessidade - todos os usuários neste grupo receberam o papel atribuído ao grupo.

É bastante incomum que somente um usuário receba determinado papel. É mais provável que grupos de usuários possuam os mesmos papéis no portal - e mesmo quando existe apenas um usuário (por exemplo, apenas um gestor do site), muitas vezes faz sentido para atender a possibilidade de havermais usuários no futuro. Como os usuários podem estar em vários grupos ao mesmo tempo, você pode ter um controle preciso sobre as permissões e classificações de usuários que utilizam esse mecanismo.

Na página anterior mostramos como fazer novos papéis no portal. Utilizando a ferramenta de administração de usuários e grupos nas Configurações do Site, você pode facilmente associar papéis a grupos - simplesmente marque as caixas relevantes e salve. Em seguida, clique no usuário para associá-lo aos grupos relevantes. Uma vez dentro de um grupo, o usuário ganhará todos os papéis atribuídos para aquele grupo além de quaisquer papéisatribuídos apenas para aquele usuário.

No formulário de papéis locais, você pode pesquisar por outros usuários e associar-lhes papéis. Você pode também associar papéis para grupos (veja a seção anterior). O mais comum, você dará a outros usuários o papel de 'Owner' (dono) ou 'Manager' (gerente) sobre seu conteúdo para lhes permitir a modificação, mas com permissões e papéis personalizados, você pode ter outros papéis a conceder. 

Note that role selection will acquire down, so if a user has Manager role at the '/stuff' folder, they will also have it at '/stuff/documents/my-document'. Currently (until Plone 2.1, most likely), local roles can be added at a lower level in the acqusition tree, but not taken away. That is, if you give a user Manager permissions at '/stuff', there is no way to prevent him or her from having the Manager permission at '/stuff/documents'. This is summarised in PLIP 16.

Note que a seleção do papel será adiquirida, apenas se um usuário possuir papel de Manager na pasta '/stuff', eles também possuem isso em '/stuff/documents/my-document'. Atualmente (a partir do Plone 2.1, mais precisamente), papéis locais podem ser adicionados em um nível mais baixo na arvore que aquisição, mas não poderão ser retirados. Significa que, se você dá a um usuário permissões de gerente em '/stuff', não há como previni-lo de ter permissões de gerente em '/stuff/documents'. Isso é resumido em PLIP 16. 

A common way of using local roles is to give the members of a particular portal group Manager permissions in a given folder. For example, to give all members of the 'A-Team' group free reins in the '/missions' folder, go to '/missions/folder_localrole_form' either by typing in the URL or clicking the 'sharing' tab in that folder, and assign the Manager local role to the 'A-Team' group.

Uma forma comum de se utilizar papéis locais é dar aos membros de um grupo em particular permissões de Manager em uma dada pasta. Por exemplo, para dar a todos os membros do grupo 'Equipe-A' livre controle na pasta '/missions', vá para  '/missions/folder_localrole_form' digitando na URL ou clicando na aba 'sharing' dentro da pasta, e atribua o papel local de Manager para o grupo 'Equipe-A'.

Workflow states are shown on content objects in the state drop-down at the top right, in the green border on content you have permission to edit. The items in the menu are the transitions you can use between workflow states. For example, to move from the visible (default) to the published state, you use the publish transition. State transitions can have guards based on roles (only members in a certain role in the current context can execute the transition - for example, only Managers and Reviewers are permitted to use the publish transition in the default Plone workflow), permissions or arbitrary expressions. Each content type either has no workflow (rare) or has exactly one workflow associated with it. This is set via the portal_workflow tool. The Contents tab of this tool in the ZMI shows the currently installed workflows. You can add or modify workflows via this GUI, adding states (remember to set a default state!), transitions and the allowed transitions between states. More documentation on the DCWorkflow engine can be found on zope.org.

Estados do Workflow são exibidos em objetos contidos no drop-down (menu desdobravél) state (estado) no canto superior-direito, na borda verde em conteúdos cujo você possuí permissões para editar. Os itens no menú são as transições que você pode utilizar entre os estados do workflow. Por exemplo, para mover de visible (estado padrão) para o published você utiliza a transição publish. Transições de estado podem possuir papéis baseados em guardas (apenas membros em um determinado papel no atual contexto podem executar a transição - por exemplo, apenas Managers eReviewers podem usar a transição publish no workflow padrão do Plone), permissões são expressões arbitrarias. Todo tipo de conteúdo ou não possui workflow (raro) ou possui exatamente um associado a ele. Isso é configurado através da ferramenta portal_workflow. A aba de conteúdo desta ferramenta na ZMI exibe os workflows instalados atualmente. Você pode adicionar ou modificar workflows através dessa GUI, adicionando estados (lembre-se de configurar o estado padrão), transições e permitindo transições entre os estados. Outras documentações sobre o mecainsmo DCWorkflow pode ser encontrado no zope.org.

The workflow engine will manage a certain number of permissions and set them correctly when the state of an object is changed. You should rarely, if ever, need to change permissions at the "Security" tab. Instead, you change them in the workflow associated with the folder or content type in question. This is the mechanism which allows several different content objects to re-use the CMF core permissions. For example, the Anonymous role has the Viewpermission in the published state, but not the visible state. Note that if you modify a workflow's permissions-in-state mapping, the changes will not affect existing objects automatically. You must update the security settings by clicking Update security settings at the bottom of the Workflows tab in portal_workflow in the ZMI.

O mecanismo workflow irá gerenciar um certo número de permissões e configura-los corretamente quando o estado de um objeto é mudado. Você deverá raramente, se alguma vez, precisar mudar permissões na aba 'Security'. Ao invés disso, você as muda  no workflow associado com a pasta ou tipo de conteúdo em questão. este é o mecanismo que permite diversos objetos de conteudos diferentes reutilizarem as permissões do nucleo do CMF. Por exemplo, o papel Anonymous tem a permissão View no estado published , mas não possui no estado visible. Note que se você modificar uma permissão de estado no mapeamento do workflow, as mudanças não irão afetar objetos existentes automaticamente. Você deve atualizar as configurações de segurança clicando em Update security settings na base da aba Workflows dentro de portal_workflow na ZMI.

Thus, workflows serve a dual purpose - to represent the evolution of a piece of content, from creation (the initial state), through a review cycle (if there is one), to a final state, and to control the permissions to the content in each state. If you have particular needs, you can create a new workflow (usually based on an existing workflow), set up the states and transitions necessary, make the workflow manage a certain set of permission and set the role-to-permission mapping for those permissions in each workflow state. Using role or permission guards on transitions, you can then control who is at liberty to alter the permissions. For more details on how to use the DCWorkflow engine, read its documentation.

Desta forma, workflows servem para dois propositos - representar a evoluão de um pedaço de conteudo, desde a criação (estado inicial), através dos cilcos de revisão (se houver), até o estado final, e para controlar as permissões para o conteúdo em cada estado. Se você tem necessidades particulares, você deve criar um novo workflow (comumente baseado em um workflow já existente), configurar os estados e transições necessarias, fazer o workflow gerenciar um certo conjunto de permissões e configurar o mapeamento de papéis-permissões para cada estado no workflow. Usando papéis ou permissões guardas na transição, você pode controlar quem tem a liberdade de alterar as permissões. Para mais detalhes sobre como usar o mecanismo DCWorkflow, leia este documento.

Explaining how to develop products and secure them properly is beyond the scope of this tutorial. Suffice it to say that to create re-usable Zope/Plone components, and for the sake of your own sanity, you should be developing your customisations and add-ons on the filesystem, as Zope products. Raphal Ritz' excellent MySite tutorial will give you a good and in-depth introduction to the topic.

PT-BR - Mostrando como desenvolver produtos e segurá-los adequadamente é algo além do escopo deste tutorial. Basta dizer que para criar componentes reusáveis no  Zope/Plone, e para o bem de sua própria sanidade, você estará desenvolvendo suas customizações e adicionados no sistema de arquivos (filesystem) como um produto Zope. Raphal Ritz' excelente tutorial meu site dará a você uma boa introdução e aprofundamento do tópico.

Protecting your code

When creating classes which are intended to be accessed through the web (typically Archetypes content types or portal tools, though this applies to any Zope class derived from ExtensionClass) you must add security assertions on your methods. Much more information about this can be found in the Zope Developer Guide.

PT-BR -  Quando criando classes destinadas a serem acessadas através da web (normalmente conteúdo do tipo Archetypes ou ferramentas do portal, embora isso se aplique a qualquer classe no Zope derivada de ExtensionClass) você deve adicionar afirmações de segurança nos seus metodos. Muitas outras informações osbre isso podem ser encontradas no Guia de Desenvolvimento Zope.

The following code example shows a general paradigm that is frequently followed in Archetypes products using the CMF core permissions. Please refer to the developer guide's chapter 6 for more details:

PT-BR -  O seguinte exemplo de código mostra um paradigma comum que é frequentemente seguido nos produtos Archetypes usando o nucleo de permissões do CMF. Para mais detalhes, consulte o capitulo 6 no guia do desenvolvedor:

  from AccessControl import ClassSecurityInfo
  from Products.CMFCore import CMFCorePermissions
  # ... (additional imports and initialisation)

  class MyType(BaseContent):

    # ... (initialisation of schema and factory type info)

    # create a class security object to handle our security policy
    security = ClassSecurityInfo()

    # set a method to be publically accessible - all TTW code can
    # call this directly
    security.declarePublic('publicMethod')
    def publicMethod(self):
      # ... (docstring and method body)

    # set a method to be private - no TTW code can call this directly
    security.declarePrivate('privateMethod')
    def privateMethod(self):
      # ... (docstring and method body)

    # set a method to be protected by a given permission.
    # Only users with this permission in the context can call
    security.declareProtecte(CMFCorePermissions.View, 'protectedMethod')
    def protectedMethod(self):
      # ... (docstring and method body)

  # ... (type initialisation)

This rather amputated example shows how a class creates a ClassSecurityInfo object and uses it to declare its methods public (accessible to all through-the-web code), private (not accessible through the web) or protected by some permission - in this case the CMF core permission View. As with all matters of security, you should always protect your methods by the most limiting permission possible to ensure security is not breached.

PT-BR -  Este trecho de exemplo mostra como uma classe cria um objeto ClassSecurityInfo e usa isso para declarar seus metodos públicos (acessivel para todos os códigos através da web), privados (não acessivel através da web) ou protegidos por alguma permissão - neste caso a permissão View do núcleo do CMF. Assim como tudo que se trata de segurança, você deve sempre proteger seus metodos pelas permissões mais privativas possíveis para assegurar que a segurança não seja violada.

Creating new workflows

Workflows can be created through the portal_workflow user interface. If you wish to ship such a workflow with your product, you must dump it to a python file and register it during Install.py. There is a dedicated product for this called DCWorkflowDump. When installed (just put it in your Products folder, no Plone installation necessary), it will give you a Dump tab when viewing a workflow in the ZMI to create a file containing the setup code for your workflow.

PT-BR - Workflows podem ser criados através da interface de usuário do portal_workflow. Se você deseja embarcar tal workflow com seu produto, você deve despejar-lo em um arquivo python e registrar-lo durante a compilação do install.py. Há um produto dedicado a isso chamado DCWorkflowDump. Quando instalado (apenas coloque-o na pasta Products, não é necessario instalação no Plone), isso irá criar uma aba Dump na visualização de um workflow na ZMI para criar um arquivo contendo o código de configuração para seu workflow.

Typically, this workflow definition is dumped into your product's Extensions/ folder and called during Install.py to set up your workflow. If you subsequently wish to make changes to your workflow, you may wish to modify this dumped code directly rather than use the GUI and re-dump, as it is likely to be quicker. The dumped code should be fairly easy to understand once you know a bit about workflows.

PT-BR - Normalmente, esta definição de workflow é despejada na pasta Extensions/ do seu produto e chamada durante Install.py para configurar o seu workflow. Se você futuramente desejar fazer mudanças no seu workflow, você deve desejar modificar este código despejado diretamente ao invés de usar o GUI e despeja-lo novamente, já que assim é mais rápido. O código despejado deve ser razoavelmente facil de entender uma vez que você sabe um pouco sobre workflows.

An alternative way of creating workflow definitions is ArchGenXML. Using this tool, you can create UML state diagrams to represent your workflows. See the ArchGenXML documentation for details.

PT-BR - Uma forma alternativa de criar definições para o workflow é o ArchGenXML. Usando esta ferramenta você pode criar diagramas UML de estado para representar seu workflow. Veja a documentação do ArchGenXM para mais detalhes.

Finally, once your workflow has been created, you must register it with the workflow tool and associate any types you want with it (ArchGenXML does all of this automatically for you). The following code snippet is adapted from the PloneHelpCenter - the fine software that runs this documentation section - also found in the Collective. You may want to look at that product in more detail (a CVS checkout will be preferable) to see how workflows are used "in real life". In Extensions/Install.py, you may wish to put:

PT-BR -  Finalmente, uma vez que seu workflow foi criado você deve registra-lo com a ferramenta do workflow e associar qualquer tipo que você queira com ele (ArchGenXML faz isso automaticamente para você). O fragmento de código a seguir é adaptado do PloneHelpCenter - o refinado software que roda essa seção de documentação - também encontrado em Collective. Você pode querer dar uma olhada neste produto para mais detalhes (uma verificação no CVS seria preferível) para ver como o workflow é usado na "vida real". Em Extensions/Install.py, você pode querer inserir:

    # ...  (header and imports)

    def install(self):

        # ... (additional installation and setup)

        # Get our workflow and install it
        from Products.MyProduct.Extensions import MyWorkflow

        # The PloneHelpCenter does this, because it modifies the
        # dumped file to put the installation-initiating code inside
        # a method called install(). By default, it is called
        # automatically as soon as the workflow module is imported.

        # HCWorkflow.install()

        # Register the workflow with the tool
        wf_tool = getToolByName(self, 'portal_workflow')

        # The id of the workflow if my_workflow, and the title is
        # My custom workflow. Due to a dumb API, these names have
        # to be entered verbatim in the argument to the method
        # below, with spaces and parentheses as shown.

        if not 'my_workflow' in wf_tool.objectIds():
            wf_tool.manage_addWorkflow('my_workflow (My custom workflow)',
                                       'my_workflow')

        # Do this after installing all workflows
        wf_tool.updateRoleMappings()

        # Now tell our custom type MyType to use this workflow
        wf_tool.setChainForPortalTypes(pt_names=['MyType'],
                                       chain='my_workflow')

        # ... (additional installation and setup)

That should be it - your custom workflow should be available for use after you install (or re-instal) your product. You are encouraged to take a look at the PloneHelpCenter code for a more comprehensive example

PT-BR -  É isso - seu workflow customizado deve estar pronto para uso após você instalar (ou re-instalar) seu produto. Você está encorajado a dar uma olhada no código do PloneHelpCenterpara um exemplo mais compreensível.