Content permissions – system description
The content rule table, the object catalogue, precedence of user and group rules, the endpoints and the super-administrator-only access.
Overview
Content permission (layer 3): WHO (user or group) may see WHAT (object type + key) for WHICH values. Table names carry the installation's own prefix in the database; the table is permission_scope (effect = 'allow'). Object masters are read to resolve labels.
Object catalogue (catalog())
| Area | Object type (key) |
|---|---|
| global | company (company_id), user (user_id – recorder), subscription_usage (user_id – whose usage is visible) |
| invoice | invoice_customer (customer_id), invoice_supplier (supplier_id), invoice_type (invoicetype_id) |
| event | topic, event |
| statistics office | ksh_settlement, ksh_dataset (geo) |
| storage | storage_account, storage_create (account_id) |
Endpoints
scope.list (one row per subject), scope.form, scope.objectsearch, scope.valuelist, scope.valueadd, scope.valueremove, scope.valuebatch, scope.delete (all rules of the subject). Values can be added and removed one by one or in bulk with a live search.
Evaluation
getAllowedScopeValues($object_type, $scope_key): super → unrestricted; if the user has their own rule, only that; otherwise the group's; if neither → unrestricted. Allow values only. getAllowedScopeTexts() does the same for text values (user and group together).
Permissions
- Every endpoint requires
isSuper(); in the seedlistisUNMAPPED,add,edit,deleteareSYSTEM. - The "Add" button follows
canAction(add); thedebugswitch followscanAction(debug), but the controller passes the list SQL to the template unconditionally.