January 2004 - Zope-Dev

ZCatalog fast as admin, dog slow as anonymous and other users
by Jason Spisak 14 Apr '04

14 Apr '04

Zopistas, My ZCatalog is fast as admin, but dog slow as anonymous and other users. Anyone had this same experience? Details: marjors: Zope 2.6.2 CMF 1.3 Plone 1.0.5 about 50,000 cataloged objects (dual xenon server, plenty of ram, RAID) User folder has 15k users in it, but admin is one of those users. i've factored it way down and a simple search with just 1 Event loaded, like: return context.portal_catalog(Type='Event') is instantaneous for the 'admin' user, but takes about 10 seconds to return 1 SINGLE object. (only 1 Event loaded) imagine the time it takes to search and display 1300 events (which is what's normally in there). ouch. i've rebuilt the indexes, and still no dice. Any help would be greatly appreciated. All my best, Jason Spisak

4 17

app = Zope.app() backwards incompatibility notice / discussion
by Chris McDonough 16 Feb '04

16 Feb '04

The extant "import Zope; app = Zope.app()" dance to get a hold of the Zope root object stopped working long ago on the 2.7 branch and HEAD due to the new configuration machinery, which implies that users be explicit about configuration settings rather than allowing Zope to guess. Up til now, the dance to get Zope 2.7 to start properly from within a script was byzantine and obscure. I've made a checkin which makes it a little easier (or at least I'm about to as soon as the full unit test suite comes back passed ;-). Code which used to do: import Zope app = Zope.app() Will need to do this under 2.7b4+: import Zope Zope.configure('/path/to/configfile') app = Zope.app() (I wont bother telling you what the dance was for 2.7 before now, it was pretty awful). I realize this is suboptimal from a backwards compatibility perspective, but I'm not sure how to make it any better, seeing as the config file has some fairly important information in it (like which databases to use) and guessing would be very bad in this context. Jim Roepke suggested that if an "ZOPE_CONFIG" envvar was set with the config file path, that "import Zope; Zope.app()" could be made to "just work", but I'm not sure this is any better than requiring that developers change their scripts. Guessing at the config file location is also fraught with problems, and I'd be hesitant to do it. I'm apt just to recommend that we require that developers add the "Zope.configure(filename)" line to their scripts as opposed to doing anything more magical. I'm sure there will be indignant wails about it, but c'est la vie. ;-) Note that FWIW, you can also do (on UNIX): zopectl run <scriptname> .. which will run a script with the name "app" set up as the root Zope application object. This might be the easiest way to run scripts which need to operate against Zope objects going forward. - C

5 7

Security validation issue
by Herman Geldenhuys 30 Jan '04

30 Jan '04

I've written a Zope product that exposes a "MenuItem". I add a menuItem in a Zope folder, and I have no difficulty accessing and editing it via the ZMI. I've written an xml-rpc-like protocol for Zope, that basically validates the security "manually". This menuItem has an attribute called "def getVersion(self):" which returns an int. This is the Code that prevents me from accessing the method in python, via my protocol: if not AccessControl.getSecurityManager().validate(None, object, attributes[-1]): raise UnauthorisedAccessException('Unauthorised: ' + originalAddress) object = <bound method HWMenuItem.getVersion of <HWMenuItem instance at 01B7B290>> This is the method getVersion attributes[-1] = "getVersion" (string) UnauthorisedAccessException: Unauthorised: menus.administration.addUser.getVersion This code works for any other default Zope type, but not mine. Did I perhaps forgot a permission or something? I can access this fine via the ZMI, but when I validate it this way, python just starts cursing at me. Can somebody help? Thanks H

2 2

Call for testing (2.6.4 / 2.7.0)
by Brian Lloyd 29 Jan '04

29 Jan '04

Hi all - Tres and I have been working to merge some final fixes, and I'd like to be able to make rc2 releases for 2.6.4 and 2.7.0 tomorrow. In the meantime, it would be helpful for anyone who runs from the 2.6 or 2.7 branches in CVS to update and let us know if you have any unresolved problems. It would be especially helpful for those who were having trouble with things like workflow scripts under the rc1 releases to give this a shot and let us know if the trouble is resolved. **Note that you need to rebuild the C extensions, due to a fix to cAccessControl. Be sure to do this before reporting any lingering issues!** Thanks, Brian Lloyd brian(a)zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com

4 5

Features for Zope 2.8
by Christian Theune 29 Jan '04

29 Jan '04

Hi. As Zope 2.7 looks like could-be-out-soon. I'd like to ask if there is room for including the post-traverse patch in Zope 2.8. I'm currently maintaining it as a patch on a branch for Zope 2.7, but would like to see it back in the mainstream. Short description of it: - Sometimes you want to run code before the published object as in the before_traverse hooks. But there you miss to variables: The object to be published and security context. - During traversal you can register yourself to be called after those two variables have been determined. This results in a chain of methods to be callen. - When the methods are callen, they get the necessary contexts and can return None (everything as usual) or return something else, that should be used for publication instead of the object that was found by traversal. (Note: I intended it that the REQUEST['PUBLISHED'] remains the one found by traversal.) This also discontinues the chain of post traversal calls. If this is feature could be a candidate for 2.8, i'll write a more in-depth proposal on it, and can provide the necessary code. Cheers, Christian -- Christian Theune, gocept gmbh & co. kg http://www.gocept.com - ct(a)gocept.com fon: 03496 3099112 fax: 03496 3099118 mobile: 0179 7808366

