[horde] using horde perms to build apps

[Chuck Hagenbuch]

Quoting Alex Vorobiev <sasha at mathforum.org>:

> 1. am i correct in assuming that permissions are essentially implemented in
> horde as a three-way logical relationship between an object/entity, a user
> or group, and an operation (read, write, etc.)?  does this also mean that
> storage-wise, you may have multiple category records for the same object,
> such as obj_id/user_id/read as well as obj_id/user_id/write?

No. The CategoryObject_Permission object represents one entity that holds all
user/group permissions (of all kinds) for the object. It gets broken up into
different attributes in the horde_category_attributes table, but you don't
worry about that as someone using the API; it is essentially one entity in the
categories system.

Though, the *logical* relationship you describe is pretty much right, yes.

> 2. how would you treat hierarchy relationships with respect to permissions?
> if a given object doesn't have explicitly defined permissions, do you check
> the parent?  is this check recursive?

Right now hierarchies like this are not checked for permissions; they *are*
checked for group membership. If we were to do it for permisssions, it'd be
implemented the same way we do it for groups, and it would be recursive.

> 3.  finally, with object-level permissions generating lists of objects can
> get very expensive.  say, you are generating a list of 100s of tickets for
> display in whups.  do you check permissions on every ticket?  what do you
> think is the best way to scale that?

This is what getCategoriesByAttributes() is for. It lets you very quickly
(single SQL query) get back all objects (of a certain type, or whatever) that a
user has permissions to.

-chuck

--
Charles Hagenbuch, <chuck at horde.org>
They're just looking at a wall of meat.