CiviCRM Community Forums (archive)

I see that civix generates menu XML files with the access_arguments property for each menu item.

Being unfamiliar with non-Drupal CMSs, I wonder how (if at all) this property is supported in WordPress and Joomla! installations. 

Is there a way that my CiviCRM-native module extension can limit access to its various features to one set of users or another?

Thanks,
Allen

In the current Joomla integration, one can manage the role-based access-control matrix by going to CiviCRM's "Administer => Users and Permissions => Access Control =>Joomla Access Control". I believe this builds on a native Joomla feature (much like we do in Drupal).

In WordPress, I believe the CMS doesn't standardize the access-control matrix. At one point, I think we hard-coded some policies (e.g. WP admins became Civi admins), but a contributor last year implemented a role-based access control matrix for use with WordPress.

http://civicrm.org/blogs/rajesh/wordpress-access-control

Joe Murray was going to look at adding something like hook_perm in 4.3, but I don't see it right now, so maybe that ball got dropped. It's patch-welcome, though.

For some pointers to anyone interested in patching:
 - I *think* the core bit of code which manages Civi's list of permissions is CRM_Core_Permission::basicPermissions. To open up to extensions, this would probably need to invoke a hook near the end.
 - This should work out fairly intuitively under Drupal (i.e. hook_perm calls CRM_Core_Permission::basicPermissions), but I'm not sure how it works on the other CMS's.
 - If the list of permissions is cached in any DBs/files/serialized-structures, then we may need to do some kind of flush/reset operation whenever an extension is enabled or disabled. I don't know what those caches/DBs/etc would be under each CMS, but a good spot to kick that off might be CRM_Core_Invoke::rebuildMenuAndCaches().
 - The main work will probably be in testing each of the CMSs.

My Joomla and WP experience is very limited, but Lobo are you saying that defining permission in a hook would be difficult in Joomla, but not probably not such a challenge in WordPress?  If so, would it be acceptable for CiviCRM to support something like hook_civicrm_perm in Drupal and WP, but not in Joomla?

OK, for now I've created a new issue http://issues.civicrm.org/jira/browse/CRM-11925, as a placeholder for possible development along these lines.

we need 3 things from the CMS:

1. Ability to expose permissions to the end user (things like view contacts etc). In joomla this is done today in the install step via an xml file: access.xml

2. Ability to set a set of permissions for certain roles: i.e. anon user can "register for events, donate money and create a profile" etc. This is currently done via some non-trivial code and sql in script.civicrm.php

3. ability to check if a certain user has a certain permission. This is nice and clean in joomla

lobo

to my knowledge, there's no easy way to dynamically define a new permission in joomla the way you can in drupal. joomla's event/trigger system is only somewhat analogous to drupal's hooks. where drupal has hooks that are designed to alter system config, the events/trigger system are strictly a response to a user action.

joomla assumes that ACL permissions will be defined by the extension and be "fixed" -- that is why they are defined in an extension xml file called during the installation.

that said -- I think the goal here (if I understand correctly) is to create a civicrm hook that is a wrapper to the respective CMS's methods for implementing a new permission. and while joomla doesn't really give you a simple way to do that because of it's structure/assumptions -- I'm sure it can be done.

I think what we would need to look at is:
/libraries/joomla/access/rules.php -- merge($actions)

I *think* that would allow us to define new permissions for the com_civicrm asset and merge them with the existing ones.

the problem is that in Joomla this ends up being just a database action. which I think means that if someone were to upgrade civicrm via the extension installer, the asset permissions would be reset to whatever is defined in the civicrm access.xml file. because we are triggering the inclusion of those permissions via the civicrm extension install hook, they would be lost (unless the extension is reinstalled).

there is a joomla trigger on extension install. so i suppose we could call it in our main joomla-civicrm plugin -- basically work it so that when civicrm is installed/upgraded, we search for any instances of our civicrm perm hook and make sure we re-merge any new permissions with the main extension perms. that could even just be part of the civicrm install script (no need to handle it in a plugin).

(sorry to ramble...)

Hi All,

With help from totten and eileen I've worked out a solution for Drupal that should also allow folks to fill in the bits for WordPress and Joomla!. (I tried testing on WP but quickly gave up trying to understand the workflow for a site admin managing user permissions.)

I'd really like to get some feedback before committing the code, mainly because the feedback I've gotten so far has been so useful.  The proposed patch is here: http://pastie.org/6319401

Functionality:
1. New hook_civicrm_permission() allows module devs to define permissions that will be treated as CiviCRM permissions by the CMS.

2. Upon uninstalling the module, vestigial records of the permissions (e.g., in D7's role_permission table) are cleaned up, very similar to how Drupal module permissions are cleaned up when those are uninstalled. This is not supported in D6, which also doesn't do it for its own modules.

3. Upon rebuild of the CiviCRM menu and cache, the above cleanup step is performed. This ensures that when a module is upgraded, any permissions from the old version are cleaned out if they're not defined in the new version.  Again, this is not done in D6, which doesn't do it for its own modules.

Architecture:
A. The functionality in #2 is provided by the methods uninstallPermissions() and upgradePermissions() in CRM_Core_Permission_Base, ready to be overridden in the corresponding WP and Joomla classes, if it's relevant on those platforms.

B. In Drupal 7, the functionality of #3 is supported by prefixing the module name to the permission key. In Drupal 6 this is not relevant. For Joomla! and WP, separate class methods are available to handle this differently as needed, in CRM_Core_Permission_Base::getModulePermissions().

C. Drupal's module_implements() function, returning a list of modules that implement a given hook, is mimicked by the new non-static method moduleImplements() in CRM_Utils_Hook_Drupal.  Like-named methods exist in CRM_Utils_Hook_WordPress and CRM_Utils_Hook_Joomla, with basic functionality to be modified as needed for WP/Joomla installations.  This also led to some refactoring in CRM_Utils_Hook.

- Allen