Ticket #5823 (closed Bug: fixed)
GenericSetup import steps `plone_various` and `plone-final` should have config files
| Reported by: | mj | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | 2.5.1 |
| Component: | Infrastructure | Keywords: | genericsetup profile |
| Cc: |
Description
The Plone GenericSetup default profile uses two import steps that do not need any configuration files, to execute changes that do not have more specific, configurable import steps. However, these steps are also run for extension profiles, where their effects can have unwanted effects.
An extension profile 'inherits' all the import steps from the base profile, but normally import steps don't do anything without a configuration file for that step in the extension profile. E.g. the actions importer will not do anything if there is no actions.xml file in the extension profile directory. The plone_various and plone-final steps on the other hand, will also be run in an extension profile, possibly resulting in errors or unwanted reconfiguration because the configuration of the Plone site has changed due to the extension profile.
Currently the workaround is to re-register the offending steps in the extension profile's import_steps.xml with a no-op method, but that requires a tight coupling on the step version (potentially breaking again in a point upgrade of Plone), and is basically a dirty hack, because these steps break the normal step pattern.
Instead, the plone_various and plone-final should check for the presence of flag files in the Plone profile. An extension profile would not include these flag files, and thus the step would not do anything. These flag files then form the configuration for these steps, namely making wether they run or not configurable.
Attachments
Change History
Changed 5 years ago by mj
-
attachment
ploneStepsConfig.diff
added
comment:1 Changed 5 years ago by mj
The attach patch (against the 2.5 branch) doesn't break any more tests or alters the 15 errors I get from running the testPortalCreation.py test file. That I get 15 test failures on that test in the first place is rather disconcerting, so I rather have someone else vet this patch for me and verify that nothing has been broken by this.
Otherwise, the patch does achieve the intended effect for me.
comment:2 Changed 5 years ago by wichert
The patch by itself looks correct. However this looks like a more generic problem which deserves a more generic solution in GenericSetup itself. Perhaps it makes sense to have a special entry in a profile which lists import/export steps to ignore for that profile or to run only for the defining profile.
comment:3 Changed 5 years ago by mj
No, adjusting GS to accomodate hacks in not a good idea. Steps in a base profile should only be run when there is a config file for them, that's the convention.
My patch fixes the hacks to follow the convention. In a future Plone version, the proper solution is to get rid of these hacks. The changes the steps make should be folded into proper GS steps where their changes are stored in the configuration files. It may be that theres still will be changes that cannot be altered through configuration, but I suspect that means the tools in question need to be fixed.
For example, the hacks try to deal with migration issues, these need to be separated out to specific migration code, not setup code. Setting up a new Plone site means it doesn't need to be migrated!

Patch adding a flag file test to the plone_various and plone-final steps