Personal tools
You are here: Home About this site... Our Workflows Workflow FAQ
Document Actions

Workflow FAQ

by Matt Blair last modified April 03, 2006 01:38 UTC

Answers to questions about HumaniNet's Workflow

I don't get all this workflow stuff.  Am I stupid?

Of course not!  Workflow is one of the most powerful features of Plone, but it can also be one of the most difficult to understand. Workflow is implemented primarily on the Zope level, and it involves the interaction between several different elements of Zope, including users, roles, permissions, state and transitions.  Here are a few statements that may help:

  • Every content item has a state, and each content item can only be in one state at a time.
  • A state assigns permissions to Roles.
  • Users are assigned to one or more Roles.
  • A user's assigned roles will determine whether they can see an item in a particular state, and if so, what they can do with it.
  • Each state has one or more available transitions.  Transitions define a destination state, and who can make that transition.
  • A user's role will also determine what transitions are available to them.

Did you build this from scratch?

No. We started with the workflows included with the GrufSpaces product.  This product adds four new roles on the Zope level: GroupVisitor, GroupMember, GroupLeader and GroupAdmin.  Our customizations are based on those roles.

What is the difference between GroupAdmin and GroupLeader?

Not much, but this may become more distinct in the future.  In our interpretation, GroupAdmin is the 'technical' administator role, while GroupLeader is the 'social' administrator with editorial responsibilities for the group. Both can add site subscribers to the group using the Roles tab. 

Why aren't all the states color-coded?

I plan to do this, I just haven't implemented it yet. Stay tuned. For now, use the Contents tab to quickly view the states of items in a folder.

Why isn't there a transition from Group to Subscriber or Public?  Why does an item have to go through the Pending state?

There are two reasons.  First, this makes publishing any content item a two-step process, even for managers and reviewers, which reduces the chance that we will accidently publish something that we didn't intend to publish.  Second, it means that content authors simply submit, and our managers and reviewers decide whether to show that content to site subscribers or to the public.

What if a folder is not published, but a page within it is published?

Because readers can't see the containing folder, they wouldn't be able to easily find the published page by browsing around your site.  However, they could find it by going directly to the web address for that page, or they could find it through search.  If they do find the page and view it, the containing folders will be displayed in the navigation portlet, whether those folders are published or not

As a rule, containers like GroupSpaces and folders should be set to a state that is the same or more permissive than the content items in them. For example, it makes sense to have a GroupSpace in the 'subscriber' state that has a mix of 'subscriber', 'group only' and 'private' items in it, but it wouldn't make sense to have a 'published' item in the same folder, because that would expose the existence of the folder.

What does the Archive state do?

For now, it simply hides content from most users to reduce clutter.  I use a smart folder to view all archived items across the entire site.  For now, this is a manual process.  In the future, we would like to have content move to the archive state automatically based on the expiration date, and add a bulk-export of all items to static HTML before deleting them from the system. 

Is this version considered final?

Yes and no.  It is 'final' in the sense that it is fully functional and deployed on our site, but we will continue to change it over time to add improvements and match our changing needs.  Rather than assign version numbers, I've opted to use a date code.  The most recent released version was last-edited on March 7, 2006, so the date code is 060307.

Why do you use the term Subscriber and not Member?

By default, Zope/Plone has a role called Member, and so we originally called the Subscriber state Member.  Once we settled on using GroupSpaces, we also had a GroupMember role, and having to continually make the distinction between site members and group members was unwieldy.  We started describing site members as subscribers, which is how we think of them in business terms anyway.  We now use GroupMember and Member interchangeably.  For example, we say that a user is a Member of a group folder.

Why don't you have a 'Visible' state?

In my experience, almost every user found the 'visible' state very confusing.  It doesn't really explain much, because an item that is set to the 'visible' state is always visible to the user viewing it. (Confused yet?)  It also begs the question: visible to whom?  I completely removed it from the 'workflow vocabulary' for all of our Plone-based sites, in favor of words that were more indicitative of who could see the item, like group, subscriber and published.

Creative Commons License
This work is licensed under a
Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License.


Powered by Plone, the Open Source Content Management System

This site conforms to the following standards: