Re: Proposal: User 'Everybody'

["Alexey Parshin" <alexeyp@gmail.com>]

Do you want group AND personal ACLs or just group ACLs?
Also, if this temp table is large enough (several thousand records) - we really need pconnect implementation. Oh, there is a side effect of temp tables with ACL. If an ACL is changed/added/removed during the session by someone else, we ether need a trigger updating it (expensive) or logoff/logon to see the effect of the change.
BTW, besides class price, class is logically identical to group, isn't it?

2007/4/15, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com >:

I am aware of slow-down effect, and it's the thing that worries me the most.
Off top of my head, one way to at least soften the impact, is to create temp
table with groups _current user_ is part of at login() time. This way at
least
we will not have to look it up on every query that requires access checking.

However, before diving into implementation difficulties, I would like to
see if
there are principle matters - i.e. if there are any problems in terms of
usability
of application itself.

Alexey Parshin wrote:
> The first result of having a group permissions is some slowdown.
> Currently, to check an access, we have to find a single ACL record.
> With the group access - we have to find a group and ACL record
> combinations, and then find if any of the found combinations grants an
> access.
>
> 2007/4/15, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com
> <mailto:ilya@total-knowledge.com>>:
>
>     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
>     group.
>
>     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.
>
>     Comments?
>
>     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
>     permissions.
>     >
>     > --
>     > Alexey Parshin,
>     > http://www.sptk.net
>
>     --
>     Ilya A. Volynets-Evenbakh
>     Total Knowledge. CTO
>     http://www.total-knowledge.com
>
>
>
>
> --
> Alexey Parshin,
> http://www.sptk.net < http://www.sptk.net>

--
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com

-- 
Alexey Parshin,
http://www.sptk.net