Re: [Zope-CMF] IMember: does it exist?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 8, 2008, at 01:32 , Paul Winkler wrote: Rob Miller [EMAIL PROTECTED] writes: then CMF does it's normal wrapping of these user objects using the standard MemberData implementation. Hmm, right, so then this might still be on-topic here ;-) Maybe the right thing is for CMF to do a directlyProvides() call in wrapUser? The CMF itself doesn't need this. There's no place that tries to ensure a member does indeed provide IMemberData or similar. If this is something you need for Plone I'm happy to consider patches with tests. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjsYVsACgkQRAx5nvEhZLKp+wCeNXxY6pPNfOSf9TEHnt71bPOJ 2A8AoKp6Y73R2YLRPJ699edbJWRPzplv =bVJl -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] CMF Tests: 9 OK
Summary of messages to the cmf-tests list. Period Tue Oct 7 11:00:00 2008 UTC to Wed Oct 8 11:00:00 2008 UTC. There were 9 messages: 9 from CMF Tests. Tests passed OK --- Subject: OK : CMF-1.6 Zope-2.8 Python-2.3.6 : Linux From: CMF Tests Date: Tue Oct 7 21:26:05 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-October/010082.html Subject: OK : CMF-1.6 Zope-2.9 Python-2.4.4 : Linux From: CMF Tests Date: Tue Oct 7 21:27:35 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-October/010083.html Subject: OK : CMF-2.0 Zope-2.9 Python-2.4.4 : Linux From: CMF Tests Date: Tue Oct 7 21:29:05 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-October/010084.html Subject: OK : CMF-2.0 Zope-2.10 Python-2.4.4 : Linux From: CMF Tests Date: Tue Oct 7 21:30:35 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-October/010085.html Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.4 : Linux From: CMF Tests Date: Tue Oct 7 21:32:05 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-October/010086.html Subject: OK : CMF-2.1 Zope-2.11 Python-2.4.4 : Linux From: CMF Tests Date: Tue Oct 7 21:33:35 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-October/010087.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.4 : Linux From: CMF Tests Date: Tue Oct 7 21:35:06 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-October/010088.html Subject: OK : CMF-trunk Zope-2.11 Python-2.4.4 : Linux From: CMF Tests Date: Tue Oct 7 21:36:36 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-October/010089.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Tests Date: Tue Oct 7 21:38:06 EDT 2008 URL: http://mail.zope.org/pipermail/cmf-tests/2008-October/010090.html ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IMember: does it exist?
Paul Winkler wrote: Rob Miller [EMAIL PROTECTED] writes: then CMF does it's normal wrapping of these user objects using the standard MemberData implementation. Hmm, right, so then this might still be on-topic here ;-) Maybe the right thing is for CMF to do a directlyProvides() call in wrapUser? Please consider using alsoProvides() since directlyProvides *overrides* all directly set interfaces. alsoProvides *adds* to them. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] MembershipTool: Using traversal to look up the Members folder?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 8, 2008, at 13:36 , Raphael Ritz wrote: Hi, today I'm facing the situation where I want to support a Members folder (rare these days) but this folder should be deeper down in the site (very rare; for me this is the first time ever). Currently, CMF(Default - and Plone for that matter) does not support this OOTB because CMFDefault's MembershipTool uses a simple getattr call for the 'membersfolder_id' on the site object. Changing this to use 'unrestrictedTraverse' instead resolves the problem including the possibility to specify the path (or relative content URL) to the folder in ZMI. It does break two tests, however, as the DummySite's 'unrestrictedTraverse' used for testing isn't clever enough to deal with relative paths/URLs correctly. Now my question: Is this something CMFDefault should support? If so, I'm happy to file a ticket with a patch (and test; I don't have repository access). If not, I will simply keep on patching my local installation. Just thought I'll let you know. Opinions anyone? Please keep in mind the true nature of CMFDefault: It's a sample application of the framework laid down in CMFCore. So IMHO _if_ this kind of configurable members folder location feature is added, it should be in CMFCore and thus available to CMFDefault. As far as the feature itself is concerned, I've never seen a situation where this is useful or needed. So my vote as far as the CMF is concerned is +-0 because it's a YAGNI feature, You Ain't Going to Need It. I'd say the correct place would be a custom membership tool for your specific application that needs to support this use case. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjsrkUACgkQRAx5nvEhZLKx3QCfS3u5pfLRG1H2AHnAVbGeiIHy nTEAoKGU7zm+ft+4CDMrQvzNzPQRXZJO =ei66 -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] MembershipTool: Using traversal to look up the Members folder?
Previously Raphael Ritz wrote: Currently, CMF(Default - and Plone for that matter) does not support this OOTB because CMFDefault's MembershipTool uses a simple getattr call for the 'membersfolder_id' on the site object. Changing this to use 'unrestrictedTraverse' instead resolves the problem including the possibility to specify the path (or relative content URL) to the folder in ZMI. Shouldn't it use restrictedTraverse? Is there a special reason you want to bypass security? Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] MembershipTool: Using traversal to look up the Members folder?
Hi, today I'm facing the situation where I want to support a Members folder (rare these days) but this folder should be deeper down in the site (very rare; for me this is the first time ever). Currently, CMF(Default - and Plone for that matter) does not support this OOTB because CMFDefault's MembershipTool uses a simple getattr call for the 'membersfolder_id' on the site object. Changing this to use 'unrestrictedTraverse' instead resolves the problem including the possibility to specify the path (or relative content URL) to the folder in ZMI. It does break two tests, however, as the DummySite's 'unrestrictedTraverse' used for testing isn't clever enough to deal with relative paths/URLs correctly. Now my question: Is this something CMFDefault should support? If so, I'm happy to file a ticket with a patch (and test; I don't have repository access). If not, I will simply keep on patching my local installation. Just thought I'll let you know. Opinions anyone? Raphael ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] genericsetup:upgradeDepends
Previously Rob Miller wrote: hi all, i've got a GenericSetup branch called 'ra-depends-tag' with a working implementation of a genericsetup:upgradeDepends ZCML tag. this tag can be used anywhere that you could use a genericsetup:upgradeStep tag (i.e. either standalone, or nested within a genericsetup:upgradeSteps). in fact, upgradeDepends is simply a special case of upgradeStep that allows you to specify a set of profile import steps to be re-applied to the site, rather than calling a generic python handler. here's an example of how it looks: genericsetup:upgradeDepends profile=Products.Something:default source=1.0 destination=1.1 sortkey=10 title=Re-run 'foo' import step import_steps=foo purge=True run_deps=False / I would like to see a simple extension: the ability to run one or more steps from another profile. This can be very useful when you run upgrades for a base profile which load (steps from a) profile from an add-on package. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] genericsetup:upgradeDepends
Previously Wichert Akkerman wrote: Previously Rob Miller wrote: hi all, i've got a GenericSetup branch called 'ra-depends-tag' with a working implementation of a genericsetup:upgradeDepends ZCML tag. this tag can be used anywhere that you could use a genericsetup:upgradeStep tag (i.e. either standalone, or nested within a genericsetup:upgradeSteps). in fact, upgradeDepends is simply a special case of upgradeStep that allows you to specify a set of profile import steps to be re-applied to the site, rather than calling a generic python handler. here's an example of how it looks: genericsetup:upgradeDepends profile=Products.Something:default source=1.0 destination=1.1 sortkey=10 title=Re-run 'foo' import step import_steps=foo purge=True run_deps=False / I would like to see a simple extension: the ability to run one or more steps from another profile. This can be very useful when you run upgrades for a base profile which load (steps from a) profile from an add-on package. .. and support upgrade-profiles similar to what we have been using for Plone releases for a while now. Extremely useful stuff. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] MembershipTool: Using traversal to look up the Members folder?
Wichert Akkerman wrote: Previously Raphael Ritz wrote: Currently, CMF(Default - and Plone for that matter) does not support this OOTB because CMFDefault's MembershipTool uses a simple getattr call for the 'membersfolder_id' on the site object. Changing this to use 'unrestrictedTraverse' instead resolves the problem including the possibility to specify the path (or relative content URL) to the folder in ZMI. Shouldn't it use restrictedTraverse? Is there a special reason you want to bypass security? The reasons are: (i) the current implementation doesn't check security either (ii) 'getMembersFolder' while public is most often called from 'getHomeFolder' which does check security so I think it is not necessary to check security twice. But should we change this at all I would be fine with 'restrictedTraverse' as well (in the sense of being defensive). Raphael Wichert. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] MembershipTool: Using traversal to look up the Members folder?
Jens Vagelpohl wrote: [..] Please keep in mind the true nature of CMFDefault: It's a sample application of the framework laid down in CMFCore. So IMHO _if_ this kind of configurable members folder location feature is added, it should be in CMFCore and thus available to CMFDefault. That would be my thinking as well but seeing that the current implementation in CMFCore is even less flexible (it looks for a 'Members' object - hard-coded id - in the site root) and that CMFDefault overrides this to allow configurability of the object id at least I thought it would fit better there. But I agree with you that should we consider this at all CMFCore would be the more appropriate place to do it. As far as the feature itself is concerned, I've never seen a situation where this is useful or needed. So my vote as far as the CMF is concerned is +-0 because it's a YAGNI feature, You Ain't Going to Need It. Which is why I wrote the little intro in my original posting and why I posted this here as a question instead of filing a bug report right away. I'd say the correct place would be a custom membership tool for your specific application that needs to support this use case. Which is perfectly fine with me as I said before. Raphael jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkjsrkUACgkQRAx5nvEhZLKx3QCfS3u5pfLRG1H2AHnAVbGeiIHy nTEAoKGU7zm+ft+4CDMrQvzNzPQRXZJO =ei66 -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] MembershipTool: Using traversal to look up the Members folder?
Am 08.10.2008 um 14:57 schrieb Jens Vagelpohl: Please keep in mind the true nature of CMFDefault: It's a sample application of the framework laid down in CMFCore. True but an eminently usable one. So IMHO _if_ this kind of configurable members folder location feature is added, it should be in CMFCore and thus available to CMFDefault. Very true. As far as the feature itself is concerned, I've never seen a situation where this is useful or needed. So my vote as far as the CMF is concerned is +-0 because it's a YAGNI feature, You Ain't Going to Need It. I'd say the correct place would be a custom membership tool for your specific application that needs to support this use case. +1 for ± 0 ;-) Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] IMember: does it exist?
Jens Vagelpohl [EMAIL PROTECTED] writes: On Oct 8, 2008, at 01:32 , Paul Winkler wrote: Rob Miller [EMAIL PROTECTED] writes: then CMF does it's normal wrapping of these user objects using the standard MemberData implementation. Hmm, right, so then this might still be on-topic here Maybe the right thing is for CMF to do a directlyProvides() call in wrapUser? The CMF itself doesn't need this. There's no place that tries to ensure a member does indeed provide IMemberData or similar. In that case I'd be inclined to leave CMF alone, until somebody actually depends on that behavior. If this is something you need for Plone I'm happy to consider patches with tests. Not me; I was initially just trying to understand how the interfaces relate to each other. To me it's just a documentation issue. (Oh, and Philip, thanks for the reminder about alsoProvides(); I've made that mistake before and should have learned from it by now!) - PW ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
