Now that I've had breakfast and thought about this a little more, I see there is broader issue: how to handle the special needs of objects that are private to a product. My product is an event scheduler. (Terry, who started the "object icons" thread, may have a different situation. Jump in and tell us about your product, Terry.) The Scheduler product registers an catalog-aware Event class so user's can define scheduled events. The product keeps track of all Events in a ZCatalog "Schedule". Now, Schedule is a persistent object and has a class definition, but the one and only instance is created by the product and load time, if an instance doesn't already exist. The Schedule has some special usage requirements: 1. There should be only one instance. That's why its class is not registered. 2. It probably shouldn't show up on users' navigation bars and folder lists. This probably is not a problem, because Schedule has a unique meta-type. But that's not a watertight solution. A standard method for marking it invisible would be better. 3. If and when it does show up (as on the manage_main menu) it should be identified with the product (to avoid the "Whaz dis?" confusion). That's why I want it to have an icon that shows it is part Scheduler product. 4. No one, not even a manager, should be able to delete it accidently. You can make an object undeletable by putting its ID in the list of reserved names, but I have found, during development of Scheduler, that this hack causes more problems than it's worth. I might settle for letting be deleted by a manager. 5. When the product is deleted (I mean really deleted, because you don't want to use it anymore), the Schedule should be deleted too. Failing this, it should at least be deletable (an iffy situation, if you use the reserved_names hack). On the other hand, if you are just updating the product code, you probably don't want to delete the Schedule object. It may contain scheduled events. This is complicated by the fact that when you load a product, Zope first deletes the old product. So a manage_beforeDelete method can't distinguish between a "real" delete and a code update. I've also discovered that any error in a product's manage_beforeDelete method makes the product not only undeletable, but (because of the implicit delete) unupdatable (un-update-able)! (Hmmm. There's an idea. You could make any object, including the Schedule, undeletable by giving it a manage_beforeDelete method that raises an error.) 6. The Schedule need to have a "well known" ID (I think). This is for use in the default_catalog property of the events. I wouldn't want someone to change the ID of the Schedule arbitrarily. This may be the same problem as accidental deletion. Anyway, I thought I'd mention this use case, so that changes to the Zope product API at least don't make implementation of such products any harder than they already are, and perhaps make them easier. Got any suggestions for the short or long term? -- Loren