Re: [Zope-CMF] Products.CMFCore release
On Oct 15, 2013, at 9:31 , Harald Friessnegger wrote: > hi jens > > sure, i'll forward port the changes to trunk too. just wanted to wait until > you guys are ok with it. > > normally i'd add Products.CMFCore to the plone cordev buildout to make sure > the new version gets released with plone. > > since the 2.2 branch still has failing tests, the checkout for > Products.CMFCore would get reverted again > https://github.com/plone/buildout.coredev/blob/4.2/checkouts.cfg > > can you take a look at the failing tests? If you run under Python 2.6, which as Yvo pointed out is the supported Python version for CMFCore 2.2, there are no failing tests. jens signature.asc Description: Message signed with OpenPGP using GPGMail ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Products.CMFCore release
On Oct 15, 2013, at 9:09 , yuppie wrote: > Jens Vagelpohl wrote: >> I have created a new release and uploaded it to PyPI. > > -2.2.8 (unreleased) > +2.2.8 (2014-10-15) > > You've got a time machine? Cheers, Yuppie Sorry, typo. I have corrected the file in SVN, but IMHO a new egg won't be required, right? I have also managed to fix the issue with the svn.zope.org mail hook, even though that's not my job anymore. jens signature.asc Description: Message signed with OpenPGP using GPGMail ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Products.CMFCore release
On Oct 14, 2013, at 23:02 , Harald Friessnegger wrote: > hi jens > > i've added a test for my change. > http://svn.zope.org/Products.CMFCore/branches/2.2/Products/CMFCore/tests/test_SkinsTool.py?rev=130325&view=rev > > can you fix the other tests and make a new release? Hi Harald, You have not forward-ported the test to the trunk. Please do so. I have created a new release and uploaded it to PyPI. jens signature.asc Description: Message signed with OpenPGP using GPGMail ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Products.CMFCore release
On Oct 14, 2013, at 13:31, Harald Friessnegger wrote: > hi jens > > you're right about a missing test for the change. > however, the method getSkinNameFromRequest is not involved in any unit-test > by now. > if you wont' add the change to the next release w/o a propert test, i'll add > it. just let me know Please do. That would have caught the trunk mess-up, too, so you can see there's a good reason to test every change in behavior, even if the behavior is not fully tested at present. jens signature.asc Description: Message signed with OpenPGP using GPGMail ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Products.CMFCore release
On Oct 11, 2013, at 19:11 , Tres Seaver wrote: > Signed PGP part > On 10/11/2013 07:34 AM, Harald Friessnegger wrote: > > hi tres > > > > sorry for the last mail. it got sent accidentally before i could > > finish it. > > > > i did a minor change to cmfcore that i'd love to see in the next > > releases of plone. http://dev.plone.org/ticket/10071#comment:8 > > > > could you please review the change and do a new release on pypi? > > > > thanks for your reply and have a nice weekend > > I can't get to this before sometime next week. Hanno and Jens are the > other two release-makers (CC'ed). If it was just about making a release I could have done it quickly. However, I see two issues I don't have time to look into right now: - the change has no unit test - two others are failing: Failure in test test_getActionObject_oldskool_action_deprecated (Products.CMFCore.tests.test_ActionsTool.ActionsToolTests) Traceback (most recent call last): File "/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/case.py", line 331, in run testMethod() File "/usr/local/src/Products.CMFCore-2.2/Products/CMFCore/tests/test_ActionsTool.py", line 94, in test_getActionObject_oldskool_action_deprecated '2.4. Use Action and Action Category objects instead.' in warning) File "/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/case.py", line 424, in assertTrue raise self.failureException(msg) AssertionError: False is not true Failure in test test_getDiff (Products.CMFCore.tests.test_FSPythonScript.CustomizedPythonScriptTests) Traceback (most recent call last): File "/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/case.py", line 331, in run testMethod() File "/usr/local/src/Products.CMFCore-2.2/Products/CMFCore/tests/test_FSPythonScript.py", line 274, in test_getDiff self.assertEqual(list(cps.getDiff()), _DIFF_TEXT.splitlines()) File "/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/case.py", line 515, in assertEqual assertion_func(first, second, msg=msg) File "/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/case.py", line 744, in assertListEqual self.assertSequenceEqual(list1, list2, msg, seq_type=list) File "/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/case.py", line 726, in assertSequenceEqual self.fail(msg) File "/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/case.py", line 412, in fail raise self.failureException(msg) AssertionError: Lists differ: ['--- original', '+++ modified... != ['--- original ', '+++ modifie... First differing element 0: --- original --- original - ['--- original', + ['--- original ', ? + - '+++ modified', + '+++ modified ', ? + '@@ -7,4 +7,4 @@', ' ##parameters=', ' ##title=', ' ##', "-return 'cps'", "+return 'cps -- replaced'"] Ran 235 tests with 2 failures and 0 errors in 0.541 seconds. Tearing down left over layers: Tear down zope.testing.testrunner.layer.UnitTests in 0.000 seconds. Total: 612 tests, 2 failures, 0 errors in 8.445 seconds. jens signature.asc Description: Message signed with OpenPGP using GPGMail ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] CMF security patches in Products.PloneHotfix20121106
Hi all,
I don't recall any information being provided to the CMF developers about CMF
fixes in the most recent Plone Hotfix:
http://plone.org/products/plone-hotfix/releases/20121106
For example, there's a monkey patch to make sure getToolByName only returns
valid tool objects and nothing else, see the attached file.
I'm not sure if there's an oversight of not forwarding this information to us
or if it was determined this fix is not relevant for the CMF. Would any list
member who also works on Plone have an insight?
Thanks!
jens
from Products.CMFCore import utils
try:
from Products.CMFPlone.FactoryTool import FauxArchetypeTool
HAS_FAT = True
except ImportError:
FauxArchetypeTool = None
HAS_FAT = False
from persistent.interfaces import IPersistent
try:
from OFS.interfaces import IItem
except ImportError:
IItem = IPersistent
try:
tool_registry = utils._tool_interface_registry
except AttributeError:
tool_registry = {}
gtbn = utils.getToolByName
def wrapped_getToolByName(obj, name, default=utils._marker):
result = gtbn(obj, name, default)
if IPersistent.providedBy(result) or \
IItem.providedBy(result) or \
name in tool_registry or \
(HAS_FAT and isinstance(result, FauxArchetypeTool)) or \
result is utils._marker or \
result is default:
return result
else:
raise TypeError("Object found is not a portal tool (%s)" % (name,))
return result
utils.getToolByName = wrapped_getToolByName
try:
import Products.CMFPlone.utils
Products.CMFPlone.utils.getToolByName = wrapped_getToolByName
except ImportError:
pass
smime.p7s
Description: S/MIME cryptographic signature
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] 2.3
On Apr 9, 2012, at 23:10 , Charlie Clark wrote: > Am 22.03.2012, 13:28 Uhr, schrieb yuppie : > >> The tools are *local* utilities. Including the ZCML doesn't fix this issue. >> You have to run the upgrade step. > > Should we add a warning to CMFTools.utils.getToolByName? To use getUtility > and the interface instead? Just a general remark: The last time we added a warning to getToolByName it had to be taken back out. The protest was too big. No one wanted to spend the time on all the third-party packages that still use that API. What's worse, back then even the CMF packages were not switched to a pure utility model and would emit these warnings as well. jens ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] 2.3
On Apr 5, 2012, at 17:08 , Charlie Clark wrote: > fuchsia:Products.DCWorkflow charlieclark$ bin/sphinx-build docs tmp > Running Sphinx v1.1.3 > loading pickled environment... done > No builder selected, using default: html > building [html]: targets for 0 source files that are out of date > updating environment: 0 added, 2 changed, 1 removed > Traceback (most recent call last):rkflow > File > "/Users/charlieclark/Sites/CMF/src/Products.DCWorkflow/eggs/Sphinx-1.1.3-py2.6.egg/sphinx/ext/autodoc.py", > line 321, in import_object >__import__(self.modname) > > I'm using the "CMF-level" api-doc to generate the ReST files. <- I suspect > this may be where I'm going wrong but I couldn't see anything in the conf.py > or Makefile that looked liked it would work the proper magic. H Charlie, Before going any further, please stop that usage pattern. The correct way to build those Sphinx docs is: - cd into the docs folder - make sure the sphinx-build script you want to use, which can be either the one inside Products.DCWorkflow or at the toplevel "CMF" package, is in the path and then run "make html": $ cd docs/ $ PATH="../bin:$PATH" make html ... I have a feeling with the way you are doing it you put output and Sphinx build state files for different Sphinx buildouts in one and the same place, which will not work. jens ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] 2.3
On Apr 4, 2012, at 19:54 , Charlie Clark wrote: >> """ >> fuchsia:CMF charlieclark$ bin/sphinx-build src/Products.CMFDefault/docs tmp >> Running Sphinx v1.1.2 >> Exception occurred: >> File "/Users/charlieclark/Sites/CMF/src/Products.CMFDefault/docs/conf.py", >> line 16, in >>import pkginfo >> ImportError: No module named pkginfo >> """ >> sphinx-build no longer works. Or should I be working from CMFDefault >> checkout and building from there? > > See above. Should probably check why documents now can't be generated from > the top-level of the project, although package level is probably saner. This is now fixed. The top-level (CMF package) buildout did not know about the documentation dependency on "pkginfo", only the buildout inside the Products.CMFDefault package did. jens ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] 2.3
On Apr 3, 2012, at 14:55 , Charlie Clark wrote: > I had a go at autogenerating the api documentation but failed miserably - > lots of empty pages got generated because Sphinx had trouble with import > paths. Does anyone know the appropriate incantations for this? I have fixed it by creating a small buildout configuration at the root of the package that will create a working sphinx-build script under bin/ with all the dependencies set up, and by replacing all faulty module references to "CMFDefault" with "Products.CMFDefault". I also cleaned up many Sphinx complaints about bad formatting. jens ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] 2.3
Hi Charlie, On Apr 3, 2012, at 14:55 , Charlie Clark wrote: > Am 03.04.2012, 14:11 Uhr, schrieb yuppie : > >> +1 >> Is CMFDefault/help now obsolete? Could it be deleted? > > I guess so. I'm still working on "tidying" up what can loosely be termed as > the narrative documentation. Still in the clean-up phase but should get this > done this week. > > @ Jens will we be able to point the release to a docs page on Zope.org? *If* there's a working Sphinx documentation set under Products.CMFXXX/doc or Products.CMFXXX/docs I can stitch it into the autogenerated documentation at docs.zope.org. > I had a go at autogenerating the api documentation but failed miserably - > lots of empty pages got generated because Sphinx had trouble with import > paths. Does anyone know the appropriate incantations for this? I can take a look over the next few days. jens ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] 2.3
On Mar 31, 2012, at 17:03 , Charlie Clark wrote: > Am 21.03.2012, 22:58 Uhr, schrieb Jens Vagelpohl : > >> The beta eggs are released now. > > Jens, > > could we have a patch release to include my fallbacks? I'd like to be able to > try the beta with a couple of other sites without adding links to trunk in my > buildouts. Products.CMFCore and Products.CMFDefault are now released as version 2.3.0-beta2 jens ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] 2.3
On Mar 22, 2012, at 13:42 , Charlie Clark wrote: > PS. I've just run tests on trunk and am getting failures in CMFCore: The tests only fail on Python 2.7, they run through fine on 2.6. As such, they're not functional failures but failures dur to changes in behavior between 2.6 and 2.7. In one place a DeprecationWarning is not written to the log, in another diff output has changed slightly. jens ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] 2.3
On Mar 20, 2012, at 23:25 , Jens Vagelpohl wrote: > > On Mar 20, 2012, at 16:14 , Charlie Clark wrote: > >> Hi, >> >> I finally landed my update step for syndication during the PyCon sprints! I >> thought I had a few more browser views to update to using the >> EditSettingsForm but on a quick check of the files it seems that this has >> already been done. Yuppie, I remember that you have commented out some of my >> views (portal configuration and membership, I think) because of the encoding >> problem, did you correct them yourself last year and I was simply looking at >> old source? If that is the case then I think we're good to go with 2.3. > > > If there are no objections I could run through the packages and create 2.3.0 > betas later this week or this coming weekend. The beta eggs are released now. jens ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] 2.3
On Mar 21, 2012, at 15:55 , Charlie Clark wrote: > Am 21.03.2012, 00:36 Uhr, schrieb Tres Seaver : > >> Sounds good. We should review the code for any stuff >> deprecated-and-promised-to-be-remove-in-2.3 before releasing a beta. > > I suppose we could also migrate the old Zope Help docs to "docs" for > Sphinx generation? I know much of the docs are inaccurate and outdated but > this might help expose the worst bits which should then be exorcised or at > least pruned. > > Not sure if this would be for 2.3 but I think that CMFCalendar should be > rolled into CMFDefault. The main reason being that the default profile for > CMFCalendar uses browser views and explicitly requires the CMFDefault skin > layer. You then can't use CMFCalendar if you override the default skin > layer. Plus, CMFCalendar's functionality is extremely limited and > intimately tied to CMFDefault. If we keep piling up tasks that are too big to be tackled in a small amount of time as part of the release process we'll never get anything released. I would classify both these items as "nice to have, but not on the critical path". jens ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] 2.3
On Mar 20, 2012, at 16:14 , Charlie Clark wrote: > Hi, > > I finally landed my update step for syndication during the PyCon sprints! I > thought I had a few more browser views to update to using the > EditSettingsForm but on a quick check of the files it seems that this has > already been done. Yuppie, I remember that you have commented out some of my > views (portal configuration and membership, I think) because of the encoding > problem, did you correct them yourself last year and I was simply looking at > old source? If that is the case then I think we're good to go with 2.3. If there are no objections I could run through the packages and create 2.3.0 betas later this week or this coming weekend. jens ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] tools as utilities
On Sep 12, 2011, at 11:52 , yuppie wrote: > Hi! > > > 5 years ago we started converting CMF tools into local utilities, and we > are still stuck in the middle of that task. > > The problem is that local utilities don't have REQUEST in their > acquisition chain. A few tool methods use self.REQUEST and the plan was > to replace these methods by view code. But that never happened. So these > tools and all tools depending on these tools are still not converted. > > I propose to use 'five.globalrequest' instead of self.REQUEST inside > tools. AFAICS that allows to convert *all* tools into utilities. Hi Yuppie, Why would you want to add a dependency for 3 lines of code? All that package does is register a 1 line event handler. I'd rather do that in the CMF itself. IMHO the "cleaner" way would be to make sure the request object is explicitly passed into any code that needs it. jens ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] cmf-tests - OK: 3, UNKNOWN: 1
On Aug 11, 2011, at 21:10 , Hanno Schlichting wrote: > On Sun, Aug 7, 2011 at 5:13 PM, Jens Vagelpohl wrote: >> After the wrapping, the discussion item has the wrong path. Even though >> "self", the "talkback" object, has the correct path when calling >> getPhysicalPath on it. I can't see anything overly stupid in the >> DiscussionItem code, so there has to be an issue with that Zope >> getPhysicalPath change. Reverting that one change in the current Zope trunk >> fixes the tests. > > Thanks for the thorough analysis! > > I tracked this down to a missing aq_inner call in the new > getPhysicalPath and fixed that. > > The "ValueError: 'Access contents information' not found in inherited > permissions" failures remain, which are next on my list. Thanks for taking the time, Hanno. I wouldn't have been able to figure than one out. jens ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] cmf-tests - OK: 3, UNKNOWN: 1
On Aug 7, 2011, at 07:00 , CMF tests summarizer wrote: > > [1]UNKNOWN FAILED (failures=3, errors=4) : CMF-trunk Zope-trunk > Python-2.6.6 : Linux > https://mail.zope.org/pipermail/cmf-tests/2011-August/015089.html I have tried to pinpoint the reason for some of these test failures. Two of these tests are for the CMF Discussions functionality: Failure in test test_deleteReplies (Products.CMFDefault.tests.test_Discussions.DiscussionTests) Traceback (most recent call last): File "/usr/local/lib/python2.6/unittest.py", line 279, in run testMethod() File "/usr/local/py26/cmf_trunk/src/Products.CMFDefault/Products/CMFDefault/tests/test_Discussions.py", line 301, in test_deleteReplies self.assertEqual(len(ctool), 4) File "/usr/local/lib/python2.6/unittest.py", line 350, in failUnlessEqual (msg or '%r != %r' % (first, second)) AssertionError: 6 != 4 Failure in test test_itemCataloguing (Products.CMFDefault.tests.test_Discussions.DiscussionTests) Traceback (most recent call last): File "/usr/local/lib/python2.6/unittest.py", line 279, in run testMethod() File "/usr/local/py26/cmf_trunk/src/Products.CMFDefault/Products/CMFDefault/tests/test_Discussions.py", line 212, in test_itemCataloguing % reply.getId())) File "/usr/local/lib/python2.6/unittest.py", line 325, in failUnless if not expr: raise self.failureException, msg AssertionError Those tests started failing after the following Zope-checkin: http://svn.zope.org/?rev=122213&view=rev What ends up happening in both cases is discussion replies ending up with a wrong idea about their physical path. Normally, they all should have a physical path that points to the "talkback" discussion container object attached to the original content item that houses the discussion, like so: /path/to/content/talkback/12345 /path/to/content/talkback/12346 /path/to/content/talkback/12347 … All of a sudden a "reply to a reply" thinks it is stored not in the content object's "talkback", but in a new "talkback" attached to the reply the user has replied to: /path/to/content/talkback/12345 /path/to/content/talkback/12345/talkback/12346 /path/to/content/talkback/12345/talkback/12346/talkback/12347 The problem appears in CMFDefault.DiscussionItem.createReply on line 251, where the newly created discussion reply is aqcuisition-wrapped in the talkback object: item = DiscussionItem( id, title=title, description=title ) self._container[id] = item item = item.__of__(self) After the wrapping, the discussion item has the wrong path. Even though "self", the "talkback" object, has the correct path when calling getPhysicalPath on it. I can't see anything overly stupid in the DiscussionItem code, so there has to be an issue with that Zope getPhysicalPath change. Reverting that one change in the current Zope trunk fixes the tests. jens ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.3 plans?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/19/11 13:15 , Laurence Rowe wrote: > Hi, > > What are the CMF 2.3 release plans? If we wanted to consider this for > Plone 4.2 we would need a release fairly soon so we could make the > required changes around member handling. Hi Laurence, I could create a first alpha release for the various packages if that helps. For the first beta a.k.a. trunk branch point I need to know if anyone is working on features that are not on the trunk yet. Please speak up if branching for CMF 2.3 needs to be delayed. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk2tdN8ACgkQRAx5nvEhZLK/zACfQfwYwwrhS6A1cuQYRcFX3Y3+ I2cAn2Xy4adCmKhOxi1/3UhKqIgo6ByV =N2HH -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup: Question on StackOverflow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/9/11 11:18 , Lennart Regebro wrote: > On Sat, Apr 9, 2011 at 10:11, Jens Vagelpohl wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 4/9/11 09:09 , Suresh V. wrote: >>> Please see: >>> >>> http://stackoverflow.com/questions/5603459/genericsetup-what-does-toolset-xml-accomplish-if-toolinit-still-has-to-be-called >>> >>> I could not create a "cmf" tag, so if you can please add that to the >>> tags in the question. >> Not sure what that site is or does, but the only forums regularly >> visited and supported by the CMF developers are this mailing list and >> Launchpad. If you would like to ask a question please use those. > > But there are some Plone people lurking there, and plone is a good > tag. But mailing lists will probably be faster than SO for any kind of > tool that isn't wildly popular. IMHO it's not a metter of how popular a given tool is. It's a matter of where the developers/supporters hang out and what channels they use for accepting questions, bug reports or support requests. For the CMF that means this list or the Launchpad sites for the various components. If there's someone who wants to volunteer monitoring and answering requests on a separate channel, like that website, that's fine. But until that time people should be warned that posting requests somewhere else may not yield any results. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk2gJ1kACgkQRAx5nvEhZLJgRQCdE32TMDT4wUvmUM6jEm/mK1H/ OWYAnRzTuV6BvZV4VePRJ2NFmNh1QxKj =h/BQ -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup: Question on StackOverflow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/9/11 09:09 , Suresh V. wrote: > Please see: > > http://stackoverflow.com/questions/5603459/genericsetup-what-does-toolset-xml-accomplish-if-toolinit-still-has-to-be-called > > I could not create a "cmf" tag, so if you can please add that to the > tags in the question. Not sure what that site is or does, but the only forums regularly visited and supported by the CMF developers are this mailing list and Launchpad. If you would like to ask a question please use those. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk2gFJgACgkQRAx5nvEhZLLKKQCaAkXibYIeDybeH1AxPbI/3tN1 DGkAn20pHJc8TtBWrE2COKxAt2V7vJzM =gSwo -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Versions found on pypi but not in svn tags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/2/11 12:15 , Suresh V. wrote: > How come the following versions are not found in svn tags? > > Products.CMFCore: Versions 2.2.1, 2.2.2, 2.2.3 I have no idea where you are looking, but those tags exist. See http://svn.zope.org/Products.CMFCore/tags/ or http://svn.zope.org/repos/main/Products.CMFCore/tags/. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAk2W+0oACgkQRAx5nvEhZLKGpgCeI5hVINfSQfPaXoveT6dJMqHB eJgAnjRSU4OmUG8R5d+ZfoBxwV+UQG6Q =2NCy -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF Tests: 3 OK, 1 Unknown
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/21/10 13:58 , CMF Tests Summarizer wrote: > Summary of messages to the cmf-tests list. > Period Wed Oct 20 12:00:00 2010 UTC to Thu Oct 21 12:00:00 2010 UTC. > There were 4 messages: 4 from CMF Tests. > > > Unknown > --- > > Subject: UNKNOWN : CMF-trunk Zope-2.12 Python-2.6.5 : Linux > From: CMF Tests > Date: Wed Oct 20 21:56:35 EDT 2010 > URL: http://mail.zope.org/pipermail/cmf-tests/2010-October/013676.html @Laurence: I have a feeling you only tested your recent workflow tool changes under Zope trunk/2.13. The test failure appears under Zope 2.12 and I'm guessing it's because you're pulling tool.zcml into the test setup, where it did not appear before: http://svn.zope.org/Products.CMFCore/trunk/Products/CMFCore/testing.py?rev=117773&sortby=date&view=diff&r1=117773&r2=117772&p1=Products.CMFCore/trunk/Products/CMFCore/testing.py&p2=/Products.CMFCore/trunk/Products/CMFCore/testing.py jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkzALtUACgkQRAx5nvEhZLJn5QCcDDY/me3g2cWhKIQ7t58mKFbU GJUAoK4hpOhFj2YAnC2cO7kOJ06opOyr =vQH7 -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.1 releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/12/10 20:45 , Charlie Clark wrote: > Am 23.09.2010, 12:47 Uhr, schrieb Jens Vagelpohl : > >> Let's talk about 2.2 releases after the bug day then. > > Hi Jens, > > I'd like a 2.2 release to include the fixes to > CMFDefault/browser/content/folder.py > and CMFDefault/browser/skins/ursa.py > > Do I just need to provide you with patches to both those files reflecting > changes from the 2.2 branch? I'm sure you're quite capable of merging those changes into the CMFDefault 2.2 branch and adding new or exercising existing tests, right? I can make releases when you're done. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAky00tIACgkQRAx5nvEhZLKYBQCdHweT/mXanVQ6lrpptHD1qCor /boAn3nKlh7W0NqjKEKuei4qwinKTAh+ =4EmN -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Site syndication form
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/30/10 23:54 , Charlie Clark wrote: > I propose to add Site Syndication Settings to the actions/global and > remove the Properties form from the SyndicationTool. I also think that > synPropertiesForm should be moved to actions/folder and the condition > "folder is object" removed. Oh, and I notice the RSS schema is way out of > date! This is probably the most important thing of all. > > Syndication policies can probably be best handled by a Syndication > Settings form. The ZMI tab will be removed as will the Syndication Reports > tab which I don't intend to implement. That's what log files are for. > > Any objections? Not from me. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkylft0ACgkQRAx5nvEhZLJIqgCgnVO/p5QF2WNQYb0/zsXq9pkA 6PIAn1IrMP7MuaMi5kjmZjzNS8l32en4 =i2HX -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Permalink and portal configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Charlie, > "enable_permalink". Now, while this is easy enough to add both to the > Script and my view and there is support for this in > zpt_generic/main_template with get_permalink, there is actually an > implicit dependency about CMFUid for this function. So, I think this means > we should either add CMFUid to CMFDefault's dependencies or move the > function to the CMFUid extension profile and associated skin layer. Or, > maybe this is like the CMFCalendar stuff? In which case maybe a more > explicit check for the existence of the tool, particularly when wanting to > enable permalinks, would make sense. IMHO any CMFUid-related bits should be in CMFUid only. Certainly CMFDefault should not have any explicit or implicit dependency on CMFUid. > On a slightly related matter: I think we could probably retire the > "Properties" tab from the ZMI for the PortalObject. The same could be done > with some of the Tools and maybe with other tabs such as "Interfaces". Or > would this make a site too dependent upon installed skins? Thoughts? +1 for removing the Properties tabs. There should only be one obvious way to set these values, and that should be in the portal itself and not the ZMI. Besides, IIRC string encoding for edits in the ZMI may end up different than edits from the portal-provided forms. I would leave the Interfaces tab in place for now. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkyhgzIACgkQRAx5nvEhZLIjDgCfad+FAEkoYMnaupnVmI2i+5fA PzMAniYcG7xBConBh3yFdlRuR+QN0vk1 =NpsB -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF dev buildouts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/23/10 12:38 , yuppie wrote: > My goal is to have *one* branch for each CMF version. (Except of CMF > 2.1, which has also a non-buildout branch.) I think we have always a > primary target platform that is used for development (e.g. Zope trunk > for CMF trunk). And some additional supported platforms that are just > used for running tests (e.g. latest Zope 2.12 release for CMF trunk). > AFAICS it is sufficient to have additional cfg files instead of > additional branches for the additional platforms. +1 jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkybcUAACgkQRAx5nvEhZLJdMACdE2lJlPQsSjKqeLVhA3Npgn0x FtQAnRN6o30m86QsqMZ+4tva4DA4SRDa =vMZ5 -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.1 releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/23/10 11:36 , Charlie Clark wrote: > Am 23.09.2010, 10:40 Uhr, schrieb yuppie : > >> Are you sure you want to make these changes in CMF 2.1? Jens is not >> talking about CMF 2.2 or trunk. > > Oh, yeah. Sorry, so caught up in 2.3 awesomeness that I can't see the wood > for the trees! Jens, 2.2 will need a patch release based on my work. The > rest is trunk. Let's talk about 2.2 releases after the bug day then. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkybMCgACgkQRAx5nvEhZLJ8CACgnFW0XqBrDf8hqaC0ODHiPqGr DdkAn2Ag3MU/iC1XUy6uEU/MfiN0l/in =nDom -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Skin consolidation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/23/10 11:39 , Charlie Clark wrote: > Hi, > > Yuppie brought this up at the "Dresden Sprint": does anyone have any > objections to removing the "ursa" and "werebear" skins in 2.3? Both are > just examples of using a BrowserView for the tool lookups and have been > effectively rolled into my new "absolut" skin. No objections from me. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkybKgUACgkQRAx5nvEhZLKImwCeOGM2cquSmk42vVeNJPDj57J1 lQEAn22wBNfgavzIf3JD8n+zSzVIMvNR =jKy2 -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.1 releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/23/10 11:36 , Charlie Clark wrote: > Am 23.09.2010, 10:40 Uhr, schrieb yuppie : > >> Are you sure you want to make these changes in CMF 2.1? Jens is not >> talking about CMF 2.2 or trunk. > > Oh, yeah. Sorry, so caught up in 2.3 awesomeness that I can't see the wood > for the trees! Jens, 2.2 will need a patch release based on my work. The > rest is trunk. OK, I'll go ahead and do the 2.1 releases now. Eric wanted them for Plone. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkybKdAACgkQRAx5nvEhZLK+9ACgiVjOKpjY+W3mMqmGh3aP706C 00wAnA+ZxFJ2hGWBD9YEbMPCxsxJDvDQ =1fcX -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.1 releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/22/10 20:49 , Charlie Clark wrote: > Am 22.09.2010, 14:31 Uhr, schrieb Jens Vagelpohl : > >> Are there any outstanding issues or blockers that need resolving or can >> I go ahead and publish the new releases? > > While I'd like my fixes to CMFDefault/browser/folder.py to be in as soon > as possible, I'm planning to get some more stuff over the next few days. > Can we wait until next Wednesday (bug day?) Is that a bug day? I'm not sure. It's not on my calendar, I must have missed it. Can anyone confirm? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkya858ACgkQRAx5nvEhZLLzMACfcLlMhEuXBgFRFYRV5wpJh4Ii A5EAnAnbURh07rtmKAN9wz1uvy2z/UVu =KQVi -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] CMF 2.1 releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I've lost a little track of release plans for the 2.1 branch, just got back from a vacation. Eric Steele would like a new CMF 2.1 release, and the following eggs have changes: - Products.CMFCalendar - Products.CMFCore - Products.CMFDefault - Products.CMFUid Are there any outstanding issues or blockers that need resolving or can I go ahead and publish the new releases? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkyZ9x8ACgkQRAx5nvEhZLIUUwCglwx18g2yo8CwyqErmiwRSShk zwoAoK0ld8nO+7l1E3HFMvCX+RO/ABLR =6szw -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF vs. CMF.buildout
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Yuppie, > I can't see any additional burden caused by the proposed change. The burden will appear when people are told or get the impression that the package represents the official sanctioned buildout for the CMF as opposed to being a developer convenience :-) It's a matter of communication. Think of someone who doesn't have a clue and sees a package named "CMF". What are they going to think? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkxa3ugACgkQRAx5nvEhZLKjBgCeKwkainxaK89QKDoO0TAGh1wb hqsAn1FsD1JdygyKTH2iBhjI0eQv9WhI =ZuTB -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF vs. CMF.buildout
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/5/10 16:52 , yuppie wrote: > Charlie Clark wrote: >> I'm actively abstaining as while I understand the need to clean things up, >> I'm not sure I understand the whole context (my lack of understanding >> rather than any lack of explanation). CMF is actually empty, isn't it? >> Apart from the history that is. > > And these files might still contain some useful information, but need to > be cleaned up: > > - INSTALL.txt and INSTALL_SVN.txt > > - README.txt Hi Yuppie, You do realize if you're trying to create one "supported" buildout for developers and end users there's a new support burden to shoulder. CMF.buildout was explicitly billed as a developer convenience. What's it going to be for a central CMF package? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkxa0oIACgkQRAx5nvEhZLIyfACgtbWmxNwIEeF/yHOO6+MOFlVj t08An3Yyo1/zSF4Zjm+MNxdEosmeoBPG =atcK -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF Tests: 2 OK, 2 Failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Subject: FAILED (failures=15) : CMF-2.2 Zope-2.12 Python-2.6.5 : Linux > From: CMF Tests > Date: Thu Jul 29 21:57:59 EDT 2010 > URL: http://mail.zope.org/pipermail/cmf-tests/2010-July/013347.html > > Subject: FAILED (failures=15) : CMF-trunk Zope-2.12 Python-2.6.5 : Linux > From: CMF Tests > Date: Thu Jul 29 21:59:59 EDT 2010 > URL: http://mail.zope.org/pipermail/cmf-tests/2010-July/013348.html I am guessing this is due to a simple repr/str representation change in the new DateTime module. I'll look at it. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkxSzuAACgkQRAx5nvEhZLJ+vwCgoCtuPBZKkQ7W6CaMrfqFJ+e5 RZwAn3M74I+2ojQaQobwr8xTVLTKd2W3 =pohJ -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.2 releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/4/10 13:46 , Hanno Schlichting wrote: > On Sun, Jul 4, 2010 at 11:30 AM, Jens Vagelpohl wrote: >> As you may have seen from the checkins, I have done a CMF 2.2 point >> release. Hanno said this would help Plone 4 testing. > > Thanks a lot! > > The new CMF releases should provide compatibility with Zope 2.13.0a1. > So you should also be able to test CMF 2.2 against it :) Stefan Holek has set up the following test combinations at this point: - CMF 2.1/Zope 2.10 - CMF 2.1/Zope 2.11 - CMF 2.2/Zope 2.12 - CMF trunk/Zope 2.12 Stefan, could you set a couple more combinations? IMHO we need: - CMF 2.2/Zope 2.13 - CMF trunk/Zope trunk Thanks! jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkwweDYACgkQRAx5nvEhZLL+oQCgsWth02cuDHS+LPBkKAsdR0Wa 5HcAoKzGAtghzGoqCYp/6I/AnqUVNbdR =m0ec -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] CMF 2.2 releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, As you may have seen from the checkins, I have done a CMF 2.2 point release. Hanno said this would help Plone 4 testing. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkwwVLUACgkQRAx5nvEhZLLTaQCfdyWFFYqxtp6MhBcoIbdDvVek hXgAoJyPXC4WuPaQRJBHF7AJumvKcMd4 =shl2 -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF Tests: 2 OK, 3 Failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/26/10 14:05 , Hanno Schlichting wrote: > This looks like its caused by Jens cleanup in Zope2: > > Error in test test_manage_propertiesForm_allows_adding > (Products.CMFCore.tests.test_ActionInformation.ActionTests) > Traceback (most recent call last): > ... > AttributeError: DummyRequest instance has no attribute 'URL1' This is now fixed. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkv9On0ACgkQRAx5nvEhZLJ4ewCgu1/ODSQ37gq6kA78GMFm/28c K5QAn3GlIy44AaGB2qt6qawJPvKXRP00 =7mH8 -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] More browser views
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/14/10 15:49 , Charlie Clark wrote: >File > "/Users/charlieclark/Sites/cmf-svn/CMF.buildout/trunk/src/Zope2/src/OFS/SimpleItem.py", > > line 45, in > from App.Undo import UndoSupport >File > "/Users/charlieclark/Sites/cmf-svn/CMF.buildout/trunk/src/Zope2/src/App/Undo.py", > > line 29, in > from ZopeUndo.Prefix import Prefix > ImportError: No module named ZopeUndo.Prefix Have you updated your sandbox and re-run bin/buildout? Several items were pulled out of Zope just recently, including ZopeUndo, and they are pulled in as separate eggs during the buildout. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkvFyXEACgkQRAx5nvEhZLK8AwCfTpxrgib36C8SN+8+kmg2vHpP 2wUAn2juI4e1P12HChJ2MJwhh9iDYCBZ =ccNT -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] More browser views
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/14/10 15:43 , Charlie Clark wrote: > Am 09.04.2010, 13:38 Uhr, schrieb Jens Vagelpohl : > >> Needless to say, this is more useful when using a CookieCrumbler as a >> standalone object without a portal. The CMF does not need this, and I >> would even say it only adds confusion and should be removed. > > I'm ready to commit this (now inherits from UniqueObject, PropertyManager > and SimpleItem) but wanted to run the tests to check. Assuming I'm using > the CMF-buildout checkout what's the correct way of doing this? > > bin/test -s Products.CMFCore brings up an error related to ZopeUndo Traceback? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkvFx5sACgkQRAx5nvEhZLKvKwCgubw2WJ8JPIgM1G36MPaX47to dPEAoI6hZyhZGWMiOsK0w+J2/xfEEu1Z =Hdcb -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] More browser views
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/9/10 13:29 , Charlie Clark wrote: > Any idea why CookieCrumbler is a Folder? They can contain objects that can be used as login/logout pages, such as DTML methods or Page Templates. Needless to say, this is more useful when using a CookieCrumbler as a standalone object without a portal. The CMF does not need this, and I would even say it only adds confusion and should be removed. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAku/Ec8ACgkQRAx5nvEhZLK3jACgpjEwDmt+0ZDUq1/flgfN4B8e l2sAoKBp5kOE3vjnsx/6FKnL8VTo/2Rm =Dcy8 -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Portal type actions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/9/10 11:09 , Charlie Clark wrote: > Am 09.04.2010, 10:58 Uhr, schrieb Jens Vagelpohl : > >>> I'll remove it from editToolsActions.dtml then. Can we backport this to >>> CMF 2.2? >> Sure. > > Committed to trunk. For 2.2 do I just make the same change to the branch? Why would you make a different change on the branch? ;-) (This is piddly stuff, you don't need to ask. Only feature changes on the branch require assent.) jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAku+8GYACgkQRAx5nvEhZLIVPACfXCDxKaGapOPDoaL3vaFoq0z3 NZMAn3P/kQTcKEzb7/eGblPbanpTR+W4 =h9lU -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Portal type actions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/9/10 10:54 , Charlie Clark wrote: >> That warning should not show up for type-specific Actions. They are not >> deprecated. This is a bug. > > I'll remove it from editToolsActions.dtml then. Can we backport this to > CMF 2.2? Sure. > In my work on the Absolut skin I noticed that Actions don't enforce icon > expression deprecation as TypeTools do. I don't know if anybody's looked > at this but I'd like to make icons as CSS images. Sounds like a good idea. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAku+7D4ACgkQRAx5nvEhZLLmhQCbBxJ1tvdSeCjYzx0glVQOEQsM wW4AoIYfInf2JgA+hBezlpLCW1XNC7S/ =VEo7 -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] More browser views
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/7/10 13:09 , Charlie Clark wrote: > Hi, > > I'm currently working on a project which will hopefully have no TTW code > so I was hoping to be do without skins - currently I have a my skin on top > of CMFDefault but it is just main_template and some CSS. If I drop the CMF > skins entirely I hit some problems as quite a few forms exist only in the > skins so I'd like to start work on views where required. I suggest keeping > all the views in "browser" but adding some packages such as "content", > "membership" and "workflow". I started work on login and logout but I hit > some problems with CookieCrumbler expecting the login form to have a URL. > What does a view need to provide to work nicely with this? I think I would change the cookie crumbler to expect both: Either a page with an ID that the cookie crumbler can traverse to (which is what it does right now), or an ID for a view that you could traverse to using the "@@" notation. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAku8cMkACgkQRAx5nvEhZLKA2wCfR5xR38bgjTgBIuabsp8osacZ bqcAnA3houfP+WQiB0pe+Hnq4/QHPhh9 =cq8q -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: CMF.buildout/trunk/src/ Don't use http:// externals for CMF externals.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/1/10 12:28 , yuppie wrote: > Jens Vagelpohl wrote: >> On 4/1/10 12:10 , yuppie wrote: >>> IIRC the general policy for the Zope repository is to switch to relative >>> externals after the release of Ubuntu 10.04 LTS, but I guess all people >>> using CMF.buildout have already Subversion>=1.5 available. >> Huh? Since when do we make repository policy based on the release of a >> particular Linux distribution? Where is this policy described? April >> fools joke maybe? > > I might be wrong, but AFAIR this was the last discussion about it on > Zope-dev and nobody objected to this mail: > https://mail.zope.org/pipermail/zope-dev/2009-September/037693.html Like Charlie says, you may be overinterpreting that email. There is no such "general policy" for svn.zope.org. Bringing up that question again certainly doesn't do any harm. I personally have no objections to using relative SVN URLs. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAku0eWcACgkQRAx5nvEhZLLMngCgo/ZHkiLL+gaGkUD4smhELeTS shIAoI8jkrQAigHGzmTxkMy+HKKb3qVq =ET7G -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: CMF.buildout/trunk/src/ Don't use http:// externals for CMF externals.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/1/10 12:10 , yuppie wrote: > IIRC the general policy for the Zope repository is to switch to relative > externals after the release of Ubuntu 10.04 LTS, but I guess all people > using CMF.buildout have already Subversion >=1.5 available. Huh? Since when do we make repository policy based on the release of a particular Linux distribution? Where is this policy described? April fools joke maybe? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAku0coEACgkQRAx5nvEhZLITsACfQObUJti5M7Kg5AEVUqLg9lI8 YkAAnjPpRYT+yxCS6agouZyUPcR4Al+q =dljU -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF Tests: 3 OK, 1 Failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/31/10 22:07 , Tres Seaver wrote: > Jens Vagelpohl wrote: >> On 3/31/10 20:33 , Tres Seaver wrote: >>> I also don't know why the 'instance' and 'i18n*' parts are configured in >>> these buildouts -- does somebody have a memory of why, or a reason to >>> keep them? >> The "instance" part is a pure convenience to quickly fire up an instance >> if I need to look at something in the ZMI while doing development. If >> there's no pressing reason to remove it I'd really like to keep it. > > I can see leaving that alone for the trunk-on-trunk buildout: do you > need it for the buildouts used to test against other Zope versions? > The extra clutter and build time seems untidy to me. I'm surprised that you want to remove it. I use it for all buildout combinations. How do you start an instance while doing work on CMF proper? Or do you never need any ZMI access or test portal instances? Do you manually create a separate buildout extending CMF.buildout? IMHO that would be a needless obstancle as opposed to keeping the "instance" part. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkuzsGoACgkQRAx5nvEhZLJSDQCfV6Gue1BBSzQwrj0qd41ecAJ3 1pkAoKzOzmnYUxX6D6h6HnvFYahnVm+6 =3lsZ -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF Tests: 3 OK, 1 Failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/31/10 20:33 , Tres Seaver wrote: > I also don't know why the 'instance' and 'i18n*' parts are configured in > these buildouts -- does somebody have a memory of why, or a reason to > keep them? The "instance" part is a pure convenience to quickly fire up an instance if I need to look at something in the ZMI while doing development. If there's no pressing reason to remove it I'd really like to keep it. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkuzpC8ACgkQRAx5nvEhZLIQqgCbBHzB46qtTkc+MUpK0Wu8OoOM mM0Anjpp3i/yfLNEeLJoNmkq2R1KZ9Kp =RF/w -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Zope2.12.3 zexp import error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/9/10 22:23 , Charlie Clark wrote: > Am 09.02.2010, 13:46 Uhr, schrieb Jens Vagelpohl : > >> Your event handler "handle_new_masterpage" should be rewritten to look >> if the object it wants to instantiate already exists. If it exists it >> should obviously not try to instantiate it again. > > Hiya Jens, > > the handlers were written to use IObjectAddedEvent as some things in the > Zope2 world can't happen until an object has somewhere to be or more > pertinently this is the most common pattern. Adding the check is easy > enough but I'm interested in the general pattern here: should we be > looking at working with (and notifying) ObjectCreatedEvents? Or should > this check become standard? Hi Charlie, Checking to see if an object you are trying to instantiate already exists is simply common sense. Everyone who writes handlers for IObjectAdded must remember that the event is not just called when a brand new instance is created, but also when an existing instance is cut/copied and pasted, and when the Zope import machinery is used. In those cases a clash is virtually guaranteed if your event handler tries to blindly add another persistent object that is already part of the copied or imported instance. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAktx1egACgkQRAx5nvEhZLKLPACeJV7Sgpd3mAqeotEUQYZbHQfs 7UkAn37q0VpUgQlFgt0jAMN29BOJO6/r =/Y9l -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Zope2.12.3 zexp import error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/9/10 13:27 , thomas.dingel...@camao.de wrote: > Module Products.camaoCms.container.masterpage, line 59, in > handle_new_masterpage > Module OFS.ObjectManager, line 332, in _setObject > Module Products.CMFCore.PortalFolder, line 313, in _checkId > Module OFS.ObjectManager, line 116, in checkValidId > BadRequest: The id "de-DE" is invalid - it is already in use. > > Anyone out there who has a solution or a hint how to fix this problem? Your event handler "handle_new_masterpage" should be rewritten to look if the object it wants to instantiate already exists. If it exists it should obviously not try to instantiate it again. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAktxWRkACgkQRAx5nvEhZLJC0QCgqfTl6HOpgOCtJc1yNwKFRGZi aCIAoK1dEMlaiW8fCL+o0JSsf60L7ltb =CsZU -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] GenericSetup release?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I noticed that the last release, 1.5.0b1, is over 3 months old. Would anyone mind if I created a 1.5.0-final release? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAks8lF8ACgkQRAx5nvEhZLL2ZACfechr9IQECgcYYoYALWwepdXf goAAni9uVAYalzpdgfh8QXOay5EY+aL/ =rH3i -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup and PluggableAuthService
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: > What you want is probably something like this: > > from zope.component.interfaces import ComponentLookupError > from zope.component.interfaces import IComponentRegistry > from zope.location.interfaces import IPossibleSite > > def importComponentRegistry(context): > """Import local components. > """ > # context is the portal_setup tool > # getSite is GS API to get the parent > site = context.getSite() > sm = None > if IPossibleSite.providedBy(site): > # All object managers are an IPossibleSite, but this > # defines the getSiteManager method to be available > try: > sm = site.getSiteManager() > except ComponentLookupError: > sm = None This works like a treat and I used it for import and export. Afterwards I needed to adjust the component import/export test harness a lttle bit so the call to "site.getSiteManager" would not blow up because the site in those tests is a PersistentComponents instance itself. Now I can use all functions in the ZMI, including snapshots, for a PluggableAuthService. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAks8klcACgkQRAx5nvEhZLIoggCgsa4dX3RxALxrC6TpHfm1pPsx bUUAniHJlrSWNMMleUb2ShDzvRFVWESD =UWLN -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup and PluggableAuthService
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: > Hanno Schlichting wrote: >> And then adjust exportComponentRegistry in a similar way. This is >> untested code :) > > Why would a PAS plugin do such a thing? PAS doesn't expect (or want) > any local / persistent component registry. This issue (steps showing up > in inappropriate profiles) was the reason for the step registries being > part of a profile, and why I argued (unsuccessfully) against their > deprecation way back when: I would have preferred fixing whatever > issues existesd, over using a "global" stop registry. That particular question, why the PAS import/export routine would try to run those CMF steps, was exactly what I thought when I tried it all out. I do remember that GS design discussion vaguely but never paid much attention because I never used GS "in anger" and outside of the CMF. It's not my goal to reopen that argument, but I'm left with the impression that at least from the perspective of someone who uses the setuptool ZMI to explore and use GS there are some expectation mismatches and usability problems. Once you recognize the design decision you can at least explain the behavior. I'll continue down the path of trying to make the steps themselves more resilient so I get somewhere. At some later date it may be useful to review the current behavior. I feel some decisions may have been taken with a too-narrow focus (CMF only) because very few people use GS outside of the CMF or Plone. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAks8g3UACgkQRAx5nvEhZLKxBQCeKGBzWK/PO1Auo5DjsuLORkqm VWIAn0r8IIjsQoEre4WNE+lGZBwBm6re =vqt/ -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup and PluggableAuthService
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: > On 2009-12-30 16:19, Jens Vagelpohl wrote: >> However, even that >> registration by interface for profiles isn't considered in the ZMI in >> the base profile or extension profile select lists that show up on the >> Profiles and Import ZMI tabs. > > That's probably a bug that should be fixed. Is there a ticket for that > in launchpad? https://bugs.launchpad.net/zope-cmf/+bug/501668 jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAks7eBsACgkQRAx5nvEhZLJRKQCeJO9cW2V9NZDW86WMz5Io9brf rMEAn1x4j5oDpYF0AN7uSmn914nknzEP =hpgx -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup and PluggableAuthService
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: > On 2009-12-30 15:35, Jens Vagelpohl wrote: >> The reason I thought this list of steps may (should?) change is that for >> example the PluggableAuthService profiles (both of which are BASE >> profiles) explicitly define what steps they provide with an >> import_steps.xml and export_steps.xml file. My assumption was that if >> you have one of the PAS profiles set as the baseline profile, and then >> select "Current base profile" on the Import tab, then the list of steps >> would reflect what the PAS profile import_steps.xml contains. > > I am wondering if the CMFCore import/export steps are registered for > Interface instead of ISiteRoot? You should only see steps that are > registered for the current context, and since a PAS user folder is not > an ISiteRoot the CMF import and export steps should not show up or be run. Looking at the code it appears steps (import and export) are not registered for interfaces. Only profiles are. However, even that registration by interface for profiles isn't considered in the ZMI in the base profile or extension profile select lists that show up on the Profiles and Import ZMI tabs. I have now gotten things to work by going through all import handlers in CMFCore and making sure they don't do anything if their handled content does not exist. Some already failed gracefully, others didn't. Looks like a simple oversight and lack of usage outside of the CMF. Another item that does not work is the Snapshot tab and the export of all steps when inside the PluggableAuthService instance. The failure looks like this: Traceback (innermost last): Module ZPublisher.Publish, line 127, in publish Module ZPublisher.mapply, line 77, in mapply Module ZPublisher.Publish, line 47, in call_object Module Products.GenericSetup.tool, line 586, in manage_exportAllSteps Module Products.GenericSetup.tool, line 351, in runAllExportSteps Module Products.GenericSetup.tool, line 1022, in _doRunExportSteps Module Products.GenericSetup.components, line 530, in exportComponentRegistry Module Products.GenericSetup.utils, line 495, in _exportBody Module Products.GenericSetup.components, line 63, in _exportNode Module Products.GenericSetup.components, line 373, in _extractAdapters Module Products.GenericSetup.utils, line 72, in _getDottedName ValueError: Cannot compute dotted name: In the debugger I see that the object in question is a absolute_url adapter residing in the base component registry in the site root. IMHO the components exporter should not look at the base registry at all, only a local registry if one exists in the folder the tool sits in. Correct? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAks7b3MACgkQRAx5nvEhZLLoVACgr9wNv68luLJ0OPt/Sg5tLprN FPYAmweOR7V3LpPng+7vUiEgMPNCodo/ =6MvA -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup and PluggableAuthService
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: > On 2009-12-30 15:06, Jens Vagelpohl wrote: >> Separate note: On the "Import" tab I see a dropdown of extension >> profiles to select. Changing the selection here never affects the list >> of available import steps, though. This is confusing to me, but I may >> have misunderstood the purpose. > > The list of import steps is global and not per-profile, so that is > expected behaviour. For most profiles only a few import steps do any > real work, but the setup tool has no way to detect that so all steps are > always listed. The reason I thought this list of steps may (should?) change is that for example the PluggableAuthService profiles (both of which are BASE profiles) explicitly define what steps they provide with an import_steps.xml and export_steps.xml file. My assumption was that if you have one of the PAS profiles set as the baseline profile, and then select "Current base profile" on the Import tab, then the list of steps would reflect what the PAS profile import_steps.xml contains. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAks7ZTIACgkQRAx5nvEhZLJzJACeJlR4VP+XWDlDPR3Nt0FAXeIv 3icAn2nkWOVV+vou8H7xDE7EDB89xfUv =0wEG -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] GenericSetup and PluggableAuthService
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I'm working on a PAS plugin and want to ensure it has GenericSetup support like the standard plugins. I'm running into issues trying to use GenericSetup in a manual test, though. With a setup_tool inside the PluggableAuthService instance I can create an export tarball when I select the "Contents: Export the PAS' registry and plugins" step explicitly and click "Export selected steps". However, I can't find a way to re-import this tarball. Separate note: On the "Import" tab I see a dropdown of extension profiles to select. Changing the selection here never affects the list of available import steps, though. This is confusing to me, but I may have misunderstood the purpose. So I am selecting my tarball into the upload field and click "Import uploaded tarball", which presents this traceback: Traceback (innermost last): Module ZPublisher.Publish, line 127, in publish Module ZPublisher.mapply, line 77, in mapply Module ZPublisher.Publish, line 47, in call_object Module Products.GenericSetup.tool, line 558, in manage_importTarball Module Products.GenericSetup.tool, line 331, in runAllImportStepsFromProfile Module Products.GenericSetup.tool, line 1085, in _runImportStepsFromContext Module Products.GenericSetup.tool, line 999, in _doRunImportStep - __traceback_info__: catalog Module Products.CMFCore.exportimport.catalog, line 28, in importCatalogTool Module Products.CMFCore.utils, line 123, in getToolByName AttributeError: portal_catalog It is obviously trying to run an import step that's not suitable outside of a CMF site. This leaves a few questions: - Is my expectation that the tool work outside of a CMF site reasonable? - If it is, then why do I always see the full set of all registered steps from all profiles on the Import/Export ZMI tabs regardless of chosen base or extension profile? - Why is the tarball import trying to run all steps without considering the selected profile? - Are import/export steps that don't guard against missing content (such as the "catalog" step that blows up when there is no portal_catalog) just faulty and should fail silently instead? Any help appreciated :-) jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAks7Xl0ACgkQRAx5nvEhZLIRqwCfULJmMKsYAzU9vey+dmNg+zBN BhIAoI8UqhW3sfV13pv24i10D0b+z0jC =u+5W -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [Checkins] SVN: Products.CMFCore/trunk/ - fixed Zope 2.12 compatibility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: > On Sun, Dec 27, 2009 at 8:31 PM, Jens Vagelpohl wrote: >> Please keep release scheduling in mind. I had announced a release date >> for CMF 2.2.0-final about a week from now. Andreas cannot possible throw >> out Zope 2 2.12.3-final by that time. We would need to postpone CMF >> 2.2.0-final for any of this to happen. > > Ok. Here's a deal: I made CMF trunk and the 2.2 branch use > five.formlib in favor of Products.Five.formlib, including a fallback > to Products.Five. So at this point everything works with both Zope > 2.12 / 2.13. > > You can now go ahead and make a CMF 2.2 final release whenever you like. OK, so as far as I am concerned we are back on track for CMF 2.2.0-final release next week, unless there are other concerns. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAks7H8wACgkQRAx5nvEhZLIVBQCfbHDllwbie8o6+XYmaAUWwK/i 0XQAoJ5+qB4UqNulmu6u0juwz2mEqph4 =w2Mp -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [Checkins] SVN: Products.CMFCore/trunk/ - fixed Zope 2.12 compatibility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: > On a related note, if I'm going to backport the five.formlib > extraction to 2.12, it would it be ok to depend on a 2.12.3 release > for CMF 2.2 with this stuff in it, right? Please keep release scheduling in mind. I had announced a release date for CMF 2.2.0-final about a week from now. Andreas cannot possible throw out Zope 2 2.12.3-final by that time. We would need to postpone CMF 2.2.0-final for any of this to happen. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAks3th0ACgkQRAx5nvEhZLJrfACgjT2GCabn5Ezrn+Ih3m54rHZG t6QAn2Ed5prLc0tUGThEiOn4VVzFgo2Z =fWCN -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF Tests: 3 OK, 1 Unknown
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 CMF Tests Summarizer wrote: > Summary of messages to the cmf-tests list. > Period Thu Dec 17 12:00:00 2009 UTC to Fri Dec 18 12:00:00 2009 UTC. > There were 4 messages: 4 from CMF Tests. > > > Unknown > --- > > Subject: UNKNOWN : CMF-trunk Zope-trunk Python-2.6.4 : Linux > From: CMF Tests > Date: Thu Dec 17 21:02:35 EST 2009 > URL: http://mail.zope.org/pipermail/cmf-tests/2009-December/012382.html @Hanno: These are all import problems, probably connected to your current reshuffling of Zope2 dependencies? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAksreBMACgkQRAx5nvEhZLJvAQCgjYTK/l7NK37at5A/Rjih6r/v U8UAn3WxHGivxmpVmCK0LXHKJ7CUbXEH =/DDY -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] CMF 2.2: upgrade steps
On Dec 9, 2009, at 16:32 , yuppie wrote: > I think it would be good to catch in .to22.check_dcmi_metadata *all* > tools that don't have a 'DCMI' attribute. > > CMF 2.0 and 2.1 did not add '_DCMI' in __init__, I just changed that > before the 2.2 beta. If the old migration code was never triggered the > tools are broken without an upgrade step. The check has been changed. >> All scripts in CMFDefault were obsolete, those I deleted. The script in >> CMFCore is a good candidate for upgrade steps, but I am thinking the step >> should be in CMFDefault, correct? > > Yes. All migration code is now linked to the default profile of > CMFDefault. At the moment I have no idea how to make these upgrade steps > available for people who use e.g. only CMFCore. I made them all into CMFDefault upgrade steps and removed the script in CMFCore. jens smime.p7s Description: S/MIME cryptographic signature ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.2.0-beta reminder
Hi Charlie, > Is there an easy to way to setup a project buildout based > on CMF? I've tried various combinations of the following: > > [buildout] > extends = > http://svn.zope.org/*checkout*/CMF.buildout/branches/zope212-cmf22/buildout.cfg > versions = versions > parts = parts > eggs = eggs > > But there must be something in the URL that causes buildout to choke on an > IOError. Other URLs work fine so maybe it's just the > extends = src/Zope2/versions.cfg For the "extends = src/Zope2/versions.cfg" line to work you must have a Zope 2 checkout in src/Zope2 *before* you attempt run the buildout. CMF.buildout does this using svn:externals, so you may not have those in your own buildout. I would never extend those convenience buildouts for my own projects, there is no maintenance or correctness guarantee on them. They are just a developer convenience, not a blueprint for a production buildout. I would either just use it as inspiration for a buildout configuration done from scratch, or copy it and then adjust as necessary. By the way, don't use URLs that use the ViewVC "checkout" magic. That's an unnecessary detour when you can use straight HTTP repository access. The URL above would translate to this direct URL: http://svn.zope.org/repos/main/CMF.buildout/branches/zope212-cmf22/buildout.cfg jens smime.p7s Description: S/MIME cryptographic signature ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] CMF 2.2: upgrade steps
Hello, > - The MetadataTool has write-on-read migration code in _get_DCMI. That > should be converted into two migration steps: One from CMF 1.6 to CMF > 2.0 and one from 2.1 to 2.2. This is done on the trunk and the 2.2 branch. > - The upgrade scripts in CMFCore/Extensions and CMFDefault/Extensions > should be converted to upgrade steps. All scripts in CMFDefault were obsolete, those I deleted. The script in CMFCore is a good candidate for upgrade steps, but I am thinking the step should be in CMFDefault, correct? > - An upgrade step for adding the new singlestate_workflow should be written. This is done on the trunk and the 2.2 branch. jens smime.p7s Description: S/MIME cryptographic signature ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.2.0-beta reminder
On Dec 1, 2009, at 07:52 , Jens Vagelpohl wrote: > Reminder: After this week (probably this coming Sunday) I plan on doing the > first CMF 2.2 beta, and creating the 2.2 release branch. All done now: - release branches for the 2.2 release series are cut - the 2.2.0 beta release is tagged and published on PyPI - the convenience buildout branch[1] now uses the new CMF 2.2 branch The trunk (-> CMF 2.3) is free for new features. Please test the beta and provide feedback through Launchpad[2] or here. I would suggest a final release, provided there are no serious issues, about a month from now. jens [1] http://svn.zope.org/CMF.buildout/branches/zope212-cmf22/ [2] https://bugs.launchpad.net/zope-cmf/+bugs smime.p7s Description: S/MIME cryptographic signature ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] CMF 2.2.0-beta reminder
Reminder: After this week (probably this coming Sunday) I plan on doing the first CMF 2.2 beta, and creating the 2.2 release branch. jens ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF and Zope trunk
Hi Charlie, > 1) How do I tie my buildout to 3.9.0? > 2) Should we be updating for the change in CMF? The buildout ties it by extending the versions.cfg file from the Zope 2 trunk. That versions file contains these overrides: zope.app.publisher = 3.9.0 zope.container = 3.9.0 zope.publisher = 3.9.0 zope.site = 3.6.2 # XXX 3.6.3 breaks for us Is your buildout using the Zope2 versions.cfg like CMF.buildout is? jens ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.2 release?
On Nov 6, 2009, at 20:16 , Tres Seaver wrote: > Eric Steele wrote: > >> Jens, could I possibly talk you into releasing an alpha (or even dev?) >> egg in the next week? After showing off Plone 4 at our conference, I'm >> getting a flood of "when can I get an alpha?" requests daily. > > - -sys.maxint to releasing any -dev eggs at all, ever, for any reason. If > you need that, you should be using something like infrae.subversion. > > I think we are in fine shape to release an alpha, though. With Hanno's fix for https://bugs.launchpad.net/zope-cmf/+bug/397795 I have now tagged version 2.2.0-alpha of CMFCalendar, CMFCore, CMFDefault, CMFTopic, CMFUid and DCWorkflow and pushed the eggs to PyPI. Since this is an alpha I have not yet created a 2.2 branch for those packages, this will happen with the first beta release. Eric has indicated that his Plone 4-schedule looks like this right now: - first alpha Monday, November 16 - two more alphas at 2 and 4 weeks after November 16, respectively The beta schedule is not clear, but I would suggest our own CMF betas for the first December weekend, like Friday, December 4. If anyone does not agree, please speak up. These 3 weeks should provide enough time for testing. Thanks everyone for their hard work! jens smime.p7s Description: S/MIME cryptographic signature ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.2 release?
On Nov 10, 2009, at 20:07 , Charlie Clark wrote: I merged my branch in my local trunk. I spotted the path changes and made them but I'm still getting the following error: VocabularyRegistryError: unknown vocabulary: u'cmf.contents delta vocabulary' As a result I didn't commit my changes to trunk. Did you see the changes I committed into the branch a couple days ago which solved that exact issue? jens smime.p7s Description: S/MIME cryptographic signature ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.2 release?
On Nov 3, 2009, at 13:24 , Charlie Clark wrote: Worked with Eric on my formlib for folders and fixing https://bugs.launchpad.net/zope-cmf/+bug/308947 I can't commit my formlib for folders because the browser tests fail due to a utility lookup. Something must have changed in the browser test framework since the summer so I hope this is easy to fix. Does anyone have an idea what might have changed? My existing browser tests are based on the other formlib ones and are independent of the changes I made. I have committed some changes that make all tests pass on the branch now: http://svn.zope.org/?rev=105535&view=rev @Charlie: Your wording is unclear, did you have changes in your local sandbox that were mot committed to the branch? Or were you confusing "committing" and "merging to trunk"? @all: I'd like to get this merged before the alpha on Friday, so if anyone wants to take a look at the changes please do. Unfortunately it's currently hard to distinguish the branch changes from other trunk changes that have been merged into the branch. I will have to merge all trunk changes onto the branch once more before merging the "real" changes onto the trunk. :-( jens smime.p7s Description: S/MIME cryptographic signature ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.2 release?
Hi Eric, Jens, could I possibly talk you into releasing an alpha (or even dev?) egg in the next week? After showing off Plone 4 at our conference, I'm getting a flood of "when can I get an alpha?" requests daily. I'll be happy to do an alpha this coming Friday. I'd do it earlier, but I'm traveling from Monday through Thursday. To keep the ball rolling I would like to set a specific beta schedule at the same time. @Eric: What is your alpha/beta schedule so I can make sure we stay a step ahead? jens smime.p7s Description: S/MIME cryptographic signature ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.2 release?
On Oct 30, 2009, at 14:30 , Charlie Clark wrote: Am 30.10.2009, 14:27 Uhr, schrieb Eric Steele : Is anyone still willing to sprint on CMF 2.2 at the Plone conference? I don't think I've managed to meet any of you yet. I'd like to make sure a sprint gets announced tomorrow if we can actually make it happen. Yes, I'm going to work on my stuff - some people I've bumped into seem to be interested as well. I don't know who else (of the CMF lot) is here but Jens is unfortunately ill. Right, I could not make it after all. I don't know who is there from the "usual CMF gang" apart from Charlie. Maybe Yvo (which would be very helpful)? jens smime.p7s Description: S/MIME cryptographic signature ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.2 release?
On Oct 14, 2009, at 23:13, "Charlie Clark" wrote: > Me and Jens will be there and Jens will be holding the "Hat of > Shame" over > my head. Not sure who will be there and who'll be sober. Better > order the > langos in advance! ;-) I will be there, but not for the post-conference sprints. My plane is leaving Saturday afternoon. I'm happy to help at any other time during the conference. Keep in mind that I may not be the best match for working on items others want in the release but have not had time to finish. jens ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] PasswordResetTool: usable on plain CMF?
On Oct 10, 2009, at 01:15 , Maurits van Rees wrote: Hi, Products.PasswordResetTool is used by CMFPlone. Is anyone using it in a plain CMF site? I highly doubt it. Most Plone or Collective code, even though much of it is confusingly named "CMFsomething", does not work with plain CMF. jens smime.p7s Description: S/MIME cryptographic signature ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] svn server WAS: Products namespace for eggs
On Sep 24, 2009, at 14:17 , Charlie Clark wrote: Regarding something completely different - I picked up on zope-dev that the svn server has been updated. Does this mean that we can now use the svn branch to trunk merging offered in svn >= 1.5 or is this still inadvisable? If it is still inadvisable could you list (again) how to go about doing it properly and safely? The SVN server has not been updated. It has been at version 1.5.1 for a long time. jens smime.p7s Description: S/MIME cryptographic signature ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Products namespace for eggs
On Sep 24, 2009, at 15:16 , Maurits van Rees wrote: Personally, I am the maintainer of Products.Poi. It will take more than one bottle of whisky to convince me to rename that. ;-) Personally, I believe most product authors who have a real Zope 2 Product but chose a name other than "Products.XXX" did so mostly because... - they think it looks cooler somehow - vanity - "just because I can" I doubt any of them can provide any real tangible benefits gained for users, developers or themselves. jens smime.p7s Description: S/MIME cryptographic signature ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Products namespace for eggs
On Sep 24, 2009, at 14:01 , Charlie Clark wrote: Am 24.09.2009, 13:52 Uhr, schrieb Andreas Jung : In my understanding: packages using the Products namespace are subject to be registered during the startup phase of Zope (using their initialize() method). And I think there is some other evil path magic within Zope related to products in general...I think nothing has changed between Zope 2.11 and 2.12...but I could be wrong. setuptools replaces that evil magic with its own! But at least you do have to specify which eggs you will be using. There's no longer a folder which will magically add any modules in it to sys.path. Now, as long as you declare the egg in buildout and add it to site.zcml and configure the egg correctly you're sorted. Maybe it's the five:loadProducts stuff in site.zcml that's keeping us tied to Products. A namespace change isn't that important and probably is a lot of fairly uninteresting work for little perceived gain. Renaming provides less than little perceived gain. It adds serious pain because then you must go about registering your package manually, you must change imports all over, and you force every package that depends on the CMF to do the same. Besides, the different CMF packages are standard Zope2 products. Leaving them in the Products namespace makes that very clear. jens smime.p7s Description: S/MIME cryptographic signature ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.2 release?
On Sep 15, 2009, at 17:19 , Eric Steele wrote: Hi, Quick introduction: I'm the new Plone 4 release manager; apologies for not popping my head up here sooner. Assuming we don't hit any further delays, we're looking at having a Plone 4.0 alpha available in about 6 weeks. Would it be possible to have a 2.2 release of CMF cut by then? What can I do to help that happen? Hi Eric, You could pester those people who pointed out various things they wanted to have done before the release in the thread starting here: https://mail.zope.org/pipermail/zope-cmf/2009-February/028180.html jens smime.p7s Description: S/MIME cryptographic signature ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
