Andreas Jung wrote at 2005-2-20 12:33 +0100:

I can across the following problem while trying to fix the broken FTP service for Zope 2.8:

ObjectManager.manage_FTPstat() tries to access self.manage_FTPlist.__roles__ whose value is ('Manager',') in Zope 2.7. In 2.8 this attribute is not available.

In Zope 2.7 and before, ExtensionClass methods were magic objects. When you used "method.attr", then the method actually used "getattr(method.im_self, method.im_func.func_name+'attr')" to retrieve "attr" (i.e. "attr" where retrieved from the bound object). For the new style ExtensionClass implementation (used from Zope 2.8 on), Jim removed this magic. You can use the "getattr" above to resolve the attribute. -- Dieter

Why do we have __roles__ in the first place? After all, when we declare protections for our classes, we do so with permissions. The answer lies in a terrible mistake I made years ago. Long before Principia, there was Bobo. Bobo originally had a security model based on roles. Objects had a __roles__ attribute and the security model tried to determine if a user had any of the roles on that object. Later, but still long before Principia, we added the concept of permissions. Objects required permissions to access them. Users were granted roles and managers could map roles to permissions. When this change was made, we had lots of software that used the older __roles__ model. To ease transition, we created a computed roles attribute that: - Determined the permission required by an object - Looked at the role-permission map for that object and all of the acquired role-permission maps to compute the roles that had the permission and returned this set of roles as the value of the __roles__ attribute. So far so good. The terrible mistake was to never transition our software away from this transitional hack. Shame on me. Note only did we perpetuate a hack, but, I think, we made the security system more complicated than it should have been. After all, developers declared the permissions required to access their objects, but the run-time system seemed to work with roles. When doing the initial work on 2.8, I hoped to remove this hack, but I wasn't able to. I had enough to do to integrate new-style extension class and I couldn't spend the extra time needed to clean this up. I do still think it would be good to clean this up, although I still don't have time to do this myself. I think Zope 2 will be with us for a long time, so I think cleaning this up would be worthwhile. I would also like to look at backporting the Zope 3 security system to Zope 2. I'm not certain that this will be feasible, but I'd like to look at it for Zope 2.9. The __roles__ hack doesn't exist in the Zope 3 security model, so paorting the Zope 3 security system to Zope 2 would clean up the __roles__ hack. I don't know if anyone is interested in working on either backporting the Zope 3 security system, or on just cleaning up the Zope 2 security system. If so, I'd be happy to provide advise. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org