Help with permissions

On Wed, 7 May 2008, David E. Wheeler wrote:
> The only types of groups that affect document/template
permissions are:
>
> * Story/Media/Template groups. Almost no one uses
these, as it'd be hard
> to keep objects in them.
> * Workflows.
> * Desks.
> * Categories. At least with these, they inherit their
permissions from
> parent categories.

Hmm, maybe I've misunderstood something or am out of date,
so my last message might not be...based on correct
assumptions..

On Wed, 7 May 2008, David E. Wheeler wrote:
> On May 7, 2008, at 11:06, Schults, Chris wrote:
>> I did try restricting by parent category (as
suggested above), but this
>> doesn't seem to work. For example, I changed the
permission for
>> /community/ to DENY, but my user can access active
assets in
>> /community/events/ and /community/kids/.
>
> Once you've set the permission for a category, any
*new* subcategories of
> that category will inherit its permissions. Existing
categories will not be
> changed.

Oh.... uh, nevermind....

On May 9, 2008, at 00:51, Scott Lanning wrote:

> (As a possible corollary of the above, [2]
> it should (possibly) be possible to specify not just a
grouping of
> permissions but a hierarchy of the objects with
explicit rules for
> how the permissions are inherited.)

Don't really follow you here.

> [1] which is another problem: the permissions are
sometimes
> embedded in the UI, c.f. `grep -r chk_authz comp`
> (or `grep -r chk_authz lib/Bric/SOAP/`),
> rather than integrated into the API.

Yes. Wasn't my idea, though the implementation is mine.
Sorry folks.  
My insistence that Christian put the enforcement of
occurrence  
specifications into the API, BTW, made integrating it into
the rest of  
the app easy. It pretty much just worked.

Best,

David