I've been reading the description of this problem and have been wondering about a few things... Mainly I have questions about "Taking Ownership". This permission will need to be kept from almost everyone. For starters since a user gains the "owner role" whenever they take ownership of an object this can be used to gain complete access to absolutely anything they can take ownership of. Does the existing owner lose the "owner role" when another person becomes owner? I don't think so currently. People with the "owner role" are allowed to delegate and give this "owner role" to others, the _exact_ opposite of the model for moving "owner" itself which can only be taken. This is bound to cause even more confusing. Wouldn't it be better to actually dump the whole concept of "owner role" and have a single coherent ownership system? Then there would be no confusion. The whole "owner role" seems to be predominately for delegation, but it _already_ works differently from normal permissions in that the person who has the owner role for any particular object isn't a set property of the user, but rather a mix of the user and the actual object. It would make sense to me to divorce the normal permissions system (in which a user has certain set roles according to their acl_user settings, regardless of where they are in the subtree) from the ownership system (in which the permissions the user has are not absolute). Shouldn't "owner" have to be given away as _well_ as accepted? I understand why it has to be accepted, otherwise you could script your objects to pass themselves to a person with more authority and then run themselves. Acceptance would be difficult in that currently everything to do with ownership is atomic, but if it was introduced there would be no need to have a "Take Permissions" permission that needed to be jealously guarded, you'd return to trusting the people themselves instead of being draconian and paranoid. Mainly I see cases of virtual hosting in which the leader of a certain web-project is leaving and wants to pass on ownership to his successor, someone who's also been working on the project but doesn't have as high permissions. Since it's virtual hosting neither has superuser permissions, neither has "Take permission" permissions. Given the suggested model they would have to petition the superuser to move the ownership over. (I presume that's going to be possible for the superuser?) If you had 500 projects running the superuser shouldn't have to deal with this kind of thing, it should be possible for the people to do themselves without having to have an extremely dangerous permission. Unrelated but still permission stuff... Is management of the permissions planning on changing? It's a different problem, but I was planning on implementing a "project" system in which people were able to become members of projects which would give them specific permissions within the subtree that housed that project. This isn't feasible within the existing security framework as you have to set up every project as a separate role, disallow all access to that role except in the directory given. There is a _lot_ of messing about with checkboxes and you can't automate it easily. With (say) 100 projects you'd have a _lot_ of trouble searching through the permissions screen, especially if you needed to add new roles and they ended up in the middle of all the project specific roles. It'd be very confusing. What I was planning on doing was making a "projects" property for users, just a list of which projects they were members of and then in the header of every dtml page within a project check that that projectname was contained in the list else redirect to a safe page. This would work, but it wouldn't protect non dtml objects. I suppose the proper thing to do would be to create a "project folder" object that checked the users membership of that project as well as using the normal zope security. Anyone got any other suggestions? -- Evan ~ThunderFoot~ Gibson ~ nihil mutatem, omni deletum ~ It doesn't count as intimacy until somebody starts crying.