Re: [Zope-dev] Keyword Indexes causing Keyerrors
Here's what was causing my KeyErrors, and how I solved it, and why I think KeywordIndexes broke. I have a keyword index on the "categories" property of my CatalogAware object. "categories" is a list. def manage_removeItems(self, ids=[]): """ Remove listed items from this category """ for id in ids: ob = getattr(self.Items, id) categories = ob.categories # -- this is the problem categories.remove(self.uid) ob.manage_changeProperties(categories=categories) ob.reindex_object() I solved the problem by switching the problem line to say "categories = ob.categories[:]". What does this mean? I was mutating the same list that was attached to the object. Doing this caused the Keyword Index to break. I assume the reason then is that the index somewhere stored a reference to the "categories" property, not a copy. This means that when I mutated ob.categories, I was also mutating the contents of the index, causing it to get screwed up. The solution would be that keyword indexes store a *copy* of the property they are indexing, not a reference to it. If I'm not mistaken, that means changing line 42 in UnKeywordIndex.py (2.2.4 version) from: unindex[i] = kws to: unindex[i] = kws[:] Although use of deepcopy may be a better idea? -- Email: itamar(at)shtull-trauring.org Web: http://itamarst.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] RE: objectIds accessiblilty and a proposal
-Original Message- From: Dieter Maurer [mailto:[EMAIL PROTECTED]] Toby Dickenson writes: ... protocol specific access rights ... Please No. Zope security is complex enough without having to worry about different security settings depending on how a method is accessed. (And we should have a lower tolerance for complexity when it applies to security) If a user has permission to access a method then he should be able to access it any way (xmlrpc, ZPublisher, DTML, PythonMethods) I agree with you mostly. But it might be a significant difference, whether you access via HTTP or HTTPS or even a protocol that provides trusted authentication. As a matter of principal, authentication issues do not belong in the permissions machinery, but rather in the User machinery. As a matter of practicality, changing the user machinery is also the smallest change that achieves what you want. What if it was possible to specify per-user the level of security required (Basic is ok for some users, another needs https, etc). You could do this today with a custom user folder, but it might make sense to add it to the standard one. Your very-private-method could then be protected by a permission that is only given to users who are configured to require https. This obviously works for normal users, but it applies to anonymous users too The word 'zen' hasnt been used on the list for a while, so ill drop it in here Zope has a standard "Anonymous" user who represents users who do not authenticate. This user has no management interface, and he has a fixed set of roles - this makes him very limited. However, you *dont* *need* *to* *use* *it*. Create your own substitute as a new user (I like to call him "Anon") in the root folder with a blank password. This is useful if you create a product with a feature that you want to make available anonymously today, but may want to authenticate in the future. You could tweak the permissions mapping so that the appropriate permissions are given to the "Anonymous" role, however that leads to alot of re-tweaking when you make the change. A better solution is to create a new role, and grant that role to "Anon". This step (granting special roles to the anonymous user) is the thing you cant do with the regular anonymous user. I hope this helps, ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] 'Subclassing' another product
[Steve Spicklemire] | does that help? Yep. Thanks Cheers, Morten ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns, ZClasses, Specialists: Assigning responsibilities
At 05:13 PM 12/21/00 +1100, Itai Tavor wrote: I think you're right about this being an OrderLineItem. A couple of fine points, however... First, I don't think there needs to be an "OrderLineItemsWithGraphic" specialist, since there is nothing else that would talk to it. It's fine in this case to have the line item classes (either with graphic or without) handle their own UI snippets. UI delegation is for when an object needs to display UI for some *other* object than itself, since you can always use class extenders and other techniques to reshape the apparent class of an object retrieved from a specialist. The interface which other objects deal with is "OrderLineItem", and they simply expect a portion of the form to be rendered, and it's okay for the class to handle that. I got a bit confused here... the UI snippet for uploading a graphic actually comes from the Graphics Specialist. That's fine, but it should be by way of an object that's filling the OrderLineItem role, yes? Or I could eliminate the problem by uploading the graphic from a form displayed by the order line item after it has been added. That's actually what I thought you were doing/intending. Here's the question... how many behaviors are different in the order line item itself? Are you also using fulfillment line items? If the only difference to the order line item is that it references some additional data, then I'd say a single class would be fine. Most of the behavior probably comes in on the fulfillment line item, yes? Again, you can ask your FulfillmentLineItems specialist to create "newLineItemFor(orderLineItem)" and let it decide what kind of implementation to hand back. In this case, it probably will be a different class, while for the order line items, it may or may not buy you anything. I haven't thought of using fulfillment line items... not sure what they are for? An order is considered fulfilled once all items have been shipped, so order line items are responsible for tracking everything that happens until a ShipmentLineItem is created. The order line item for a customizable product tracks the product using state values like 'sent to factory', 'received from factory', etc. So it needs a new set of state values, as well as methods like 'sendManufacturingOrderToFactory'. What exactly does the fulfillment role you're referring to do? Does it do more than a shipment role? Fulfillment would be between ordering and shipping, covering such things as pulling items from the warehouse to customizing them with the graphic. I assumed that an order line item was only meaningful until you have a completed order. You may not need the complexity, but to me it seems like a seperate phase with a very different set of behaviors than what I would think of as an order line item. If I were doing an app like this, I'd at least have some sort of state/status objects to delegate these different behaviors to. But I'd say this could be left to the taste of the chef. :) P.S. By the way, I'm off on vacation later today, and won't be active on the list again for a little over a week. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] LoginManager and PTK
Hi guys, I previously posted a couple of functions that enables users to login at a lower level in the tree-structre than where the actual user folder is. I.e., a user could enter username and password at /a and get redirected to /a/a/a/a/b (the acl_users folder would be located in /a/a/a/a). Now, there is a minor problem, because I can't seem to figure out how to login the user to the actual context /a/a/a/a, except maybe first redirecting the user to /a/a/a/a and then letting the user log in from there.. Any thoughts / ideas? And if you've got a completely different solution, I'd be glad to hear it. =) Thanks. -Morten ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
