Lex Berezhny writes:

Hello,

I am working on a voting system for my schools' computer science classes. Students in each class will vote for the student of the week. The student heirarchy is represented in the Zope filesystem by folders: at the top is the class folder, then period folders and finally student folders. Each student folder contains an acl_users with that students login information.

An important feature in this voting program is to authenticate students when they vote, so that they are not able to vote in classes/periods they are not in. .... This design does not look good:

1. It tightly associates a student with a single class, which is not good (I think). Why should it be impossible that a student does not belong to several classes? 2. It does not take into consideration, that a user defined in a folder F's "acl_user" has only access to objects in the subtree rooted in "F" or to objects accessible by "Anonynous". Or, to say it differently: outside of "F" is the use "Anonynous". I would go for the following solution: * a single "acl_user" for all students, probably implemented by "ExtUserFolder" or a similar UserFolder Product, which allows to associate additional properties to users. * each user has additional properties, e.g. the list of classes it belongs to, periods(?), ... * a ZCatalog that indexes the relations "student-class", "student-whatever", ... You would not use Zope's security system to protect voting but would provide the security by application code. This code would check, whether the current user is allowed to vote in the current context. The object would use a Proxy Role to be able to do thing, the user normally would not be entitled to do... Dieter