Re: Question on access levels for blocks

On 3/04/2010 19:25, [email protected] wrote:
>...
> Oh you're not missing anything, you're raising a valid point.
> When I designed the group access thing I made a vague assumption that if
> one wanted more than 1 group one could create a common ancestor group,
> That's why the code contains an isAncestor rather than an isParent call.
>
> But perhaps you are right: if we add ancestors for such a purpose we
> load up the roles tree visually, whereas if we allow more than one group
> to be chosen in the UI, the choices get hidden away from sight wherever
> it is we store the mask data.
>
> Feel free to modify:)
>
> Marc

OK, the access GUI is now split off from the modify GUI function, and
admins can now override the default privileges for each object and
specify which groups get which access levels individually.

So you can e.g. say that some users can display + create, but not
modify - even though the normal sequence of access levels would be
display < modify < create.

The initial set of access levels is calculated based on the existing
privileges, and you can always go back by unchecking the "Override
access rights" checkbox again.

And I also added content filtering by group, e.g. to automatic filter
out items based on some property value in views.

Not all of this is reflected in the GUI/API functions yet - the main
place where you'll see the difference is in object lists for now...


Mike.
P.S.: if any of this sounds like submitting articles or filtering by
article status or whatever, that's probably just a coincidence ;-)