4teamwork / ftw.upgrade

An upgrade control panel and upgrade helpers for plone upgrades.
6 stars 10 forks source link

ftw.upgrade lists upgrade steps for uninstalled products #46

Closed fredvd closed 9 years ago

fredvd commented 10 years ago

I'm testing ftw.upgrade and I noticed that ftw.upgrade lists upgrade steps for addons in @@manage-upgrades that once were installed in the Plone site, but have been uninstalled since. I am maybe confused by the first line in the manage-upgrades view, noting

"This view lists all profiles with at least one upgrade. Profiles which are not yet installed are not listed. Upgrades which are already installed are hidden by default, click on the profile title to show them. "

In this particular case I have a Plone 4.2.7 site where collective.blogging has been installed once, but uninstalled as well.

collective_blogging

collective.blogging is still listed in the portal_quickinstaller contents but its status there is uninstalled.

portal_quickinstaller

And off course collective.blogging is also listed as uninstalled in the Add-on Products section of the Plone Control Panel.

Is this listing of uninstalled a known issue and intentional, or should they be hidden from manage-upgrades view?

lukasgraf commented 10 years ago

I wouldn't say it's intentional, but it's not a use case we took care to support so far.

To my knowledge, uninstallation of products in Plone is a concept that's only really implemented in portal_quickinstaller, but not in Generic Setup.

So I took a look at an uninstalled collective.blogging: portal_setup still reports the installed version for its default profile as 1.2:

(Pdb) profileid = u'collective.blogging:default'
(Pdb) self.portal_setup.getLastVersionForProfile(profileid)
(u'1', u'2')
(Pdb) self.portal_setup.getVersionForProfile(profileid)
u'1.2'
(Pdb) pp self.portal_setup.getProfileInfo(profileid)
{'dependencies': (u'profile-plone.app.jquerytools:default',),
 'description': u'A blogging extension for Plone.',
 'for': <InterfaceClass Products.CMFPlone.interfaces.siteroot.IPloneSiteRoot>,
 'id': u'collective.blogging:default',
 'path': u'/Users/lukasgraf/Plone/buildouts/plone43devel/src/collective.blogging/src/collective/blogging/profiles/default',
 'product': 'collective.blogging',
 'title': u'Blogging',
 'type': 2,
 'version': u'1.2'}

That's currently all ftw.upgrade considers to determine if a profile is installed or not (see gatherer.py:131).

portal_quickinstaller on the other hand is able to determine it has been uninstalled:

(Pdb) portal_quickinstaller.isProductInstalled('collective.blogging')
False

So the check in _is_profile_installed could probably be extended to also query portal_quickinstaller to determine if a profile is installed. But since product != profile, I'll have to look into the details of implementing this.

fredvd commented 10 years ago

Thanks for your feedback! Maybe what could be added in the current listing without too much impact is a warning note next to the profile listing in ftw.upgrade if portal_quickinstaller thinks the add'on is not installed, without limiting or filtering the listing.

One area where ftw.upgrade definetely did help me so far is spotting upgrade steps for Products that I would have expected to be run during normal Plone upgrades, for example Products.TinyMCE. I have a hunch this is because TinyMCE is listed in the HiddenProfiles class in CMFPlone. Too much filtering is not good as well, ftw.upgrade is still a power/admin user tool. afaics ;-)

lukasgraf commented 10 years ago

Yeah, that could certainly be a less invasive option. Probably it should not list them as "proposed" then (and therefore not tick the checkboxes by default). Because one major philosophy behind ftw.upgrade is that you should just be able to visit @@manage-upgrades, hit that button, and it should do The Right Thing [tm].

jone commented 9 years ago

The fix for this problem is available in ftw.upgrade = 1.10.2.