Hi! I'm feeling that my head could explode sooner or later. But I'll try anyway to sort out that security thing: So what we are building is a content management system (Kontentor) that, unlike the CMF, can have as many "sub-portals" to a portal as you like. We are initially doing this for a university. So there this the main site of the university, with some target-group-specific portals like "studying abroad" or "alumni", and then there are the sites of the faculties (or "schools") (e.g. "School of Business") and institutes, which themselves contain sites for departments (e.g. "Department of International Marketing"). The look&feel ("chrome"/"skins") and basic site layout should be enforced globally. There is a role model with "Editors" and "Reviewers" (a bit simplified, but it will do for the example). People can hold these roles for branches in the tree, e.g. somebody could be Reviewer and Editor for the Marketing Department, but only Editor for the Business School site. In addition, he/she could also be an Editor in a completely unrelated branch, let's say in the Computer Science Department. So these are the security-relevant use case that I have to deal with: 1. An Editor for anything on any branch in the tree should be able to SEE the managementButtonBar on top of the site when logged in 2. An ordinary visitor of the site should NOT SEE the managementButtonBar, not even if he/she calls the object's URL directly 3. On the sites the Editors are responsible for, they should see and be able to use in-site management buttons/icons like "move up" or "delete" for all elements they are authorized to edit (i.e. NOT the basic elements that are pre-configured by their "parent" site, like site-wide menu bars etc.). In terms of actual coding, I do not want to have to check for security, just do things like "<dtml-var managementButtonBar missing>" or try/excepts in Python. If I have to hard-wire things like "if user is Editor then display", I won't be able to change the names of the roles etc. later. Let's say we have a security model that checks like this: "If the current user has a role that is linked to my permission, and he has that role for the container I am in or for one of its parent containers, then grant access!". That's how we all thought the Zope security model should work. So if I am an Editor in the Marketing Department, I can edit all local elements whose "manage_edit" method is bound to a permission "Edit Content Object", which is globally bound to the "Editor" role. Even though I have the Editor role, I can NOT edit objects of the same type in other branches of the tree (e.g. the Computer Science Dep.) or up in the tree (i.e. on the root level of the Business School). Fine. So if everything that seems to be broken in the security model is fixed, number 3. is partly doable. But let's go to the rest of the use cases, and a missing aspect in case 3.: How would I normally do No. 1? I'd bind the "view" permission of the managementButtonBar to the Editor role. That way I can say "<dtml-var managementButtonBar missing>" in the index_html, and voila: an ordinary user would not see the buttons, but my Editor would. Yes, but only if he is an Editor in ROOT (that's where the managementButtonBar DTML Method is at home). If I choose to NOT protect the managementButtonBar directly but to do things like "<dtml-if AUTHENTICATED_USER.has_role('Editor')>", the DTML Method will be callable by anybody directly. This may not be an issue for the management button bar, but it would for more security-relevant methods. The crucial point is: Everything works fine if I can bind my roles to local instances of the Product, e.g. a local "faculty" instance. Then, the Editor is editor for THAT instance. But as soon as I want to use acquisition for some of the display methods, those will not work as needed. So what we seem to need for those is the possibility to say "any Editor on any level in the hierarchy should be able to use this", or as an alternative, "faculties (or whatever other sub-object we have) can acquire this method as their own and make it available to their Editors, but if the object is called directly, it is protected". Probably the only way of doing most of this with the current security model is having myriads of Roles, like "Editor of Business School" or "Reviewer of Computer Science Department", and putting all the users into the ROOT folder. That's rather ugly ... O.k. Have I lost all my readers now? If not, I'd like to hear what you think ... ;-) Joachim