Drupal admin: permissions and HTML entities

Submitted by Frederic Marand on Sun, 2005-08-21 23:07

Permissions defined by modules in Drupal are usually given short names, in plain ASCII-96. Using anything else, like entities, requires caution...

For the upcoming customer support / helpdesk module for a future site, I had defined a set of permissions with names including the > character, in the hook_perm function of the new module.

Such perms appear properly on the admin/access page in Drupal, just as expected. But visually, there is no way to store them: although they can be checked, and Save permissions claims the permissions are indeed saved, at the next display of the same page, they're gone. What the heck ?

A quick look at the permission table shows that the permissions are indeed inserted in the perm field for the chosen rid (role identifiers). Debugging user.module#user_admin_perm() shows that the permissions are retrieved properly, but the match tested to define the checkbox status fails. The code is as follows:

<?php
 $row
[] = form_checkbox('', "$rid][$perm", 1, strstr($role_permissions[$rid], $perm));
?>

What has happened ?

Further examination of the permission table shows that the entity has been stored decoded (i.e. as &gt;) instead of being stored as in the module (i.e. as &amp;gt;). So the test performed by strstr fails, quite logically, because it matches a decoded string against an encoded one.

What is one to do when using Drupal 4.6.3 ? A chat on the developer's channel suggests permissions should only be given simple english names, made up of plain ASCII alphabetic characters without HTML entities.

For most cases, just supplying the permission in hook_perm using the decoded entity will be the simplest option if the unusual name is to remain, but it may not be simple to type : Think about using &amp;nbsp; to avoid word wrap in the permission name. Do you know how to type this in your favorite text editor ? It can appear as &Acirc; because its UTF-8 representation is 0xC2C0, where C2 happens to be the iso-8859-1 value for &Acirc;. Luckily, for &amp;gt;, the simple &gt; can be used.

Another option would be to patch user.module, by testing against html_entity_decode($role_permissions[$rid]) instead of testing against just $role_permissions[$rid]. But as the core is currently mostly frozen until 4.7 comes out, this will have to be a site-local patch, and there might be a better solution in the wings.

Till next time...

Tagged for , , and in Technorati.