Hi! The differentiation of the 'contents' and 'add' attributes of browser:containerViews seems weird. To actually 'add' content the permission which is set for 'contents' nescessarily has to be granted to the principal. To put more formal: not permission('contents') => not permission('add') All Principals excluded from 'contents' are excluded from 'add'.
A consequence of this is: Each principal, that you want to grant the permission to add, gets the Cut/Insert/Delete-menu and is able to delete content, because this menu is controled by the 'contents' attribute. So it is impossible to distinguish members (which can add) and editors (which can cut and delete). To include a principal to 'add' you nescessarily have to include him to 'contents' and its cut/delete-menu. An Example: <containerViews for="paradigm.categorydb.interfaces.ICategory" index="zope.View" contents="paradigm.EditCategory" add="paradigm.AddCategory" /> paradigm.AddCategory is granted to members, members can add content. paradigm.EditCategory is granted to Editors, only a few editors can delete etc. contents. With this setting a member with granted paradigm.AddCategory can *not* add content, but is prompted to the login form. To let a menber add content I have to change the registration to: <containerViews for="paradigm.categorydb.interfaces.ICategory" index="zope.View" contents="paradigm.AddCategory" <---------------- add="paradigm.AddCategory" /> But then the member can has the right to delete etc. But maybe only my application is "weird". I don't want all folks be able to delitte, i want them to add! ;) I want stable content with lots of relations... Regards, Christian _______________________________________________ Zope3-users mailing list Zope3email@example.com http://mail.zope.org/mailman/listinfo/zope3-users