Tiger_Acl_Acl

@api · extends Zend_Acl

Tiger_Acl_Acl — the AUTHORIZATION engine (what may you do).

A Zend_Acl subclass that only LOADS policy from data, in override order — it hard-codes no rules. Ported from AskLevi's Levi_Acl_Acl, adapted to Tiger's layout (Core is a package + default namespace, not a core module).

Load order (Zend_Acl is last-write-wins per role/resource/privilege, so order = precedence):

  1. Roles from ini — the canonical role graph shipped in code (core + module configs/acl.ini). Source of truth.
  2. Roles from DB — acl_role rows layered on top (a derived app adds roles by data; existing ini roles are left as-is).
  3. Resources + rules from ini — each unit's default policy.
  4. Resources + rules from DB — loaded LAST, so DB overrides win.

The deny-all baseline, god-mode, and public exemptions are all DATA (core acl.ini), never code. See core/configs/acl.ini.

acl.ini format (per unit): acl.roles.{k}.role / .parent (comma-sep) / .description acl.resources.{k}.resource / .description acl.rules.{k}.role / .resource / .privilege / .permission (allow|deny|removeAllow|removeDeny) * (or 'all'/'') = Zend_Acl wildcard (null).

Methods

__construct()

__construct()

Build the ACL by loading policy in override order (ini roles, DB roles, ini rules, DB rules — last write wins).

isAllowed()

isAllowed($role = null, $resource = null, $privilege = null)

Authorize a role against a resource and privilege (deny-by-default).

Unknown role => not allowed (never a Zend_Acl exception). A user has exactly one role per request (resolved from their org_user membership); callers pass that single string.

  • $role string|null — the role name (null = the Zend_Acl wildcard)
  • $resource string|null — the resource name (null = wildcard)
  • $privilege string|null — the privilege (null = wildcard)

Returns bool — true if allowed