[Framework-Team] Community workflow and plone workflow

Raphael Ritz r.ritz at biologie.hu-berlin.de
Mon Apr 30 08:31:46 UTC 2007

Martin Aspeli schrieb:
> Hi guys,
Hi Martin,
> We've determined that removing plone_workflow won't work - it breaks 
> too many tests, which make silly, implicit assumptions about the 
> default workflow.
which is bad testing style then but anyway ... :-(
> However, we don't want this to be the default on freshly created Plone 
> sites, because it is not appropriate for most sites - particularly now 
> that we turned of member folder creation by default. Alex just found a 
> number of security/access control related bugs which make the OOTB 
> user experience a bit painful (basically, only admins can add content 
> on a freshly created site at the moment, which is silly). 
But not too surprizing as the memberareas used to be the
only places where regular members could do that up to now.
> Therefore, I've switched the default, but invoked a hidden 
> 'testfixture' extension profile in Products.CMFPlone.tests.PloneTestCase.
Do I understand correctly that testes now run with different
security settings compared to a TTW created Plone site?
Do we really want that?
> Note that other packages which make workflow assumptions can get this 
> by passing extension_profiles=['Products.CMFPlone:testfixture'] to 
> setupPloneSite().
> I expect we may find a few more of these assumptions. I'd rather they 
> were fixed, but for now we have a workaround. I've run
>  $ zopectl test -s plone
> as well as the CMFPlone and ATContentTypes tests and fixed what I 
> found.  There are some failures around, but most of them have been 
> there for a while and hopefully the relevant people know.
> Anyway, Alex also made the point that plone_workflow and 
> community_workflow are virtually identical.
IIRC they are. In essance, it's just a renaming (plus the addition of 
the reader
and editor role)
> It's pretty much impossible to remove plone_workflow at this stage, 
> but we *can* change its title to be "Community workflow".
As long as we are only concerned about a more meaningful UI
that should be fine.
> Is there a reason to keep both around, or can we just merge the two?
Not having looked more closely at this recently (sorry, I've been out
of the loop for a while) I would assume they could just be merged.

> Martin
> _______________________________________________
> Framework-Team mailing list
> Framework-Team at lists.plone.org
> http://lists.plone.org/mailman/listinfo/framework-team

More information about the Framework-Team mailing list