In article <[EMAIL PROTECTED]> "Alexander Limi"<[EMAIL PROTECTED]> wrote:
> On Thu, 21 Jun 2007 06:26:42 -0700, Ed Eddington > <[EMAIL PROTECTED]> wrote: > >> This problem may be related to workflow. The _View_Permission that >> is reset during migration appears to be set to the object's >> published workflow state. However, in our case, we have a workflow >> script that is supposed to run before/after the publish transition >> to preserve the _View_Permission. Can anyone clarify what workflow >> related updates are done during a migration (are objects >> "published", or "retracted and republished", etc.)? It appears as if >> _View_Permission is simply being reset to the permissions defined in >> the workflow state - WITHOUT running the transition scripts. > This is how workflows work. Never set permissions manually outside > of workflow states. They will be reset to what the state specifies. > > (unless I misunderstood what you're explaining above) > Yes. I realized the problem was a result of the voodoo we are doing in our workflow (we implemented before/after workflow scripts to adjust view permission for our 5 custom roles - instead of having a workflow state for every possible combination of view permissions). It has worked fine as long as workflow states arn't reset without running the scripts. We will be revising this scheme using Local Roles and a single custom role. The problem that led us to this implementation was the difficulty in restricting anonymous view permission for content. In order to achieve this with workflow, you need a separate published workflow state that doesn't "aquire" the anon view permission from the parent. Without local roles in Plone 2.0 we chose to roll our own. -- I'm trying a new usenet client for Mac, Nemo OS X. You can download it at http://www.malcom-mac.com/nemo _______________________________________________ Setup mailing list [email protected] http://lists.plone.org/mailman/listinfo/setup
