Skip to content

Bika Lab Systems

Sections
Personal tools
You are here: Home Help Centre Manuals Managing Content in Plone Managing Workflows Understanding Roles and Security in Workflow
Document Actions

6.3. Understanding Roles and Security in Workflow

Up one level
In any complicated system, you'll have users of all roles and groups. These roles give Plone a large amount of flexibility with security, but they also can make it more complicated. The next Chapter covers security, local roles, and groups, but this section covers some key points about how these topics relate to workflow.

When a piece of content moves from one workflow state to another, the workflow process can change the security settings on that content. The security settings determine what user can perform what action on what piece of content. By manipulating the security settings through workflow, you can cause the security to change on a piece of content through its life cycle. Users from static systems or Zope often get confused because in Zope, all pieces of content have the same security settings throughout their life cycle.

Returning to the credit card example, you can infer the security settings for the credit card bill. One way to represent this is to produce a table that expands the security in general terms for the transitions that can occur at each of the various states, as shown in Table 8-1.

Table 8-1. The Transitions and Entities That Can Make Them

State Me Bank
Draft   Post
Review Pay Reject
Paid    

At this stage in Table 8-1, you've seen the transitions and who can make them. You haven't thought about the access that each user has to perform an action on an object at each point. For example, at which point can someone edit the bill, and when can it be viewed? These are called actions in Plone terminology, as shown in Table 8-2. I hope that only I have access to my own credit card statements! Likewise, at any stage, the bank is able to view the credit card bill and answer queries on it.

Table 8-2. The Actions and Entities That Can Make Them

State Me Bank
Draft   View, Edit
Review View View
Paid View View

Actually, as it turns out, I can't edit my credit card bill; only the bank can. I can send back my credit bill by rejecting it, but the bank is unlikely to want my edits. In this situation, assume the bank is the owner of the credit card bill. This demonstrates a concept called ownership. I may have several credit card bills from several banks, and in each case you can think of the bank as the owner. Each bank owns its own credit card bills, but Bank A isn't the owner of Bank B's bill. Table 8-3 combines the transitions and actions, changing the terms Me and Bank to Payee and Owner, respectively.

Table 8-3. The Transitions and Actions Combined, plus the Roles of People

State Payee Owner
Draft   Post, View, Edit
Review Pay, Reject, View View
Paid View View
Of course, this is a rather contrived example, but it illustrates how you can apply workflow to basic states. More transitions can occur here-for instance, I'd be more than happy for someone else to pay my credit card bill for me-but that's so unlikely that you shouldn't add it to the workflow or security.

Before showing how to create and edit workflows, I'll now show you the default workflows that ship with Plone.

 

www.bikalabs.com - Home of Bika Lab Systems, implementers of web based open source LIMS, Plone hosting and content management systems   Powered by Plone, the open source content management system. Customised and maintained by Bika Lab Systems