CiviCRM modification Component com_jcivi_v2.2 for Joomla 1.5.14 and CiviCRM v2.2.8
Screenshots attached and component installation files attached.
Note: THIS IS NOT FULLY TESTED - PLEASE TEST IN YOUR OWN ENVIRONMENT BEFORE USING ON A LIVE SITE
Updated 13th August with v2.2 which allows smart groups to be used to restrict access to profiles
This package is a set of modifications for CiviCRM v2.2.8 in a Joomla 1.5.14 environment which allows control over who can access CiviCRM profiles through the Joomla frontend to view and edit contact details. It is packaged up as a Joomla component so that you can use the standard component installation routines - just install it as you would any other component and it will update the relevant CiviCRM files. There is a separate Undo component which will should reverse the changes, redtoring the v2.2.7 files
This is attempting to address two concerns:
Secondly this is providing additional functionality in that access to profiles (for search, listing, view or editing) can be restricted by full Joomla user group (guest/registered/author/editor/publisher/manager/admin) and also by CiviCRM group membership. This works irrespective of whether the link to the profile is through a Joomla menu link, or by directly constructing a URL query string.
The access restrictions are all set up by the site administrator using Joomla menu and component parameters - these are defined in xml files. In this release you need to know the id numbers of any profiles or CiviCRM groups you wish to use as controls - Joomla 1.6 will introduce multi-select parameter lists so more admin friendly method of selection will be available.
Description of the changes:
There are changes to the Joomla com_civicrm frontend component (file civicrm.php in Components), and also changes to two files in the core CiviCRM package which control visibility of edit links and edit forms (files Edit.php and Listing.php in Administrator/Components/Ccom_civicrm/civicrm/CRM/Profile ). There are also new .xml files to define the parameters.
The component level parameters require a minor change to the admin file toolbar.civicrm.html.php to add the parameters button on the toolbar in the backend. Since some people give wider access to the backend, the Parameters button is only shown to the Super-Admin user (you could easily remove this restriction). No default values are set to avoid the Joomla quirk whereby if you have default values for a text box component parameter these defaults then get reinstated for a menu entry even if you have changed them at component level. (text box, unlike radio and selector types does not have a 'Use Global' default).
Menu parameters are defined in the relevant view xml files.
Part 1 - improving CRM4668 to use Joomla user groups to control access to editing. This involves changes to two core CiviCRM files. Firstly CRM/Profile/Selector/Listing.php around line 400 inserted code to check the user group and only show the edit link if allowed. Secondly CRM/Profile/Form/Edit.php around line 85 this now checks user level before actually displaying the edit form and redirects away if not authorised.
There is a quirk here that the CiviCRM code redirects to the CiviCRM $config->userFrameworkBaseURL, which is typically not a CiviCRM page, but the error message does not get displayed until the next time the user accesses a Civi page which can be confusing!
It should be quite easy to extend these edit validity checks to use restrictions by CiviCRM contact group.
Part 2 - setting up access control in general. There are several layers to this, almost all the changes are in the frontend control file JoomlaPath/Components/com_civicrm/civicrm.php. Most of the changes have been bundled into a new separate function check_joomla_permissions().
Before this there is a basic check introduced around line 22(all line numbers refer to the modified files) so that we can prevent ALL public access to CiviCRM functions. This happened to be a requirement for one of my sites so I put it here - it could be made more sophisticated allowing access to (say) profiles but not dashboard, or events but not profiles etc.
Next around line 90 we call the new check_joomla_permissions() function which returns true if the request in the $args is allowed or false with a message to be displayed if the request is barred.Around line 106 I have changed the style for the Civi 'no permission' message and also remove the synchronising of users and contacts as I prefer to handle this through the CiviAuthenticate plugin and CiviUser component.
check_joomla_permissions() is at the end of the file starting around line 175.
The first thing we do is check if we are a Super-Admin and if we are return true straight away - super-admins should be able to do anything.
The next check is for guest users (line 203) - assuming we have allowed public access then we need to check the component parameter for Public Profiles to see if this profile id is listed. The parameter is a comma separated list of profile id numbers. 'any' can be used to alow any profile through, and an empty list will deny all.
Having dealt with guests we now have logged in users left who belong to a Joomla user group and may also belong to CiviCRM contact groups.
The switch at line 226 gets the appropriate component parameter for the Joomla group - note that these are specific, not cumulative, so an editor does not inherit the rights of an author and registered user. It could be made to inherit by removing the break; statements. They do all inherit the public rights though.
If you want to just use CiviRM groups to control access you will need to set all of the component access parameters to 'any'.
Having checked that the user is the right level to access this profile we now need to check whether she belongs to the right groups for this particular menu call. NB this check only applies if the profile is being called through a menu entry as only then will the menu parameter be set for the code to check against. This means that this check is NOT secure - a user could construct a url for a profile for which his Joomla user level was enabled but which his Civi Group membership was not valid and still gain access to the profile - this would apply to edit as well as view profiles. So in the lowest case if you had a profile which was enabled for registered user view but which you wished to restrict to a subset through a Civi group, then a registered user who was not a member of the group could still access the profile directly - it becomes a question of how far you trust your members. A solution should be possible either through work inside CiviCRM or with the new coming Joomla ACL system.
Line 260 checks whether we are restricting by Civi group. Only a single group can be selected in the parameter for each menu entry, but smart groups can be included.
So that is it - to use this the site admin needs to set up the relevant parameters both at component level (the button in the toolbar in the backend) and at menu level (when creating menu entries)
Many possible tweaks for particular situations - some people might want more flexible error messaging. Currently it is using the message css class in the Joomla template css - there is a nice Joomla system call to show different box styles depending on warning/info/ message type etc