- Zope-Dev - Zope lists

Final Python 2.1.x and Zope 2.5.x releases?
by Adam Manock 02 Apr '02

02 Apr '02

Fellow bleeding edge Zopers, (Zopesters, Zopeheads, Zopers and Zopists too) Firstly, I'd like to thank everyone who has worked on the "Segfault Saga", esp. Matthew and Leonardo! Obviously now that it's fixed, all that's left to do is to make stability a reality for everybody ;-) Does anyone know of a release timeline for a new bugfix release of Python, be it 2.1.2a or 2.1.3? (I am hoping that Zope's need for this will cause it to be sooner rather than later) Are there any outstanding issues with Zope 2.5.1b1 preventing a 2.5.1b2 or 2.5.1-final release? I.E. should we be expecting to see a new Zope release this week? Adam

1 0

DA howto found
by Charlie Reiman 02 Apr '02

02 Apr '02

I was searching for "database adaptor", not "database adapter". Both spellings are correct according to m-w.com. http://www.zope.org/Members/petrilli/WritingADA

1 0

ZCatalog - hiding query results
by Igor Stroh 02 Apr '02

02 Apr '02

Hi all, I don't know if it's the right list to post to, but I have the following problem: I have several objects (documents, folders etc) that are accessible only by a certain user role, this objects are cataloged. Now if I query the catalog the brains of these objects are returned correctly, but to _all_ users that issue a query. That means, users that don't have the permission to "View" or "Access Content Information" can see the brains as well... I tried to filter the result set by converting the brains into real objects (brain.getObject) in an external method (I thought, this way I should be able to exclude unauthorized users by adding the "skip_unauthorized" to the dtml-in), but that doesn't work since there are "brains" that are actually NoBrainer instances... Does anyone have an idea of how I could solve this problem? Actually I thought this kind of "information hiding" is supported by basic ZCatalog machinery, but now it looks like I'll have to hack a workaround... Any help greatly appreciated. Greetings, Igor

5 4

ZCatalog: hiding search results from unauthorized users - hack
by Igor Stroh 02 Apr '02

02 Apr '02

Hi all, in case someone have same problem as me (see "ZCatalog - hiding query results" thread for more info) - I got a solution: - create a product that subclasses ZCatalog - in this product overwrite ZCatalog.getobject with def getobject(self, rid): """foo""" obj = self.aq_parent.unrestrictedTraverse(self.getpath(rid),\ restricted=1) return obj - create a python script in your catalog (e.g. "filterCat") with a parameter that reoresents the catalog itself ("brains" here): retval = [] for brain in brains: try: obj = container.getobject(brain.getRID()) retval.append(brain) except: pass return retval - adjust your catalog query reports, so that they call "filterCat(_['<catalogname>'])" instead of <catalogname> Now your users see only those hits in a query which apply to objects they are allowed to "View". greetings, Igor

3 3

DC development guide
by Charlie Reiman 02 Apr '02

02 Apr '02

Is there a general Database Connection developer's guide? I'm currently attempting to hack together a user keyed DC system so each authenticated user gets her own sign-on specific connection to the database. While my work is proceeding pretty well, I'd like to, well, know what I'm doing. Does anyone have any documentation or nice example suggestions? Charlie Reiman creiman(a)kefta.com

1 0

[Zope Crash Solution] Positive Report
by Stefano Noferi 02 Apr '02

02 Apr '02

Hi Zopers! Thanks all for your time, especially to Matthew and Leonardo. My patched Python/Zope systems run well now in multi-threads mode. I tested with very hard Python Scripts too and my report is at all positive. My relief is great, like many others zopers, I think ; ) Thanks again and Happy Easter! Stefano ---------------------------------------------------------- Stefano Noferi n o z e S.r.l. Soluzioni Open-Source Via Caduti del Lavoro, 32 56122 Pisa (PI) - Italy Tel: +39 (0)50 533320 Fax: +39 (0)50 526604 Email: stefano(a)noze.it Web: http://www.noze.it ----------------------------------------------------------

3 3

__bobo_traverse__, restrictedTraverse and PageTemplates
by Florent Guillaume 02 Apr '02

02 Apr '02

