The problem

We upgraded from Plone 3.1.4 to Plone 3.2.3, both using zc.buildout.  (That was a long, hairy process, too.)  Our buildout includes several third-party products, including a custom policy product of our own.  Our own product includes two custom workflows.  (They are named "original" and "crispy".)

When we upgraded, somehow the "crispy" workflow was used, rather than the "original" workflow.  This showed up in the ZMI > portal_workflows > "Workflows by type" listing.  The entries used to say "original" before upgrade, but now they all read "crispy".  (This was not intended or expected.)

Initially, the end-result was that some folders looked like they were restricted, when the editor viewed them.  However, other non-authorized users were able to see these folders.  In reality, these folders had the "open" workflow state, from the "original" workflow.  However, the site was using the "crispy" workflow and could not correctly display the "open" state from the other workflow.

To clarify: it appears that Plone workflow states are identified uniquely by both workflow name and state name.  This is why it is important to click the "Apply Security Settings" button after you change workflows via the ZMI.

So, without really thinking it through enough, I clicked "Apply Security Settings" in the ZMI.  Bad move.  Plone adjusted most of the workflow states fine.  But, there were a few items that it could not adjust, so it set their workflow state to the default, which is "restricted" (in the "crispy" workflow).

The end-result is that most of the site is now unreachable by end-users.  Also, the content managers don't want to manually go and fix what I just automagically messed up.  Sigh. I should have stayed on vacation.