1

Using a custom module, how can a permission be added to a core/contributed module "group" on the permissions page without hacking the core/contributed module?

Example:
Add custom permission to core module

3

As already said, it would not be a good idea to list a permission implemented by a module together the permissions implemented by another module; it would difficult for users to find the permissions implemented by, for example, custom_module.module, when it is listed together the ones implemented by user.module.

If you really need to change the order used to list the permissions (but then, is it really necessary), then I would suggest to change how the list of permissions is shown: instead of listing them basing on the module implementing it, you could list them basing on different criteria.
To do this, you would need to:

Is it worth doing it? It could be, depending on your customer.
Considering that the first official release for Drupal 7 has been released, and the code for Drupal 7 would change, it is probably not worth doing it. I would rather try to understand why the customer wants to change the order of the permissions listed in the administration page, and explain the reason why changing it is a bad idea; if the customer insists the code needs to be implemented for their own purposes, then I would make him understand that the code should be rewritten when the site passes to Drupal 7, and it is not worth spending time for such changes, when it is possible to use the same time to implement something that it is really necessary.

1
  • I agree, after explaining all this to the client he decided against it. But hook_theme_registry_alter() and theme_user_admin_perm() worked great in the test runs, thanks
    – Laxman13
    Mar 15 '11 at 19:58
2

There's no hook_perm_alter and those permissions are grouped by module, so likely th way would be to get in there would be with hook_form_alter on those forms (there's is per role permission forms along with the main one; not sure if they are using the same form_id).

Should still define the permission via yourmodule_perm so anything else can know the permission exists.

Personally, I'd advised against it; let your permission by where it would be so there's no "I installed this module and can't find the permission! oh, why was the permission under a different module?!!"

2
  • I wasn't too big on the idea either, but a client wanted to know if it was possible so thought I'd ask
    – Laxman13
    Mar 14 '11 at 18:54
  • +1 (only virtual, as I have used all my votes already) for pointing out it would not be a good idea to list the permissions of a module together the permissions defined from another module.
    – apaderno
    Mar 15 '11 at 14:15
1

There are two ways to accomplish what you ask for.

Either through hook_form_alter or by overriding the form's theme function: theme_user_admin_perm.

For a standard contrib module, this wouldn't be a good idea, as people tend to look for a module's permission by browsing for it's name. If your module does some alterations to the standard user permission flow, it might not be a bad idea to show the added permission along with the default ones from the user module.

1
  • Yea, persuaded the client that it's better to leave it under custom module's name for future clarity. Thank you for theme_user_admin_perm, did not know about that one.
    – Laxman13
    Mar 15 '11 at 14:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.