I'm using Zope 2.5.1b1, CMF from CVS. I'm having a strange problem when trying to define a custom __bobo_traverse__, where an Unauthorized exception is raised from PageTemplates/Expressions.py/restrictedTraverse. The object's __bobo_traverse__ is simply doing def __bobo_traverse__(self, REQUEST, name): """Traversal to get to the virtual documents.""" target = getattr(self, name, None) if target is not None: return target #... other things that are never called ... (The goal would be to make some objects appear to be under a given level which isn't in fact a container but calls the catalog to display a listing.) With that code, if I try to view the object, I get: ... File .../lib/python/ZPublisher/Publish.py, line 39, in call_object (Object: foo) File .../Products/CMFCore/PortalContent.py, line 167, in __call__ (Object: foo) File .../lib/python/Shared/DC/Scripts/Bindings.py, line 252, in __call__ (Object: mylevel_view) File .../lib/python/Shared/DC/Scripts/Bindings.py, line 283, in _bindAndExec (Object: mylevel_view) File .../lib/python/Products/PageTemplates/Expressions.py, line 177, in _eval File .../lib/python/Products/PageTemplates/Expressions.py, line 134, in _eval (Info: here) File .../lib/python/Products/PageTemplates/Expressions.py, line 321, in restrictedTraverse (Object: foo) (Info: {'path': ['portal_url'], 'TraversalRequestNameStack': []}) Unauthorized: You are not allowed to access portal_url in this context There error stems from the fact that the view calls here/portal_url, which sould be ok. If I remove the bobo_traverse, everything works fine and dandy of course. I don't undersand the difference because my __bobo_traverse__ is just doing standard stuff that traversal would do anyway. If I look at Expressions.py/restrictedTraverse, there are discrepancies I cannot explain. The relevant parts in this case are (I commented the code that's not executed, for display purposes): t=get(object, '__bobo_traverse__', N) if t is not N: o=t(REQUEST, name) container = None #if has(o, 'im_self'): # container = o.im_self #elif (has(get(object, 'aq_base', object), name) # and get(object, name) == o): # container = object if not validate(object, container, name, o): raise Unauthorized, name # line 321 else: o=get(object, name, M) if o is not M: # Check security. if has(object, 'aq_acquire'): object.aq_acquire( name, validate2, validate) #else: # if not validate(object, object, name, o): # raise Unauthorized, name #else: # try: # o=object[name] # except (AttributeError, TypeError): # raise AttributeError, name # if not validate(object, object, name, o): # raise Unauthorized, name object = o So I don't understand the different treatments, with bobo_traverse I get a None container, which makes the validate fail, whereas standard traversal calls ac_acquire with as a filter validate2, the filters receives a container, and this validation suceeds. If anybody has any lights on how I write do the __bobo_traverse__ I need... Thanks, Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 10 http://nuxeo.com mailto:fg@nuxeo.com

2 2

Re: [Zope-dev] ZClass Constructor Cleanup for 2.6
by Didier Georgieff 02 Apr '02

02 Apr '02

On Wed, 2002-03-27 at 17:31, Casey Duncan wrote: > ZClasses have been overlooked enough. Nobody has even bothered > putting a ZCatalogPathAware available for them... I've done that locally (changing __init__ and the the py but had no chance to make it work with __existing__ ZClasses. Something was coded inside the zclass instance ;-< So i had to patch ZCatalog for getting the right behaviour for my existing products. So, even if ZClasses are not cooked completely, they allow guys like me to use zope, to promote zopet even if we are useless at good python programming ;-), and until Z3 exists. All my support for ZCatalogPathAware in 2.6. Maybe we should investigate : - how updating old CatalogAware ZClasses for taking care of that - what impact for already updated construtor scripts ? (shuild be none, but not sure) Didier.

5 4

FW: Catalogs, Imports, and Path Awareness (was Re: [Zope-dev] ZClass Constructor Cleanup for 2.6)
by Jeffrey P Shell 02 Apr '02

02 Apr '02

On 4/1/02 5:59 PM, "R. David Murray" <bitz(a)bitdance.com> wrote: > On Mon, 1 Apr 2002, Jeffrey P Shell wrote: >> If other people have come across this, I think finding a resolution to this >> would be a more-than-worthy 2.6 project. If I'm just smoking crack and it's >> only a ZPatterns/TransactionAgents behavior that I'm witnessing, then I'll >> just leave my huffing and puffing and whining and yelling and fainting to >> myself and immediate coworkers next time I have to go through this >> situation. :/ > > I thought that with ZPatterns one was recommended to avoid the > Catalog mixins and instead use something like SteveA's > catalog trigger from ZPAddOns (I think that's the right product > name). That's what I did. But, looking at the import machinery, the newly imported object is added in to it's parent object with '_setObject', which then goes and calls "self.manage_afterAdd()", which then goes down into all of the subobjects and calls that. That's probably the right thing, but it is what's causing the double cataloging, regardless of how the item is cataloged. Catalog*Aware objects call into the catalog during manage_afterAdd, and I'm sure that the same thing is happening to my "WHEN OBJECT ADDED..." triggers as well. *sigh*. I've got a few quarter assed solutions in my head, but I don't like any of them. Waaa. -- Jeffrey P Shell www.cuemedia.com

2 1

Re: [Zope-dev] ZClass Constructor Cleanup for 2.6
by Anthony Baxter 02 Apr '02

02 Apr '02

>>> Casey Duncan wrote > I don't think this is a big enough change to warrant a real proposal, so > I'll shoot this out here: > > Does anyone see a problem with changing the default generated > constructor method for ZClasses to a python script in Zope 2.6? +1. There's always some funniness in ZClass constructors anyway with the stupid acquisition tricks that get played, so making it a pythonscript can only make it more obvious what's going on...

1 0