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
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
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).
shows that the permissions are retrieved properly, but the match
tested to define the checkbox status fails. The code is as follows:
$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
>) instead of being stored as in the module (i.e. as
&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
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
&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
Â because its UTF-8 representation
C2 happens to be the
iso-8859-1 value for
&gt;, the simple
> can be used.
Another option would be to patch
by testing against
instead of testing against just
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...