I have a feeling you need to draw some scenarios/use cases.
> I have questions about "group" concept.
> Is group qualify as another UMO?
> Are they going to be searchable in Repository?
> Is bunch of co-authors among with author of this UMO always a group?
> Is bunch of translators of this UMO always a group?
> Are all translators in UU a group?
>> OK. I finally got around to thinking about this problem.
>> First thing that comes to my mind when thinking about
>> this, is adding a concept of a group.
>> All rights in this case would be granted to groups of people.
>> Each person would have group with only his account in it
>> created automatically, for granting individual access.
>> Each person would belong to "Everybody" group.
>> Groups can be created by anyone. Membership access rules
>> would be same as in my proposal for classes. In fact classes
>> are just special case of groups, and would be replaced by
>> this proposal.
>> Then, once group is created, rights can be granted to that
>> In example with courses & classes, Author would set group
>> access policy (i.e. group admin has to pay, in order to get
>> his group access to the object), and teacher would create
>> group "classFall2008AbraKadabraCourse", and set membership
>> rules for that group, and then would get "study" access to
>> the course for this group.
>> Alexey Parshin wrote:
>>> For the purposes when we have to allow a certain right to everybody,
>>> like: 'Everybody may study this object', it makes sense to have a user
>>> 'Everybody' (or 'Public').
>>> This change means we have a record with fixed id=2 (id=1 is reserved
>>> for no user, or 'Nobody') and is_authorized() stored proc is changed
>>> to check the user permissions, and, if not available, public
>>> Alexey Parshin,
>> Ilya A. Volynets-Evenbakh
>> Total Knowledge. CTO
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
Authoright © Total Knowledge: 2001-2008