[Zope-CMF] CMF Collector: Open Issues
The following supporters have open issues assigned to them in this collector (http://www.zope.org/Collectors/CMF). Assigned and Open efge - CMFSetup: provide non-ascii im- and exports, [Accepted] http://www.zope.org/Collectors/CMF/292 - CMFSetup doesn't correctly detect DCWorkflow on export, [Accepted] http://www.zope.org/Collectors/CMF/298 jens - Discussion replies removal, [Accepted] http://www.zope.org/Collectors/CMF/391 mhammond - Windows DevelopmentMode penalty in CMFCore.DirectoryView, [Accepted] http://www.zope.org/Collectors/CMF/366 mj - CMFSetup doesn't correctly detect DCWorkflow on export, [Accepted] http://www.zope.org/Collectors/CMF/298 regebro - fiveactionstool broken (Zope 2.9/3.2), [Accepted] http://www.zope.org/Collectors/CMF/392 Pending / Deferred Issues - CMFCalendar weekday locale issue, [Pending] http://www.zope.org/Collectors/CMF/237 - Wrong cache association for FSObject, [Pending] http://www.zope.org/Collectors/CMF/255 - CMFSetup: Windows exports contain CR/LF, LF and even CR newlines, [Pending] http://www.zope.org/Collectors/CMF/266 - FSPropertiesObject.py cannot handle multiline input for lines, text attributes, [Pending] http://www.zope.org/Collectors/CMF/271 - PortalCatalog.ZopeFindAndApply should probably also search in opaqueItems, [Pending] http://www.zope.org/Collectors/CMF/296 - Can't invalidate skin items in a RAMCacheManager, [Pending] http://www.zope.org/Collectors/CMF/343 - CMFSetup: Workflow Tool export fails with workflows which have scripts, [Pending] http://www.zope.org/Collectors/CMF/373 - CMFCore.Skinnable.SkinnableObjectManager can merge skin data, [Pending] http://www.zope.org/Collectors/CMF/375 - Proxy Roles does't work for a Script using portal_catalog.searchResults, [Pending] http://www.zope.org/Collectors/CMF/380 - WorkflowAction deprecated warning should not printed for WorkflowMethod, [Pending] http://www.zope.org/Collectors/CMF/388 - workflow notify success should be after reindex, [Pending] http://www.zope.org/Collectors/CMF/389 - came_from and VIRTUAL_URL problem, [Pending] http://www.zope.org/Collectors/CMF/393 Pending / Deferred Features - Favorite.py: queries and anchors in remote_url, [Pending] http://www.zope.org/Collectors/CMF/26 - Allow flexible date editing in Event.py (CMFCalendar), [Pending] http://www.zope.org/Collectors/CMF/40 - DefaultDublinCore should have Creator property, [Pending] http://www.zope.org/Collectors/CMF/61 - Make changeFromProperties accept sequences too, [Pending] http://www.zope.org/Collectors/CMF/99 - path criteria on Topic should honor VHM, [Pending] http://www.zope.org/Collectors/CMF/111 - Document.py: universal newlines, [Pending] http://www.zope.org/Collectors/CMF/174 - Permissions in PortalFolder: invokeFactory(), [Pending] http://www.zope.org/Collectors/CMF/175 - Add condition for transition's action like other action, [Pending] http://www.zope.org/Collectors/CMF/207 - Major action enhancement, [Pending] http://www.zope.org/Collectors/CMF/232 - portal_type is undefined in initialization code, [Pending] http://www.zope.org/Collectors/CMF/248 - Action._listsActions() should be more safe, [Pending] http://www.zope.org/Collectors/CMF/253 - Expose Document text_format metadata, [Pending] http://www.zope.org/Collectors/CMF/285 - customization of type of homefolder on creation, [Pending] http://www.zope.org/Collectors/CMF/288 - Allow contentFilter to use review_state, [Pending] http://www.zope.org/Collectors/CMF/294 - CMFTopic Does Not Cache, [Pending] http://www.zope.org/Collectors/CMF/295 - Wishlist: a flag that tags the selected action., [Pending] http://www.zope.org/Collectors/CMF/301 - CMFDefault should make use of allowCreate(), [Pending] http://www.zope.org/Collectors/CMF/340 - Nested Skins, [Pending] http://www.zope.org/Collectors/CMF/377 - CatalogVariableProvider code + tests, [Pending] http://www.zope.org/Collectors/CMF/378 - manage_doCustomize() : minor additions, [Pending] http://www.zope.org/Collectors/CMF/382 ___ 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
Re: [Zope-CMF] Dead branches
Florent Guillaume wrote: Could folks having old CMF branches clean them up ? Why, what's the problem with them? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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: [CMF-checkins] SVN: CMF/branches/tseaver-pkg_resources/ Avoid using __file__ where possible.
Tres Seaver wrote: Log message for revision 40036: Avoid using __file__ where possible. Why? I use this all over the place so need to know why it's bad ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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
Re: [Zope-CMF] Dead branches
On Thu, Nov 10, 2005 at 05:52:05PM +0100, Florent Guillaume wrote: Could folks having old CMF branches clean them up ? See http://svn.zope.org/CMF/branches/ This seems to concern: ajung, andrew, chrism, chrisw, gregweb, jshell, mj, regebro, shane, sidnei, slinkp, tseaver, yuppie. I'm afraid I don't know what that means. I didn't find anything relevant under http://www.zope.org/DevHome/Subversion . -- Paul Winkler http://www.slinkp.com ___ 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: Dead branches
Paul Winkler wrote: Could folks having old CMF branches clean them up ? See http://svn.zope.org/CMF/branches/ This seems to concern: ajung, andrew, chrism, chrisw, gregweb, jshell, mj, regebro, shane, sidnei, slinkp, tseaver, yuppie. I'm afraid I don't know what that means. I didn't find anything relevant under http://www.zope.org/DevHome/Subversion . It means removing them using svn rm. The point is that looking at available branches is a good way to know what's cooking, and if there are tens of them that have either been merged or abandonned, it clutters everything. Also removing them is not a problem as svn doesn't lose the information, and if for some reason the history of the branch has to be retrieved, it's easy. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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] backporting GenericSetup to CMF-1.5
hi all, those of us planning out the next Plone releases are in a bit of a bind. we really want to make use of GenericSetup's newer Z3-interface-based means of defining import and export handlers, so that we can start work on rewriting our migration engine to use XML import and export, and so we can keep up w/ CMF 2.0 as it moves forward. however, we just had a release that broke all of the add-on products, and it's not really an option for us to break everything again by depending on CMF 2.0, which has removed a bunch of deprecated spellings that are still in common use throughout many Plone add-on products. we realize, of course, that this is in part a result of us having fallen so far behind CMF's development cycle, but we are now earnestly trying to play catch-up, and to continue to keep up, without forcing all of our product authors to rewrite their products twice in 6 months just to keep them working. to this end, it would be very useful for us to have a 1.5-compatible version of CMF that makes use of the newer Generic/CMFSetup semantics. this would allow us to use the new site creation code (which we've nearly completed) in our next release without breaking backwards compatibility with the existing add-on products. this would also make it easier to keep up w/ CMF trunk development w/o having to maintain two radically different branches of Plone. CMF 2.X would be required, of course, with the subsequent release. how do folks feel about this? (note that we, i.e. the plone developers, are willing to do the work.) would you be willing to have an additional 1.5 release, or perhaps a 1.6 release, which includes these changes? our current tentative release schedule has a Plone alpha in late december, beta in february, release some time in march. thx for your input, -r ___ 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: backporting GenericSetup to CMF-1.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rob Miller wrote: those of us planning out the next Plone releases are in a bit of a bind. we really want to make use of GenericSetup's newer Z3-interface-based means of defining import and export handlers, so that we can start work on rewriting our migration engine to use XML import and export, and so we can keep up w/ CMF 2.0 as it moves forward. however, we just had a release that broke all of the add-on products, and it's not really an option for us to break everything again by depending on CMF 2.0, which has removed a bunch of deprecated spellings that are still in common use throughout many Plone add-on products. we realize, of course, that this is in part a result of us having fallen so far behind CMF's development cycle, but we are now earnestly trying to play catch-up, and to continue to keep up, without forcing all of our product authors to rewrite their products twice in 6 months just to keep them working. to this end, it would be very useful for us to have a 1.5-compatible version of CMF that makes use of the newer Generic/CMFSetup semantics. this would allow us to use the new site creation code (which we've nearly completed) in our next release without breaking backwards compatibility with the existing add-on products. this would also make it easier to keep up w/ CMF trunk development w/o having to maintain two radically different branches of Plone. CMF 2.X would be required, of course, with the subsequent release. Thanks for explaining the rationale so clearly. how do folks feel about this? (note that we, i.e. the plone developers, are willing to do the work.) would you be willing to have an additional 1.5 release, or perhaps a 1.6 release, which includes these changes? I would be happier with this as a 1.6, because it adds features (and therefore risk of instability) into a mature release / support line. +1 to that, assuming we can scope it as current 1.5 branch except CMFSeup / GenericSetup from some labeled tag of current trunk. Note that I would expect to continue critical / security bugfix support for the 1.5 line, and would want the 1.6 line to stay as close to 1.5 as possible (with the exception of the setup code) to reduce the maintenance burden. our current tentative release schedule has a Plone alpha in late december, beta in february, release some time in march. Just for the record: CMF 2.0 should be in alpha by the end of this month, with a beta in mid December and a release in early January. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDdUxm+gerLs4ltQ4RAnrcAJ934YyNQlS8zMb1ufS6gXXjpv8vQwCgsjsk VTlqYM03fJtDBNtH7MGnqHo= =ZnK6 -END PGP SIGNATURE- ___ 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
