CiviCRM Community Forums (archive)

Found a bug on line 116 when initiating CiviCRM

require_once 'administrator/components/com_civicrm/civicrm.settings.php';
When logging in to the administrator backend the statement needs to reference the full path. Need to add the full path to get this working.

require_once JPATH_ROOT.'/administrator/components/com_civicrm/civicrm.settings.php';
hmmm

Thanks Dave.

I'm planning on putting this into production in the next few weeks and will work on getting it into better shape. For now it appears to meet my requirements but I'd like to make it more flexible for the rest of the community. A good way forward would be to get some params setup so it can be configured from admin rather than hacking the file direct.

From the lack of response I'm a little discouraged by the Joomla CiviCRM community. Personally I'd like to see the integration get stronger along the lines of drupal. 

I keep on hearing that Drupal has better hooks than Joomla and one of my bug bears is when one of my Joomla users changes email. From what I can see Joomla does have tool here and I like to get a better understanding of how Drupal handles a user / contact changing their email address. Assuming this is done in a civicrm profile surely this can get written back to the Joomla user table since we already know who they are through UFMatch.  Wouldn't JUser::save handle this http://api.joomla.org/Joomla-Framework/User/JUser.html#save

Excellent! Thanks for the heads up!

RogerCo,

I'm sure that lobo could give you a full pointer but this might be the right place...
http://fisheye.civicrm.org/viewrep/CiviCRM/trunk/CRM/Core/BAO/CMSUser.php?r1=13745&r2=14533

http://issues.civicrm.org/jira/browse/CRM-2820

Henry

Thanks lobo,

I'm actually on J1.5 with CiviCRM 2.0.2 (yes I know that is "not supported" but it works just fine so far. J1.0 is really deprecated and all new sites will be using 1.5, I have moved all of my old J1.0 sites to J1.5 now - legacy mode allows most things to work)

In my particular case I certainly don't want all CiviCRM contacts to be Joomla users, and I probably don't want all Joomla users to be CiviCRM contacts. In fact I think it is quite important not to enforce this - imagine you are using CiviCRM to track supporters and members in a particular area. You might want only members to be able to become front-end (J or D) users as you might be exposing other things to front end users in the normal way (eg document libraries, forums, mail list, as well as content pages). So you might not want supporters who are non-members to have access to the logged-in part of the front-end, hence not be J (or D) users. Conversely you might have members in other areas who you want to be able to give access to all of your registered user front-end goodies but not actually to be registered as contacts in the CiviCRM database - another territory might be tracking their membership.

So from my point of view the model you describe (all front-end users have to be CiviCRM contacts) is not good.

As part of my mod to use CiviCRM groups for access control in the Joomla front end I check and warn if the Joomla and CiviCRM primary email addresses are not the same - but again I don't want to enforce this as I am aware that many people these days have 2 or more email addresses - often a 'free' one they use for website signups and a private one which might be in the CiviCRM contact details - enforcing equality after the initial link between the Joomla and CiviCRM user tables would be bad news.

RogerCO

Hi Henry
Apologies in advance for a long reply - I'll try and be concise.

The client has several layers and areas of organisation. National, Regional and Local as well as interest groups cutting across these layers. The site is provides resources for members of the organisation which includes using CiviCRM to manage details of members and supporters for one particular region.

Very few people are given access to the backend - essentially only techies - most user access is exposed through the front-end using profiles and access control (in my case using Joomla 1.5 and my mod to use groups for access control - I guess Drupal sites would use the CiviCRM ACL roles)

The home page of the site is of course publicly visible - but mostly consists of links to other public sites belonging to the organisation and a log-in form.

A registered Joomla user once logged in can see the rest of the site - which includes many facilities other than CiviCRM - which may be of interest to members of the organisation from other regions. Thus it is necessary to be able to create Joomla users who are not CiviCRM contacts. Of course you could argue that there would be no harm in automatically creating CiviCRM records for them but there is no need as their membership details are managed elsewhere and the primary focus of this application is activities within this particular region. I would rather not clutter the database with spurious contact records for foreign users.

