Getting the user’s group ID and type

The following organized list describes the user groups in Joomla! 1.5 in a way in which we are all probably familiar. Each of these groups has an ID and a name; these are the group’s ID and type respectively.

This recipe explains how to find the group ID and group type of the current user. Note that the hard coded group IDs should not generally be used for access control; for this it is best to take advantage of the JAuthorization class. For more information, refer to the Joomla! API site: http://api.joomla.org/.

Dynamic permissions

There is no administrative functionality that allows the modification of groups. It is, however, possible to programmatically modify groups and group permissions. Most of the time a Joomla! 1.5 extension will opt to implement its own permission management rather than use the incomplete Joomla! solution.

Joomla! 1.6, in development at the time of writing, promises a complete GACL (Group Access Control List) implementation.

Getting ready

To complete this recipe, we need the JUser object that represents the current user. For more information, refer to the Getting the user recipe covered earlier in this article.

$user =& JFactory::getUser();

How to do it…

The group ID is held in the gid field in the #__users table. We use the JUser::get() method to extract the user’s group ID.

// determine group ID
$groupID = $user->get('gid');

The group type is held in the usertype field in the #__users table. Again, we use the JUser::get() method to extract the user’s group ID.

$usertype = $user->get('usertype');

How it works…

Apart from the obvious format of the data, there is a subtle difference between the gid and usertype fields. The gid field is always populated, where as the usertype field is populated only if the user is not blocked. When dealing with the current user, the user will never be blocked, but when dealing with other users there is a possibility that the usertype field will not be populated. Therefore, we need to be careful that we select the most appropriate field, depending on the context of what we are doing.

The user groups that we have mentioned are maintained in the #__core_acl_aro_groups table, or as it can also be called, the Access Control List Access Request Object Groups table. This table holds a tree structure, as indicated in the introduction of the recipe. What is noticeable is that Public Frontend and Public Backend are both technically user groups. As this is a tree structure, we can use the left and right values to perform all sorts of neat tricks.

The #__core_acl_aro_groups table employs the nested set model: http://dev.mysql.com/tech-resources/articles/hierarchical-data.html.

See also

The next recipe explains how to use the Public, Registered, and Special access levels.

Restricting a user’s access using Public, Registered, and Special

In Joomla! we often define access based on three simple access levels. These levels relate to the user groups described in the previous recipe, Getting the user’s group ID and type. This recipe explains how to use these access levels to restrict access to resources.

• Public (0)
• Registered (1)
• Special (2)

Getting ready

To complete this recipe, we need the JUser object that represents the current user. For more information, refer to the Getting the user recipe covered earlier in this article.

$user =& JFactory::getUser();

How to do it…

The JUser::get() method can be used to retrieve the user’s aid. This is the access level number, as shown in braces in the recipe introduction.

// get access level
$aid = $user->get('aid');

For each resource we want to restrict access to, we must define the required access level. This is normally done in a database TINYINT(3) field named access. This can then be used to restrict the access using a database query (used when listing)…

// get the DBO
$db =& JFactory::getDBO();
// prepare access field name
$access = $db->nameQuote('access');
// restrict query by access level
$where = "WHERE $access <= " . intval($aid);

…or when viewing a single record. Note that ALERTNOTAUTH is a core translation string, which in en-GB is equivalent to You are not authorised to view this resource.

// make sure the user has the necessary access rights
if ($table->get('access') > $aid) {
 JError::raiseError(403, JText::_('ALERTNOTAUTH'));
 jexit();
}

How it works…

A good example of this in action is the content component. If we take a look at the article manager, we can see that there is an Access Level associated with each article that determines which users can access the article.

These access levels are relatively primitive and we don’t have any bona fide control over them. So how do they translate into concrete user groups? The following table describes the seven user groups and the guest group, and shows how these relate to the access levels:

User Group	User Group ID	Access Level	Access Level ID
None (Guest)	0	Public	0
Registered	18	Registered	1
Author	19	Special	2
Editor	20	Special	2
Publisher	21	Special	2
Manager	23	Special	2
Administrator	24	Special	2
Super Administrator	25	Special	2

See also

The previous recipe explains how to work with the user group ID and group type. This can also be useful for dealing with access control.

Getting the user’s parameters

User parameters provide a mechanism for including additional user data without the need to modify the database. The core user parameters are defined in the XML files located in the administratorcomponentscom_usersmodels folder.

Getting ready

To complete this recipe, we need the JUser object that represents the current user. For more information, refer to the Getting the user recipe.

$user =& JFactory::getUser();

How to do it…

To retrieve a parameter we must first know the name of the parameter we want to retrieve. One example of a common parameter is timezone. This is an integer that defines the hours offset from UTC (Coordinated Universal Time), also known as GMT (Greenwich Mean Time) and Z (Zulu).

To retrieve a parameter, we can use the JUser::getParam() method.

$timezone = $user->getParam('timezone');

It is also possible to provide a default value. This is useful especially if the user we are dealing with is a guest because guest users do not have any parameters defined by default.

$timezone = $user->getParam('timezone', '0');

How it works…

A user’s parameters are represented as a JParameter object. We do not have to interact directly with this object because JUser will do this for us.

A minor problem with this method is the default value. Technically the XML files define the default values, but by default these XML files are not loaded by the JUser class. Therefore, the XML defined default values are not employed. One way to overcome this is to interact directly with the JParameter object. The next section explains how to do this.

There’s more…

The JUser::getParamters() method allows us to directly access the user’s JParameter object. Note that we must use =& when assigning the return value to a variable. If we do not and we are using a PHP version prior to PHP 5, we will inadvertently create a copy of the returned JParameter object.

// get parameters with XML definition file loaded
$params =& $user->getParameters(true);

When we retrieve the JParameter object there are two optional parameters. The first parameter $loadsetupfile determines whether or not the XML file that defines the user’s parameters should be loaded. Loading this file gives meaning to the data and also provides default values for defined data.

For information about the second optional parameter, refer to the recipe, Extending and editing user parameters.

To retrieve a value, we use the JParameter::get() method. We pass two parameters to this method—the name of the parameter we want the value of, and the default value to return if the parameter does not exist.

// get timezone (hours UTC offset)
$timezone = $params->get('timezone', '0');

See also

The next recipe, Setting the user’s parameters, explains how to set a value in the user’s parameters.

Setting the user’s parameters

User parameters provide a mechanism for including additional user data without the need to modify the database. The parameters are defined in the XML files located in the administratorcomponentscom_usersmodels folder.

User parameters are not restricted to the parameters defined in the XML files. It is perfectly acceptable to add additional parameters.

Getting ready

To complete this recipe, we need the JUser object that represents the current user. For more information, refer to the Getting the user recipe.

$user =& JFactory::getUser();

How to do it…

To set the value of a parameter, we use the JUser::setParam() method. This method requires two parameters—the name of the parameter we want to set and the value to which we want to set the parameter. For example, we could change the user’s editor preference to use no editor.

// set value of someparameter to some value
$user->setParam('editor', 'none');

There’s more…

If we have retrieved the JParamter object directly from the user, we can alternatively use that object to set the user’s parameters. For information about retrieving the user’s parameters, refer to the previous recipe, Getting the user’s parameters. To set data in the JParameter object, we use the JParameter::set() method.

// set value of someparameter to some value
$params->set('editor', 'none');

See also

The previous recipe explains how to get a value from the user’s parameters.