| Newsgroups |
gmane.comp.cms.xaraya.devel |
| Organization |
Xaraya |
| Message-ID |
<[email protected]> |
Sorry, been distracted :)
The method is unfinished. It has no bearing on blocks and should be
adjusted to reflect the structure of dataobject masks. I plead leniency
because I wasn't having it be used anywhere yet :)
The access property is a generalization of a security check. I used it
in blocks, but as you know that is coincidental. Since all blocks have
the same mask structure we can essentially reduce that to an access
level, and we add the group access condition on as an adjunct. In fact
we can add more adjuncts to make the check richer, but that is a
different story.
The access property lends itself to be applied on a set of similar
objects,such as are blocks of xarpages. Dataobjects are just another
case where it can be useful. I got sidetracked there mainly for 2 reasons:
1. I am not quite sure where to store the mask (access) information.
Dataobjects have a configuration field which could fit the bill for
instance.
2. I wasn't quite sure how to deal with the objects/items dichotomy.
A simple example would be to add a mask to each of the object's main
methods, allowing us to easily (and dynamically) change access
requirements on each one for creating, displaying etc.
I have to say I haven't really thought enough about the UI handlers as
yet to be able to make any useful comments to that effect.
The secondary agenda here is that successfully applying the access
property to data containers or objects such as DD encourages their
application in other areas. Thus over time we may be able to run all of
Xaraya with a few such container types, such as blocks, dataobjects,
xarpages, articles...
BTW one of the things that this exercise shows up (for me anyway) is
that in some cases we may have shot beyond the mark: the privileges
system in this case may be too finely grained for most real world
situations.
Marc
mikespub wrote:
> On 1/04/2010 11:01, mikespub wrote:
>> Why is the checkAccess method in DataObjectMaster related to blocks ?
>> There doesn't seem to be any place where this is actually used today,
>> and I don't see the link with blocks either.
>>
>> Note: I don't really have a problem with having such a method to check
>> access for object actions (view/display/create/update/delete/config/...)
>> in general for the future, e.g. to replace the xarSecurityCheck(...)
>> calls in the object UI handlers with simpler $object->checkAccess(...)
>> calls.
>>
>> But then the link to blocks would need to disappear, and we'd need to
>> expand the number of actions too ;-)
>>
>> So what was the idea here ?
>>
>> Mike.
>
> In the meantime I've started calling checkAccess() in the DD UI classes
> too, but still using the existing xarSecurityCheck() calls inside that
> method. That way we can change how access is determined later on if we
> want to.
>
> The existing GUI and API functions still rely directly on
> xarSecurityCheck() - some day I'd like to remove the duplication of
> code and only keep them as wrappers for corresponding OO methods, so
> we can clean them up then.
>
> And I'd like to get rid of the *DynamicData*Field* masks at some point
> too, because they don't really show much use at all in practice...
>
> What do you think ?
>
> Mike.