December 2001 - Zope-Dev

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

Shallow copies/links/references
by Mario Valente 08 Mar '02

08 Mar '02

Hi: OK everyone, I've managed to get object links to work. As discussed previously by others (re: object references) and asked by myself: I had the need to be able to refer to objects from different points of the folder hierarchy without duplicating those objects. Yes I know that can be done *programatically*. That is not the idea. The idea is to have a folder with differente widgets/components and to be able to copy and paste references to those widgets throughout the folder hierarchy. Of course that the usual copy/paste is not OK, since that *duplicates* the objects and as such further changes to the original object wont be reflected in the copies. With something like this + Ordered Folders you are able to have an index_html that just renders the objects within a folder and you can then drop objects/widgets into the folder to produce a page. What I did: - edited CopySupport.py - copied the manage_pasteObjects method to a manage_pasteMonikers method - commented the #ob=ob._getCopy(self) line (the duplicate object part) - added a "Paste Ref" button to the lib/python/OFS/dtml/main.dtml file that calls the pasteMonikers method """ <input class="form-element" type="submit" name="manage_pasteMonikers:method" value="Paste Ref." /> """ It works. It does what I want/need. When you change a reference, the original also changes. When you change the original, the references change. You can delete either the reference or the original and all is OK. Issues/TODO - find a way to distinguish references from the original (tried to change the meta_type at paste time but no luck). At least the meta_type/icon should change to provide a visual cue. - provide tool(s) to find impact of changing a reference. Provide a link from a reference object to the original. Provide a link from an object to its several references. Comments and experiences are welcome. C U! -- Mario Valente

2 2

Bravery & Zope 2.5 Testers
by Matthew T. Kromer 16 Jan '02

16 Jan '02

OK, I am formulating a hypothesis that if you replace ExtensionClass.h in Zope 2.4 and Zope 2.5 with the following one: http://cvs.zope.org/~checkout~/Zope/lib/Components/ExtensionClass/src/Exten… (Which goes in lib/Components/ExtensionClass/src/ExtensionClass.h btw) and rebuild zope .... python2.1 wo_pcgi.py and rebuld any other modules you may have which depend on extension class that some of the segfaults could go away. I have one person testing this right now, and am looking for others to prove it. I have *not* been able to reproduce any crashing problems (even Martijn Faassens one) so I can't tell what may be going wrong for sure.

3 5

Re: [Zope] [Bug] "bobobase_modification_time" unreliable to catalog
by Casey Duncan 07 Jan '02

07 Jan '02

This behavior is logical if unintuitive. I propose that we can kill two birds with one stone to fix this: - Add a new method perhaps: getModificationTime() to the API of SimpleItem or even Persistent that returns the ZODB modification time or if the object has been changed, but not yet commited, the current date/time. - Deprecate bobobase_mod_time and perhaps even omit it entirely from Zope3. This will fix the aforementioned bug and get rid of an API anachronism. Thoughts? -Casey --- Dieter Maurer <dieter(a)handshake.de> wrote: > I just discovered that the value cataloged for > "bobobase_modification_time" > is often wrong: > > The cataloged value is not the time of the > current modification > but that of the previous modification. > > I expect that this is because > "bobobase_modification_time" is updated > when the transaction is commited while the values > to be cataloged > are determined before the commit. > > Do not trust the cataloged > "bobobase_modification_time"! > > > Dieter > > _______________________________________________ > Zope maillist - Zope(a)zope.org > http://lists.zope.org/mailman/listinfo/zope > ** No cross posts or HTML encoding! ** > (Related lists - > > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope-dev ) > > __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

5 7

Delete or move - who can tell?
by Tom Bech 07 Jan '02

07 Jan '02

Hi! Is there really no way for an object to know wether a call to manage_beforeDelete is the result of a delete or a move operation? I've tried to override _notifyOfCopyTo and setting an internal variable based on the op parameter, but alas it's not called when moving the parent... I have another class of objects which must not be cloned (sitewide unique) and I have overridden _CanCopy to avoid this, but again it's simply ignored when the parent is cloned... Any suggestions? Tom

