Methods to access properties of the account of the logged in user
This deals mainly with retrieving information about the user that is currently logged in. There is one exception: a user that is NOT logged in can still have a $USER object, but there are no privileges in that case. The special user_id in that case is 0.
The constructor reads the important data from the database. This includes things like the full name of the user and the email address. This information is stored in the object and can be used, e.g. $USER->email. This information is basically copied from the table 'users'.
Furthermore, any properties for this user are retrieved from the table 'users_properties'. All properties are stored in an array. These can be used directly via $USER->properties['foobar'].
Access Control
Finally we deal with access control. This has become quite complex but still managable (I hope). There are six tables dealing with acl's:
All bits '0' is a special case: this is the default (nothing allowed) and hence does not have to be stored: the mere non-existence of permissions implies no permissions.
All bits '1' is also a special case, dubbed 'ROLE_GURU'. If an ACL has this value, it means that all current (and future) permissions are granted. A user with ROLE_GURU can do anything.
Of the six tables, only the first one (acls) is read immediately in the constructor. The others are read on demand. This is done by initially setting the corresponding cache variable to NULL. If the table has been read, the variable will always be of type 'array', even though that array may be empty (indicating no permissions).
The permissions from the ACLs are combined between the user's acl and the optional group-acls. Only the combination of user and group permissions is cached in order to save space. This is done by OR'ing the permission bits. Note that the condition all bits '0' is not stored, also to save space.
There are some functions to test for individual permissions:
The effect of this call is as follows. First the routine checks the (already cached) intranet-permissions at the site level. If access is granted at the site level, there is no need to look any further because obviously this user has access to this intranet (private area) and all other current and future intranets. If not, the routine looks at intranet permissions at the area level. The first time this will trigger reading and caching the table for area-level permissions. In this case (intranet-access), the area-level permissions provide the definitive go/nogo for this user (there is no point in having intranet-access-permissions at the node level).
Note that the 'lower' ACL is only checked if the 'higher' does not provide answers. This saves unnecessary trips to the database.
Note that this works much the same for the other has_xxx_permissions(): first the site-level is tried, then the area-level and finally the node-level (when applicable).
ACLs for modules
Access to the CMS itself is fairly fine-grained. The permissions are stored in the fields 'permissions_nodes' in the tables 'acls' (site-level), acls_areas (area-level) and acls_nodes (node-level). These permissions basically deal with the page manager (the piece de resistance of the whole system).
However, there are modules that can be linked to nodes, e.g. a chat or a forum or an agenda which also require autorised users and permissions. These permissions are stored in three tables: acls_modules (site-level). acls_modules_areas (area-level) and acls_modules_nodes (node-level). This works pretty much the same as the permissions for the CMS itself, be it that there is an extra parameter, namely the module_id.
Once again, the permissions are only read when necessary. I.e., if the site-level already grants a permission, the area and node level are not read from the database. This saves time and space.
Roles and permissions
Permissions are indivial flags that allow or disallow a certain feature, e.g. 'adding a page to a section'. In order to keep these permissions manageable groups of permissions are combined yielding a limited number of 'roles'. A 'role' is a combination of 1 or more permission bits. Assigning permissions (in the user account manager) is done by assigning these 'roles' to a user, either sitewide, areawide or per node. These roles are dubbed sitemaster, areamaster, sectionmaster, pagemaster and contentmaster. The 'higher' roles incoporate the 'lower' roles: permissions of a sectionmaster include those of a pagemaster and a contentmaster.
Located in /program/lib/useraccount.class.php (line 254)
get pertinent user information in core
Note: We used to have a bool named 'high_visibility' in both the users table and this class. That changed with version 0.90.4 (April 2012) and we now have a field and variable 'skin' which is a varchar(20). The values were mapped as follows: high_availability=FALSE -> skin='base' and high_availability=TRUE -> skin='textonly'. The extra test for the existence of $record['skin'] was necessary for the case where the user wanted to upgrade from 0.90.3 to 0.90.4 where 'skin' replaced 'high_visibility'.
retrieve acl-data from table into a sparse array
determine user's permissions for an area
this looks at the area-level permissions for manipulating nodes and areas. However, we first look at the site-level permissions. If those already satisfy the request, we return immediately. If not, the permissions are fetched from the table acls_areas or from the cached data. We only fetch the data if it is really necessary.
determine user's permissions for an intranet area
this looks at the area-level permissions for intranet areas.
determine user's permissions for a job
determine user's permissions for a module at the area level
this looks at the area-level permissions for manipulating nodes and areas. However, we first look at the site-level permissions. If those already satisfy the request, we return immediately. If not, the permissions are fetched from the table acls_modules_areas or from the cached data. We only fetch the data if it is really necessary.
determine user's permissions for a module at the node level
determine user's permissions for a module at the site-level
this looks at the site-level permissions for manipulating mdules. The permissions are cached from the table acls_modules.
determine user's permissions for a node within an area
determine user's permissions for the site-level
this looks at the site-level permissions for manipulating nodes and areas etc. The permissions are cached from the table acls.
determine whether the user has administrator privilege
If this user has access to the admin startcenter, she is considered an administrator. Further access depends on the other bits in the job permissions, but at least she is allowed to enter the system via admin.php.
determine whether the user has administrator privilege for pagemanager
This routine determines whether a user has any privileges at all for the page manager. This is true in the following cases:
a convenient routine to construct a selection of acls
this constructs a where clause of the form '(acl_id = 1) OR (acl_id = 2) OR (acl_id = 3)'
Documentation generated on Tue, 28 Jun 2016 19:12:29 +0200 by phpDocumentor 1.4.0