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
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