2 1

cPickleCache endless loop...
by Mario Lorenz 28 Jan '04

28 Jan '04

Hello, we have spent most of the day tracking down obscure hangs of Zope (2.6.4rc1) under python2.1.3 on a RHEL3 machine. The problem seems to be a logic flaw somewhere related to the cPickleCache, when using a destructor in a Zope object that accesses itself. In our case(shortened to the offending line): def __del__(self): print "About to destroy: ", self.id What seems to happen is that the "self.id" access causes the object to be cached again, causing scan_gc_items() to run in circles. Any ideas on how to best fix this? Mario -- Mario Lorenz EMail: Mario.Lorenz(a)km3.de Tel: 03774 6625-78 Technik Netze Handy: 0160 3151600 km3 teledienst GmbH Fax: 03774 6625-79

7 12

ConflictError in BTreeFolder2
by Florent Guillaume 27 Jan '04

27 Jan '04

FYI: I've fixed BTreeFolder2 to properly re-raise ConflictError in _delObject and not swallow it during beforeDelete cleanups. This is the same fix that was done in ObjectManager. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com

3 3

fdrake's fix for brian's fix for bug 1203 needs to be applied in other branches
by Leonardo Rochael Almeida 27 Jan '04

27 Jan '04

Hi, There's a recent entry in the 2.6 branch from fred stating: types don't have a guaranteed truth value, so check that it isn't None the diff is here: http://cvs.zope.org/Zope/lib/python/ZTUtils/Zope.py.diff?r1=1.10.6.3&r2=1.1… This same fix needs to be applied to at least the 2.7 branch and HEAD, probaly other branches too, but I haven't checked. Should I file a bug for this? Cheers, Leo -- Ideas don't stay in some minds very long because they don't like solitary confinement.

3 4

Re: [Zope-dev] cPickleCache endless loop...
by Paul Winkler 27 Jan '04

27 Jan '04

On Mon, Jan 26, 2004 at 08:59:36AM +0000, Chris Withers wrote: > Paul Winkler wrote: > > >On Fri, Jan 23, 2004 at 12:08:27PM -0500, Tim Peters wrote: > > > >>>def __del__(self): > >>> print "About to destroy: ", self.id > > > >I don't know what your intention is there, but fwiw, if > >what you're *really* interested in is the object being > >marked for deletion in the ZODB, you can use: > > I'm pretty sure that only works in Zope, so? the O.P. was about zope, and this IS the zope-dev list... > and even then, when the > ObjectManager stuff comes into play ;-) true enough. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's THE FASCIST! (random hero from isometric.spaceninja.com)

2 1

2.6.4.c1 still problem with security
by robert rottermann 26 Jan '04

26 Jan '04

Hi there, I am using zope from cvs Zope-2_6-branch. I still get the following assertion in a DCWorkflow which worked flawlessly in 2.6.2 Thanks for any pointers Robert Traceback (innermost last): Module ZPublisher.Publish, line 98, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 39, in call_object Module Products.CMFCore.FSPythonScript, line 92, in __call__ Module Shared.DC.Scripts.Bindings, line 261, in __call__ Module Shared.DC.Scripts.Bindings, line 292, in _bindAndExec Module Products.CMFCore.FSPythonScript, line 126, in _exec - __traceback_info__: ({'traverse_subpath': [], 'container': <PloneSite instance at 8bbed10>, 'context': <PloneFolder instance at 96fb608>, 'script': <FSPythonScript at /zehnder/zehnder/createObject used for /zehnder/zehnder/tasklist/Task.2004-01-19.3020/Attachments>}, (None, 'File', None), {}, (None, None, None)) Module None, line 12, in createObject Module Products.CMFCore.PortalFolder, line 362, in invokeFactory Module Products.CMFCore.TypesTool, line 824, in constructContent Module Products.CMFCore.TypesTool, line 516, in constructInstance Module Products.CMFCore.TypesTool, line 420, in _finishConstruction Module Products.CMFCore.CMFCatalogAware, line 101, in notifyWorkflowCreated Module Products.CMFPlone.WorkflowTool, line 26, in notifyCreated Module Products.CMFCore.WorkflowTool, line 362, in notifyCreated Module Products.DCWorkflow.DCWorkflow, line 367, in notifyCreated Module Products.DCWorkflow.DCWorkflow, line 440, in _changeStateOf Module Products.DCWorkflow.DCWorkflow, line 543, in _executeTransition Module Shared.DC.Scripts.Bindings, line 261, in __call__ Module Shared.DC.Scripts.Bindings, line 290, in _bindAndExec Module Shared.DC.Scripts.Bindings, line 1, in ? Module Shared.DC.Scripts.Bindings, line 224, in _getContext Unauthorized: You are not allowed to access in this context

2 3