For members in the region the CiviCRM data is tracking their personal details, roles, activities, membership details, local and other group membership within the organisation. If a member has a Joomla login then they can see (and edit some of) their personal information, and depending on their membership of groups used for access control may be able to see other profiles and lists. Not all members will have or even want a Joomla login (about 25% don't even have an email address)

In the CiviCRM contact data I am also keeping details of supporters in the region who are not members. These CiviCRM contacts (supporters) would never be given Joomla logins - most of the site is for members only. If they wish to see the personal data held about themselves they make a data protection request in the normal way (UK law). Some groups of members will have access to some views edits of the supporters information. So for example the communications member group might have access to the details of all contacts, both members and supporters, who have poster sites available - exposed on the frontend through a profile whose access through the menu is limited to the communications group.

To get a (Joomla) login to the site a user has to request a login by email (or a form on the site) giving their membership details - for members from other regions their details have to be checked elsewhere before they are given their login. In principle I could automate the process for members in the region whose contact details are in CiviCRM - but that would then rely on them using the same email address for their Joomla registration as is held with their membership details - not all will. In addition I find that some members share the same email address so the email address is not unique in the CiviCRM contact details. So adding frontend CMS users is a manual operation after checking that they are genuine members somewhere in the organisation.

New members are at the moment always added as contacts on the backend because the details are passed from another system (national or local level) and it is frankly easier and safer to import a row or rows from a spreadsheet than retyping everything and introducing mistakes. Once held in this system any changes in personal details (made by the user or an authorised membership officer) entered into the system are automatically reported back to national and local level by email.

New supporter details can be added through a front-end profile form or the backend.

So in summary I need to have Joomla users who are not and never will be CiviCRM contacts as well as CiviCRM contacts who never will be Joomla users. I would have thought that this must be not an uncommon requirement so maybe I am missing something obvious, or maybe Drupal is very different.

For access control on the frontend I have modified the Joomla CiviCRM component file so that when creating a menu item to access a CiviCRM profile on the frontend you can not only use the standard Joomla access levels (public/registered/special) to control visibility of the menu item, but you can also use CiviCRM groups to control access to the profile pages. I imagine this does very simply what in Drupal you do using the CiviCRM ACL roles and permissions. There is probably more sophistication in the integral solution, but simple access control using groups works fine for me - we'll have to see how it goes if the number of access groups multiplies.

RogerCO

Hi lobo,

In 2.0, a Joomla user becomes a civicrm contact ONLY when they access a civicrm page ...

Aaargh !! So it does. That's a bit of a nuisance - I don't suppose there is an easy way of disabling this behaviour is there? It'll be ok so long as I don't need to expose any CiviCRM access to CMS registered users who are not contacts, but it would be nice to disable this.

When we implement the joolmla 1.5 user plugins, a civicrm contact will be created whenever a joomla user is created/edited.

Please please make this behaviour optional. As explained above I do not want to have spurious contact records created whenever a user is registered on the front end. I want this to be optional both ways.

What I am looking for now is a way to add a 'register Joomla user' option on the contact edit form (both on the backend and as a field that can be added to a profile for the front end).

The current 'synchronise users' thing is useless for me as it creates contact records for ALL joomla users who do not have them. One example of why this might be a problem is the case of the member who is using two email addresses - one for his membership record in CiviCRM which is where he wants official communications from the organisation to go, and a different one for the website registration (which might be made visible to other users). As I understand it the current system will create a second contact record for the user with the different email address - not good. In this specific example possibly friggable by messing with the contact matching settings, but better to not use it.

I guess what I am saying is that I don't want tight coupling between website CMS registrations and CiviCRM contacts to be enforced.

Any pointers to adding a CMS register option to backend contact editing and profiles gratefully received...

Thanks for all the help and advice.
RogerCO