Re: [Zope-CMF] Re: Workflow state change event
On May 15, 2008, at 10:31 PM, Martin Aspeli wrote: Tim Terlegård wrote: I was wondering if it perhaps would make sense to move the ActionSucceededEvent notification after the reindexing of the workflow status has been done? doActionFor(...) calls _invokeWithNotification(...) and the bottom of that method looks like this: def _invokeWithNotification(self, wfs, ob, action, func, args, kw): ... for w in wfs: w.notifySuccess(ob, action, res) notify(ActionSucceededEvent(ob, w, action, res)) if reindex: self._reindexWorkflowVariables(ob) return res In an event handler I would like to use the catalog and search for published objects, but it's not possible because the catalog is updated after the event handler is triggered. That shouldn't matter, though - you get the object as part of the event, no need to search for it. The grandparent of the object is doing a catalog search, so the object that currently got a new workflow state isn't found. The whole use case: siteroot - folderA - docB I have an 'is_empty' index that is based on catalog searches. When folderA doesn't contain any published objects it's considered empty. When workflow is changed on object docB, going from visible to published, I need to reindex the object, and also the parent and the grandparent etc. So when the state change event handler for docB calls folderA.reindexObject(idxs=['is_empty']) it will not find docB because the catalog does not reflect the state change yet. /Tim___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] CMF Tests: 9 OK
Summary of messages to the cmf-tests list. Period Thu May 15 11:00:00 2008 UTC to Fri May 16 11:00:00 2008 UTC. There were 9 messages: 9 from CMF Tests. Tests passed OK --- Subject: OK : CMF-1.6 Zope-2.8 Python-2.3.6 : Linux From: CMF Tests Date: Thu May 15 21:47:04 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008777.html Subject: OK : CMF-1.6 Zope-2.9 Python-2.4.4 : Linux From: CMF Tests Date: Thu May 15 21:48:34 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008778.html Subject: OK : CMF-2.0 Zope-2.9 Python-2.4.4 : Linux From: CMF Tests Date: Thu May 15 21:50:04 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008779.html Subject: OK : CMF-2.0 Zope-2.10 Python-2.4.4 : Linux From: CMF Tests Date: Thu May 15 21:51:34 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008780.html Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.4 : Linux From: CMF Tests Date: Thu May 15 21:53:04 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008781.html Subject: OK : CMF-2.1 Zope-2.11 Python-2.4.4 : Linux From: CMF Tests Date: Thu May 15 21:54:35 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008782.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.4 : Linux From: CMF Tests Date: Thu May 15 21:56:05 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008783.html Subject: OK : CMF-trunk Zope-2.11 Python-2.4.4 : Linux From: CMF Tests Date: Thu May 15 21:57:35 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008784.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Tests Date: Thu May 15 21:59:05 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-May/008785.html ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: Workflow state change event
Tim Terlegård wrote: On May 15, 2008, at 10:31 PM, Martin Aspeli wrote: Tim Terlegård wrote: I was wondering if it perhaps would make sense to move the ActionSucceededEvent notification after the reindexing of the workflow status has been done? doActionFor(...) calls _invokeWithNotification(...) and the bottom of that method looks like this: def _invokeWithNotification(self, wfs, ob, action, func, args, kw): ... for w in wfs: w.notifySuccess(ob, action, res) notify(ActionSucceededEvent(ob, w, action, res)) if reindex: self._reindexWorkflowVariables(ob) return res In an event handler I would like to use the catalog and search for published objects, but it's not possible because the catalog is updated after the event handler is triggered. That shouldn't matter, though - you get the object as part of the event, no need to search for it. The grandparent of the object is doing a catalog search, so the object that currently got a new workflow state isn't found. The whole use case: siteroot - folderA - docB I have an 'is_empty' index that is based on catalog searches. When folderA doesn't contain any published objects it's considered empty. When workflow is changed on object docB, going from visible to published, I need to reindex the object, and also the parent and the grandparent etc. So when the state change event handler for docB calls folderA.reindexObject(idxs=['is_empty']) it will not find docB because the catalog does not reflect the state change yet. Reindex the object in your event handler where you reindex the parents. Laurence ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Multiple GS profiles per product
Hi,
Some observations here with a few questions sprinkled through.
For Plone we at Zest Software made eXtremeManagement (affectionately
called xm), a project management tool. See
http://plone.org/products/extreme-management-tool
For upgrading from Plone 2.5 to 3.0 I made an upgrade profile:
basically just a regular extension profile that is not meant to be run
directly from the portal_quickinstaller or portal_setup but that is
only hooked up to an upgrade step like this:
def from_plone25_to_30(context):
context.runAllImportStepsFromProfile(
'profile-Products.eXtremeManagement:eXtremeManagement-30-types',
purge_old=False)
It removes some actions from some portal types, which seemed handy to
do in a GS profile instead of manually coding some python. Works fine
actually. This is on Plone 3.0 with CMFQuickInstaller 2.0.4.
Note that for GS upgrade steps you do not really need upgrade
profiles. That was just my understanding/expectation of how to do
upgrade steps at the time.
But: along comes Plone 3.1.1 with CMFQuickInstaller 2.1.4. This has
slightly different handling of GS profiles. In this case when
visiting the portal_quickinstaller in the ZMI it does not seem to care
much for the Extensions/Install.py, it finds the two profiles (the
upgrade profile and the default profile) and picks the first one it
finds and print its name in the list of installed/installable
products. So the QI now gives eXtremeManagement the dopey title of
eXtremeManagement types fix for Plone 3.0, which is the title of the
upgrade profile.
Question 1: can I influence which profile is picked here? Should we
add some code to the QuickInstaller.getInstallProfile(s) methods to
for instance prefer a profile with a name like productname:default?
For reference, this is info from the two profiles I now have:
[{'description': u'eXtremeManagement types actions fix for Plone 3.0.',
'for': InterfaceClass Products.CMFPlone.interfaces.siteroot.IPloneSiteRoot,
'id': u'Products.eXtremeManagement:eXtremeManagement-30-types',
'path':
u'/home/maurits/buildout/test/products/eXtremeManagement/profiles/30',
'product': 'Products.eXtremeManagement',
'title': u'eXtremeManagement types fix for Plone 3.0',
'type': 2,
'version': '1.5.2'},
{'description': 'Profile for Extreme Management',
'for': InterfaceClass Products.CMFPlone.interfaces.siteroot.IPloneSiteRoot,
'id': 'eXtremeManagement:default',
'path': 'profiles/default',
'product': 'eXtremeManagement',
'title': 'Extreme Management',
'type': 2,
'version': '1.5.2'}]
The first one is the upgrade profile, only meant to be used via the
Upgrades tab in portal_setup. The second one is the default profile
that I want to have available in the quick installer.
Now, I tested with eXtremeManagement 1.5.2, the latest stable release,
in case anyone wants to try it out (remember to add a Poi 1.1 bundle
too). That release also has Extensions/(App)Install.py files. I
moved those out of the way and restarted. On Plone 3.0 everything
seems to go fine: the name in quick installer is 'Extreme Management'
and installing it does everything it needs to do, using the default
profile. This is because the upgrade profile is not found, due to a
slightly different implementation of the getInstallProfile method.
Now, on Plone 3.1.1 (QI 2.1.4) with a fresh zodb the QI lists that
strange name of the upgrade profile instead of the name of the default
profile. And indeed when installing it only that upgrade profile is
executed, not the default profile.
Question 2: I am used to having a profiles directory in a product and
a subdirectory inside it named 'default'. eXtremeManagement is the
only product I know that has a second profile next to it. Are others
using more than one profile? Well, CMFPlone does a few things here.
Question 3: Should we encourage programmers to only use one profile,
presumably simply in a directory named 'profile' by default?
In the case of eXtremeManagement, the day is saved because it still
has an Extensions/Install.py. That is the installer that is actually
executed and it has some code to run the correct profile, including a
dependency. The only hickup so far is that with the newer QI the name
of the other profile is listed instead of the default profile.
Meanwhile on trunk (and on the 1.6rc5 I released on the cheese shop
last night) I have removed the upgrade profile as I do not like the
side effects of having two profiles.
Hm, hiding profiles by using
Products.CMFQuickInstallerTool.interfaces.INonInstallable could be an
option too, now that I think of it. Should work.
Reactions are welcome.
--
Maurits van Rees | http://maurits.vanrees.org/
Work | http://zestsoftware.nl/
This is your day, don't let them take it away. [Barlow Girl]
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See
[Zope-CMF] Re: Multiple GS profiles per product
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Maurits van Rees wrote:
Some observations here with a few questions sprinkled through.
For Plone we at Zest Software made eXtremeManagement (affectionately
called xm), a project management tool. See
http://plone.org/products/extreme-management-tool
For upgrading from Plone 2.5 to 3.0 I made an upgrade profile:
basically just a regular extension profile that is not meant to be run
directly from the portal_quickinstaller or portal_setup but that is
only hooked up to an upgrade step like this:
def from_plone25_to_30(context):
context.runAllImportStepsFromProfile(
'profile-Products.eXtremeManagement:eXtremeManagement-30-types',
purge_old=False)
It removes some actions from some portal types, which seemed handy to
do in a GS profile instead of manually coding some python. Works fine
actually. This is on Plone 3.0 with CMFQuickInstaller 2.0.4.
Note that for GS upgrade steps you do not really need upgrade
profiles. That was just my understanding/expectation of how to do
upgrade steps at the time.
Sees reasonable, although I should say that I don't use the upgrade
machinery in GS at all.
But: along comes Plone 3.1.1 with CMFQuickInstaller 2.1.4. This has
slightly different handling of GS profiles. In this case when
visiting the portal_quickinstaller in the ZMI it does not seem to care
much for the Extensions/Install.py, it finds the two profiles (the
upgrade profile and the default profile) and picks the first one it
finds and print its name in the list of installed/installable
products. So the QI now gives eXtremeManagement the dopey title of
eXtremeManagement types fix for Plone 3.0, which is the title of the
upgrade profile.
This is a bug: QI should probably be displaying *all* extension
profiles registered for the site root interface, rather than trying to
bless one per product.
Question 1: can I influence which profile is picked here? Should we
add some code to the QuickInstaller.getInstallProfile(s) methods to
for instance prefer a profile with a name like productname:default?
For reference, this is info from the two profiles I now have:
[{'description': u'eXtremeManagement types actions fix for Plone 3.0.',
'for': InterfaceClass
Products.CMFPlone.interfaces.siteroot.IPloneSiteRoot,
'id': u'Products.eXtremeManagement:eXtremeManagement-30-types',
'path':
u'/home/maurits/buildout/test/products/eXtremeManagement/profiles/30',
'product': 'Products.eXtremeManagement',
'title': u'eXtremeManagement types fix for Plone 3.0',
'type': 2,
'version': '1.5.2'},
{'description': 'Profile for Extreme Management',
'for': InterfaceClass
Products.CMFPlone.interfaces.siteroot.IPloneSiteRoot,
'id': 'eXtremeManagement:default',
'path': 'profiles/default',
'product': 'eXtremeManagement',
'title': 'Extreme Management',
'type': 2,
'version': '1.5.2'}]
The first one is the upgrade profile, only meant to be used via the
Upgrades tab in portal_setup. The second one is the default profile
that I want to have available in the quick installer.
Now, I tested with eXtremeManagement 1.5.2, the latest stable release,
in case anyone wants to try it out (remember to add a Poi 1.1 bundle
too). That release also has Extensions/(App)Install.py files. I
moved those out of the way and restarted. On Plone 3.0 everything
seems to go fine: the name in quick installer is 'Extreme Management'
and installing it does everything it needs to do, using the default
profile. This is because the upgrade profile is not found, due to a
slightly different implementation of the getInstallProfile method.
Now, on Plone 3.1.1 (QI 2.1.4) with a fresh zodb the QI lists that
strange name of the upgrade profile instead of the name of the default
profile. And indeed when installing it only that upgrade profile is
executed, not the default profile.
Proposed changes to QI aren't exactly in scope on this list.
Question 2: I am used to having a profiles directory in a product and
a subdirectory inside it named 'default'. eXtremeManagement is the
only product I know that has a second profile next to it. Are others
using more than one profile? Well, CMFPlone does a few things here.
Yes, I use multiple profiles.
Question 3: Should we encourage programmers to only use one profile,
presumably simply in a directory named 'profile' by default?
No. The name 'default' should *definitely* not be majyk.
In the case of eXtremeManagement, the day is saved because it still
has an Extensions/Install.py. That is the installer that is actually
executed and it has some code to run the correct profile, including a
dependency. The only hickup so far is that with the newer QI the name
of the other profile is listed instead of the default profile.
Meanwhile on trunk (and on the 1.6rc5 I released on the cheese shop
last night) I have removed the
[Zope-CMF] Re: Multiple GS profiles per product
Hi. Maurits van Rees wrote: This is on Plone 3.0 with CMFQuickInstaller 2.0.4. I think you are on the wrong list here. QuickInstaller is a part of Plone and not CMF and should be discussed on plone-dev. I'll give some responses anyways ;) Question 1: can I influence which profile is picked here? Should we add some code to the QuickInstaller.getInstallProfile(s) methods to for instance prefer a profile with a name like productname:default? Picking the first profile from the arbitrarily sorted list of profiles is obviously a shortcoming of QI. The main problem here is that QI uses the product name as a primary key for all its operations and thus can only really handle one installation record for one product. The whole use of extension profiles as installation procedures is a bit of a hack. What should really happen and which I'll do for Plone 4.0 is to remove the support for Extensions/Install.py and give up the one-to-one relationship between products and installation records. What happens in the end is that you apply configurations to a site - that can be as many as you want with extension profiles. I just don't see a way on how to move forward with this without a clear cut. Now, I tested with eXtremeManagement 1.5.2, the latest stable release, in case anyone wants to try it out (remember to add a Poi 1.1 bundle too). That release also has Extensions/(App)Install.py files. I moved those out of the way and restarted. Why did you remove Extensions/Install.py? This one is supposed to take precedence over extensions profiles. In your case having one, which installs the GS profile you want internally should work just fine. Question 2: I am used to having a profiles directory in a product and a subdirectory inside it named 'default'. eXtremeManagement is the only product I know that has a second profile next to it. Are others using more than one profile? Well, CMFPlone does a few things here. Multiple profiles are common. I think I made the profiles/default thingy the default value, when you don't provide one in ZCML, but that's all the magic there is and should be. Question 3: Should we encourage programmers to only use one profile, presumably simply in a directory named 'profile' by default? No. :) In the case of eXtremeManagement, the day is saved because it still has an Extensions/Install.py. That is the installer that is actually executed and it has some code to run the correct profile, including a dependency. The only hickup so far is that with the newer QI the name of the other profile is listed instead of the default profile. That is a bug. I think someone added this code of taking the title from the profile, shortly before the final and I missed to review it properly. We should just revert those changes. If you have an Extensions/Install.py nothing should be read from the profile database. Can you add a ticket for this last issue? Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
