Jens Vagelpohl wrote:
> An open Launchpad issue had me take a look at the import/export
> machinery for the actions tool and action providers
> ). I see some inconsistencies and would like to get rid of them.
> Here's the behavior I read out of the code:
> - _all_ action providers known to the actions tool are written to
> actions.xml as "action-provider" nodes
> - if an action provider contains "old-style" actions, those are
> exported as children of the corresponding "action-provider" node.
> Curiously, that action information export is marked "BBB: for CMF 1.6
That's a copy 'n' paste error. For exports that should be "CMF 1.6
settings", not "CMF 1.6 profiles".
While you still can use the Action tabs, it is no longer recommended
since CMF 2.0 and the export/import machinery moves Actions from those
tabs to the recommended place.
> - the "action-provider" nodes are added to the actions tool if they
> do not exist _and_ if their IDs happen to be 'portal_actions',
> 'portal_types' or 'portal_workflow'. None of the other "action-
> provider" nodes are added.
This is migration code. Since CMF 2.0 all 'normal' Actions should be
stored in portal_actions. Only 'special' Actions (in CMF type Actions
and workflow Actions have special implementations) should be stored in
other tools. But the hardcoded _SPECIAL_PROVIDERS list is problematic as
described in the bug report.
> - if the "action-provider" node has children of type "action", their
> data is imported and recreated on the respective provider as "old-
> style" actions. This is also marked as "BBB: for CMF 1.6 profiles".
No. This is also migration code. They are recreated as newstyle Actions
> The main discrepancy is in the handling of action providers that are
> not 'portal_actions', 'portal_types' or 'portal_workflow'. Their data
> is exported, but they are not re-added to the actions tool during
> import. Also, the BBB note about "CMF 1.6 profiles" is confusing. That
> mechanism is still in use today, it hasn't been discarded after 1.6.
It might not have been the best idea to make implicit migrations on
import. Anyway. We now are talking about CMF 2.2 and most people should
meanwhile have migrated their 'normal' Actions to portal_actions. So I'm
fine with removing the migration code.
> I would like to change the actions tool import/export code so it does
> the following:
> - all action-provider nodes from the export should be added to the
> actions tool during import if they are not already registered there.
> - the old-style action information data should not be handled
> centrally by the actions tool export/import, unless those actions are
> on the actions tool itself. All other providers should export/import
> their old-style actions themselves.
+1 for making the handler of each tool responsible for its Actions
But I propose to add deprecation warnings for 'normal' Actions (not type
Actions) stored in Actions tabs. People did have enough time to move
those Actions to the Actions tool. And if 'normal' oldstyle Actions are
deprecated, we don't have to provide export/import support for them.
> - clarify the BBB comment
Zope-CMF maillist - Zope-CMF@lists.zope.org
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests