I'm looking for a way to run a function after a module has been completely installed.
Right now I'm trying to apply permissions to roles programmatically when the module is installed, but since the permissions supplied by the module have not yet been parsed into drupal, i'm getting some errors.
So what I would like to know is if there is function/hook of some sort that I implement in the module when it gets installed after the permissions are already parsed.
The following methods don't work
hook_install() ....
hook_installed is called before drupal parses the permission supplied by the module
hook_perm()..
won't work for the same reason. i'm trying to apply permissions that are in the hook_perm so for sure drupal does not yet know about them
Here are some workarounds that I can think of...
One option that will probably work is to install everything with an install profile. and have the persmission applied after all the modules are enabled.
another option would be to create a script that will enable the module and then call the permissions functionality, but this would defeat the whole automation of drupal.
I'm just wondering if there is a simpler, cleaner solution?
Cheers
Comments
hook_enable() and set a flag
hook_enable() and set a flag once the permissions have been set up so that it's not done again
or could use hook_init() in the same way but a bit of a sledgehammer approach
TBH I think hook_perm() is only invoked here http://api.drupal.org/api/function/user_filters/6 and here http://api.drupal.org/api/function/user_admin_perm/6 (the latter being the permissions page).
This is what actually does the business of updating the role permissions in the database after the admin has fiddled with them: http://api.drupal.org/api/function/user_admin_perm_submit/6. Works for the 2 cases - perms for all roles are being set (admin/user/access) or perms for just role n are being set (admin/user/access/n).
So you could probably just use hook_install() anyway... If you want to find out what permissions your module offers then you'd have to force load the .module file (module_load()) and invoke the perm hook by hand. But you should really know that info without having to ask the module!!
gpk
----
www.alexoria.co.uk
gpk
----
www.alexoria.co.uk
hook_ enable is half the ticket
Thanks for the reply. I wasn't aware of the hook_enable();
hook_enable() seems to be for the enabling of a module. It would be really useful if there was a hook_installed() for the the installation purposes. b/c enabled != installed
Regarding permissions, I already know what permissions my module is offering, I just want to apply them to the roles.
I programmatically apply the permissions to roles by executing the "user_admin_perm" form (I think is the most simplest, elegant and efficient way without messing with db code, when in doubt do it the way drupal does it!). But if the permission is not yet known (offered) to drupal and then I drupal_execute() the form it won't validate, because the permission was never on the form. This happens if the form is executed in the hook_install() or hook_perm() of the module.
After giving some more thought, hook_enable() is just the ticket. At least for permission purposes.
Thanks.
Ah I see :) sounds like
Ah I see :) sounds like you're nearly there :) :)
I guess doing it with drupal_execute() you don't have to worry about previously-granted permissions as that would be handled automatically. Nice :)
gpk
----
www.alexoria.co.uk
gpk
----
www.alexoria.co.uk
It's not so simple.
It's not as simple as it sound. natrually with drupal there are some kinks that have to be ironed out before things works the way you want them to...
I plan on making a howto soon, it should explain howto programmatically assign permissions to roles using the form
hook_update_n should run
hook_update_n should run after a module is completely enabled and only once.
Also as for permissions, these days this is best handled by exporting the permissions to a features and let features take care of assigning the permissions or updating them as may be necessary.
No - that's incorrect, the
No - that's incorrect, the schema_version in {system} table is always set to the highest available in the modules hook_update_n's and the updates are never ran (7.x)