Martin Aspeli schrieb:
At the very least we should be carefull not to override any exisiting
workflows which may just happen to have the same name.
In addition, we must not touch any type -> workflow mappings
nor change the default workflow or we are in danger of
breaking the site's security settings completely.
This means we cannot simply load the workflow tool step
from the profile - I think at least. Doing it more carefully
"by hand" could be OK though.
I think the correct behaviour would be:
- For each new workflow:
- Check if an existing workflow has the same name
- If not, add it to the workflow tool
- Do not touch workflow mappings
- Do not modify existing workflows in any way
I general I agree; it's mostly a practical issue here because
the old API for adding workflows to the tool is gone and
I simply don't know whether/how GS supports doing only
parts of an import step (import wf x and y but leave z alone;
don't touch the chains ...) but maybe it's just me and all this
turns out to be a non-issue.
All I'm saying is: it's not as straight-forward as it might seem
at first glance. Which means if we address this it should have
thorough testing on non-trivial, real-world setups which happen
to have a custom workflow with one of the new ids as well as
changes in Plone's default workflows as well as changed type
assigments.
While thinking about this: one approach could be to define
individual extension profiles for each new workflow we ship
with. On migration, just check for existance and if not load that
particular profile. This should add the new wf to the tool but
leave everything else alone. (just thinking aloud)
If someone champions this tonight, great'! ;-)
Raphael
The upshot of this is that we have a control panel where people can
switch sensibly to the new workflows if they wish.
Martin
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