6 5

security.declareProtected doesn't always work?
by Martijn Faassen 04 Jan '02

04 Jan '02

Hi there, I have some issues with using declareProtected() outside product classes (deriving from ObjectManager or SimpleItem). An external method example that _does_ work, taken from the ZDG: import Globals import Acquisition from AccessControl import ClassSecurityInfo class Book(Acquisition.Implicit): def __init__(self, title): self._title=title # Create a SecurityInfo for this class security = ClassSecurityInfo() security.declareObjectPublic() security.declarePublic('getTitle') def getTitle(self): return self._title Globals.InitializeClass(Book) # The actual external method def GetBooks(self): books=[] books.append(Book('King Lear')) books.append(Book('Romeo and Juliet')) books.append(Book('The Tempest')) return books Now replace the line "security.declarePublic('getTitle')" with something like "security.declareProtected('View', 'getTitle')", and suddenly nobody is allowed to call getTitle() on a Book object anymore. This doesn't only occur in external method code, but also in product code, which is where I ran into it. Take for instance this class: class TOCEntry(Acquisition.Implicit): security = ClassSecurityInfo() security.declareObjectPublic() def __init__(self, id): self.id = id security.declareProtected('View', 'render') def render(self): """Render entry. """ return self.id Globals.InitializeClass(TOCEntry) 'render()' can now never be called from a DTML method or a ZPT template, while using 'security.declarePublic('render') does work. One gets errors like this: """ Error Type: Undefined Error Value: You are not allowed to access render in this context not found in 'entry/render', at line 8, column 3 """ which doesn't look very grammatical either. :) I haven't been able to figure out what causes the difference; classes that are initialized with Zope don't seem to have this problem, but this little class does. I've tried inheriting from Persistent or SimpleItem.Item but that doesn't seem to make any difference.. So what's going on? Am I missing something? If so, where is this documented? Martijn

4 6

increase penis size by an average of 26% sex drive also
by River 31 Dec '01

31 Dec '01

3 2

Re: [Zope] ATENCION COMPATRIOTAS
by Dirk Datzert 31 Dec '01

31 Dec '01

I need to say that the email with the subject above came not from me or a member of Rasselstein-Hoesch. The eMail-Adresses aren't real and unverified to this mailinglists Dirk Datzert Rasselstein Hoesch IT-Department postmaster and webmaster Un(a)rasselstein-hoesch.de, Argentino(a)rasselstein-hoesch.de, Harto(a)rasselstein-hoesch.de schrieb:

2 1

Patch acceptance. What about this one?
by Adam Manock 28 Dec '01

28 Dec '01

Fellow Zope addicts, I do both name and IP based virtual hosting from a single Apache instance, proxypassing to various different places within Zope. It works great, with or without Apache working mod_ssl magic! Except..... There's a little issue with Zope logging to be solved. Zope logs the IP of the Apache server, not the client. Oops. I might want to track where all administrative logins are really coming from, for example! So I decided to try searching this list before rolling my sleeves up and fixing it myself. Here's what I found: http://www.mail-archive.com/zope-dev@zope.org/msg07600.html Well it appears that Joseph has already solved it for me. Great, gotta love this community. Probably a cleaner patch than what I could have come up with anyway. And I don't have to spend hours digging through the Zope source to get it done! Except... It was written against 2.4.1 I run 2.4.3. It would have been really nice if it had been included in Zope 2.4.next...... Hmm, has anything else changed that I need to be aware of before applying the patch? Lets go to cvs.zope.org and see: First I look at "Diff for /Zope/ZServer/medusa/http_server.py between version 1.26.4.2 and 1.30.36.1". Changes. Looks like some careful inspection of the code and some testing is in store for me. And more porting work next time I upgrade Zope... and next time. I can't help but wonder why something this simple and useful was not just included in Zope 2.4.next? It would have saved me and all the poor fools like me so much duplicated effort... Just another Zope Admin's 2 cents worth...... Adam

5 10