Closed fredvd closed 9 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.
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 ;-)
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].
The fix for this problem is available in ftw.upgrade = 1.10.2
.
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 is still listed in the portal_quickinstaller contents but its status there is uninstalled.
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?