Re: [Zope-dev] Odd behavior of undoable_transactions()
Paul Winkler [EMAIL PROTECTED] wrote: On Sun, Mar 13, 2005 at 06:57:28PM +0100, Florent Guillaume wrote: You're right. Please put it in the collector. The prefixes should indeed be matching only at '/' boundaries. OK, issue created at http://www.zope.org/Collectors/Zope/1726 and assigned to myself. If nobody objects soon, I will check in tests fixes on both the 2_7 CVS branch and on the SVN trunk. (Is there a 2_8 branch in SVN too? I haven't worked there much yet.) Not yet, but there probably shortly will. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope3-dev] Re: Heads-up: Zope 2.8, Zope 3 and Five
On Tue, Mar 15, 2005 at 07:31:51PM +0100, Christian Heimes wrote: Martijn Faassen wrote: [Could you point me to the issue or mail describing the old-style BTree problem? I may have run into it under another name or something.] http://zope.org/Collectors/Zope/1695 Persistent* were fixed yesterday by Tim Peters Thanks for the pointer. [snip] That sounds a little bit better but Jim was worried for a long time to add zope.interfaces and related. Just read the last discussion over adding parts of ZopeX3 to Zope2.8. I was involved with the discussion. It actually turns out stitching in parts of Zope 3 is much much harder than stitching in all of it; the latter is just a distribution issue. On the other hand we maybe get more developers from Five and ZopeX3 into Zope2 because they want to use Zope 2.8. Let's see what the future will reveal us. Yes. And again, I totally understand where you're coming from. I'm coming from the same direction. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: ZCatalog getObject broken
Roché Compaan wrote: I don't get why you're not getting it :-) A, B and C are folders nested in each other i.e. A/B/C. A user does not have access to A and B but he does have access to C. If getObject uses restrictedTraverse it returns None immediately when traversing A, even though the user is allowed to access C. If getObject was working properly it would have returned C. Ah, okay, I thought that's what you meant, but I hoped it wasn't. The fact that you expect this to work is a bug in Zope's security machinery, IMHO, but sadly only IMHO it appears. I would have no problem with the above behaviour if getObject raised Unauthorized rather than returned None. Your patch still had it returning None, IIRC, why did it do that? The rest of the discussion basically boils down to figure out if the user is allowed to access C or not. Yep, personally I reckon EVRYTHING should behave like restrictedTraverse, but as I said, that appears to just be me... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: ZCatalog getObject broken
Roché Compaan wrote: This is what I am arguing but I haven't had anybody agree/disagree with me yet. It is also a lot simpler to fix: return self.aq_parent.restrictedTraverse(self.getPath(), None) --- return self.aq_parent.unrestrictedTraverse(self.getPath(), None) I don't really mind either, provided the ,None vanishes... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Overriding Products
Martijn Jacobs wrote: Hello guys. I have a question regarding product importing in zope 2.7.x, as since zope 2.7 this part is way more flexible then it was before. I'd like to accomplish the next situation : Look for PRODUCTS_PATH or its zope.conf equivalent... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] checkPermission and proxy roles
Issue #'s 78, 846, 1125 all relate to checkPermission not considering proxy roles. #78 was resolved, however, from the looks of the code (and I haven't tested this), it will fail to Cut/Paste because the 'Delete objects' perm would be permitted by the proxy role which is not considered in the checkPermission. Anyway, the question is this... Why doesn't checkPermission consider proxy roles? I found the following discussion in Zope-CMF and it looks like this was fixed in CMF, but it seems to me like this should be the default policy behavior in Zope. We can do the patches if there's no reason for it being the way it is... Cheers, Tim begin quote Dieter Maurer wrote: I think, we should have both possibilities: [1] check whether the real user would have the permission (independent of proxy roles) [2] check whether the current context has the permission (dependent on the current proxy roles and other execution security aspects (such as ownership)) I'd like to replace utils._checkPermission in CMF HEAD with the attached code. This would change the behavior of _checkPermission from [1] to [2]. (If I didn't make a mistake.) The way utils._checkPermission is used in CMF implies possibility [2] would be the right behavior, the fact it implemented [1] looks like a bug to me. I don't know of any code that'll break if we switch to [2]. I can see there might be a need for [1]. But in this case you can use Zope's checkPermission method. If there are no objections I'll soon make a CVS checkin of the attached code. Cheers, Yuppie --- -- Tim McLaughlin Chief Technology Officer Siteworx, Inc. Innovative internet solutions. 703.964.0300 ext. 208 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
