Re: Question on access levels for blocks

"[email protected]" <[email protected]> Tue, 06 Apr 2010 13:11:01 +0200
Newsgroups gmane.comp.cms.xaraya.devel
Organization Xaraya
Message-ID <[email protected]>
Looks good.
Small question  Assuming item access is only controlled in the latter 
part of the page, perhaps it would make sense from a usability pov to 
signal clearly that choosing no conditions gives access to all items.

Is item access completely separate from objects access? In other words 
can I see all items even if I can't display the object? Guess so. 
Although I wonder if that makes sense in real situations.

Wonder how much of this scheme we can package and put back into the 
access property. Can be useful in other cases.

Marc


mikespub wrote:
> 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 ;-)