[Framework-Team] Community workflow and plone workflow
optilude at gmx.net
Mon Apr 30 10:39:00 UTC 2007
> 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?
It's not ideal, but since we have switchable workflows, we really need
*all* the workflows to work sensibly. There is some additional work
cleaning up and adding more tests in plone.app.workflow, where we have
some workflow tests already.
For tests which are directly impacted by security settings, or which
test functionality that is security-sensitive, the "default site"
assumption is bunk anyway. Users don't have default sites. Such tests
need to explicitly set up the test fixture or, ideally, test under
*all* the workflows, every time.
> IIRC they are. In essance, it's just a renaming (plus the addition of
> the reader
> and editor role)
We can't rename the id, but we can obviously give them a new title. If
they identical, we should just drop the community workflows and give
the Plone workflow a better title.
FYI, I did a review of all the workflows to make sure the
Reader/Editor/Contributor roles were set properly, and found a few
mistakes. In the process, I ended up touching most of them, if only to
re-order the way roles were listed in the workflow so that they are
easier to compare (I was going crazy trying to work out where the
discrepancies were), and to apply the general short-circuit that if a
permission is given to Anonymous, there is no need to give it to other
roles (Zope short-circuits in this case).
More information about the Framework-Team