Author Topic: Fundamental confusion with Joomla + CiviCRM (Read 10865 times)

nant · October 07, 2012, 12:31:10 pm

I have been experimenting with CiviCRM 4.2 + Joomla 2.5.7 for a couple of weeks now.

Ok - now I have more fundemental questions!!!

1. Must CiviCRM agents always access backend Joomla area to perform CRM related actions?
2. If 1 is Yes, then is there a way to hide menu areas from them? It looks like with Joomla ACL you can restict access but areas are always shown and when clicked on lead to error.
3. If 1 is No, then I would love to know how I can give a frontend Joomla logged in user access to add a contact, edit a contact, search a contact, etc.

Thanks in advance for any answers or comments.

Donald Lobo · October 07, 2012, 05:18:34 pm

pretty sure 1 is no

what happens in the front end when u give a specific joomla role

* access CiviCRM
* view / edit all contacts
* add contact

lobo

nant · October 08, 2012, 12:22:41 am

Quote from: Donald Lobo on October 07, 2012, 05:18:34 pm

pretty sure 1 is no

what happens in the front end when u give a specific joomla role

* access CiviCRM
* view / edit all contacts
* add contact

lobo

Thanks for replying.

Well Joomla is not like Drupal.

I can create such a Joomla ACL group (there is no role term in Joomla).
But how do I expose the civiCRM dashboard (Home | Search | Contacts ...) to a frontend logged in Joomla user?
I see no way to do this.
The Joomla menu Civicrm items exposed when creating a new Joomla menu, do not seem sufficient to do this.

I have been successful in creating a new Joomla ACL group that allows Joomla backend login that only shows the civiCRM dashboard. However if I start "not allowing" specific civiCRM actions (that are exposed to Joomla permissions control), then I get the folowing result: The civiCRM dashboard still shows the complete menu to the viewer, but if the viewer clicks on a menu item that leads to an action that is not permitted, then a very cryptic (unfriendly) code error appears.

In other Joomla components, if permissions do not allow an action, the component will not display access links (menu item, button, etc) to that action.

To make things even clearer, If I login as a Joomla superadmin that be default is allowed to do everything civiCRM related, I cannot do or access similar civiCRM tasks in frontend as I can in backend.

The frontend civiCRM dashboard is a static view of the superadmin contact info - i cannot search of other contacts as i can in backend.

sergeich · October 10, 2012, 09:10:13 am

@Lobo

There was actually a very similar discussion three years ago in 2009, another user longing for the same thing:
http://forum.civicrm.org/index.php?topic=8507.0

There are scenarios when it'd be super useful to allow Registered users to login from the Front End and use CiviCRM's powerful features of the BackEnd. At present Joomla's Front End has a tiny fraction of what can be done in CiviCRM. Pushing folks into the BackEnd brings another layer of problems: we lose FE's menus, we need to nurse their Access Rights to Joomla's inner workings, etc.

Lobo, is there anyway to expose CiviCRM in its full power on the Front End? I'm not talking Public, just Registered user access.

Donald Lobo · October 10, 2012, 09:34:59 am

I suspect we are quite close to having this. We just need a joomla / civi developer or two (besides brian s) to help out and figure out what else needs to be done to make this happen

sergei / nant: do u think u'll can help out? if so ping us on irc and we can help you get started

bottom line: people longing for it helps but does not help the code make any progress

So any code / development help / resources u'll can provide would great and help civi-joomla integration make bigger strides

lobo

nant · October 10, 2012, 01:48:45 pm

Quote from: Donald Lobo on October 10, 2012, 09:34:59 am

I suspect we are quite close to having this. We just need a joomla / civi developer or two (besides brian s) to help out and figure out what else needs to be done to make this happen

sergei / nant: do u think u'll can help out? if so ping us on irc and we can help you get started

bottom line: people longing for it helps but does not help the code make any progress So any code / development help / resources u'll can provide would great and help civi-joomla integration make bigger strides

lobo

No issues with helping as much as I can, but I need to understand what is implemented and what should work - otherwise I would be running around in circles.

I posted on irc, but looks like you left, so I am posting here what I did.

On your demo site, I created a new Joomla ACL group called civiCRM Manager.
I have the group backend login access and also enabled all civiCRM related permissions (via the CiviCRM » Administer CiviCRM
Access Control).

With such a setup, I would expect to see that a user added to this Joomla group would be able to login to Joomla backend and see only the CRM component and when viewing the CRM component this user should be able to see exactly what the superadmin is seeing.

Well you can login as crmadmin/crmadmin and see that the civiCRM Administer menu is missing.

So is this a feature or a bug or did i misunderstand something?

The next steps I would be trying to take is to start removing privileges to show even less menus to this crmadmin user.
For example how do i turn off reports?

Donald Lobo · October 10, 2012, 05:14:53 pm

missed u when i got back on IRC, but my 2 cents:

we should find out what hook / plugin joomla calls when perms are updated and/or a user record is updated and use that to trigger a rebuild of the nav menu

this will enable us to keep in sync with changes made to the CMS

lobo

lcdweb · October 10, 2012, 07:10:41 pm

there is a plugin that ships with civicrm that handles some of the navigation resetting. check to make sure it's enabled in the plugin manager. it's called: CiviCRM User Management

if it is enabled, and you have a found a workflow where the navigation should be rebuilt and is not, let's try to identify exactly what should be triggering it. we should be able to identify a joomla event or civicrm hook and then just extend that existing plugin.

re: permissioning traditionally backend pages for frontend access --

here's the prob -- there are certain elements of the page (e.g. breadcrumbs) and links that are built which assume the backend environment. you may be able to expose some pages to the frontend, but you would need to really kick the tires and make sure form submissions, redirects, validation, and any links on the page, respect your frontend environment.

i had a project where we exposed the activity create and edit forms to the frontend. it wasn't a problem providing access to that form (with the appropriate permissions), but I had to strip out some elements and tweak form handling to make it properly retain that frontend environment.

from a code perspective, here's the issue --
civi handles "frontend" pages differently than most joomla components. ALL of the civi code base resides in the administrator/components path. for pages that are intended for frontend access, there's a param in the CRM_Utils_System::url() method to indicate it is intended for frontend access. if flagged, civi strips the administrator path when building the url. kind of cludgy, but it does the trick. however -- it does mean we are explicitly determining what urls are intended for frontend access. so if you can find a way to overcome that in a more dynamic way, you might be able to achieve the desired results.

that said --
one could argue that Civi is actually in a better position (in terms of code architecture) to allow the flexibility you're looking for. most joomla components retain frontend pages in the root/components path and admin in root/administrator/components -- with no (easy) possibility of bridging the gap.

Donald Lobo · October 10, 2012, 07:26:06 pm

hey brian:

thx for the response. A few thoughts:

1. Seems like we should enable the plugin by default in the installer. I assume this should be relatively easy

2. Thanx for reminding us about the frontend / backend parameter

I had forgotten about it!

seems like we should be able to automate that and generate frontend urls all the time if civi is invoked from the frontend. That distinction is still important, since there are times in the backend when we want to generate a frontend url (i.e. urls within a civimail, live/test contribution page links etc)

nant: wanna take a crack at items 1 and 2 above. ping us on irc if u need any help

lobo

lcdweb · October 10, 2012, 07:41:10 pm

re: 1 -- it is enabled by default. but worth checking.
I think in v4.0 when we first created and included it, we may not have had it enabled by default. we fixed it in one of the point releases for 4.0.

I suspect it is enabled, and we are just missing some place where we should be triggering the resetNavigation() function and aren't.

re: 2 --
I agree, but we just need to proceed cautiously. for most orgs, the front/back great wall of separation is really important.

nant · October 11, 2012, 01:06:38 am

Quote from: lcdweb on October 10, 2012, 07:10:41 pm

there is a plugin that ships with civicrm that handles some of the navigation resetting. check to make sure it's enabled in the plugin manager. it's called: CiviCRM User Management

Yup, it's there and enabled by default.

Quote

if it is enabled, and you have a found a workflow where the navigation should be rebuilt and is not, let's try to identify exactly what should be triggering it. we should be able to identify a joomla event or civicrm hook and then just extend that existing plugin.

The workflow that fails for me (verified on my local install and the civi demo) is the following:

0. There is an existing user that has been created and put in an existing (created by me) Joomla ACL group that has specific civicrm permissions - the navigation bar for this user looks ok.
1. If I log off and login as superadmin and then change the Joomla ACL permissions for the previous group and then login again as previous test user, then the navigation bar does not refresh to show new situation. If I create a new user from scratch and add him to this modified group, then navigation bar appears ok.

So, it seems that user permissions or the user navigation bar are somehow statically stored and are not triggered at all by user logout and login.
I would think that every time a user logs in, the navigation bar for that user needs to be authenticated.

The joomla plugin used seems to trigger off the following:

- onUserAfterSaveGroup

I am not sure (will investigate) when this trigger actually is fired.

I think it is fired when a user record has been saved that has been modified (added, removed) groups (example this is triggered when a user is added to or removed from a Joomla group).
Again, I am not sure but this explanation does explain what I am seeing.

** Action item for me: to investigate what this trigger does and see if a better one is available.

Quote

re: permissioning traditionally backend pages for frontend access --

here's the prob -- there are certain elements of the page (e.g. breadcrumbs) and links that are built which assume the backend environment. you may be able to expose some pages to the frontend, but you would need to really kick the tires and make sure form submissions, redirects, validation, and any links on the page, respect your frontend environment.

i had a project where we exposed the activity create and edit forms to the frontend. it wasn't a problem providing access to that form (with the appropriate permissions), but I had to strip out some elements and tweak form handling to make it properly retain that frontend environment.

from a code perspective, here's the issue --
civi handles "frontend" pages differently than most joomla components. ALL of the civi code base resides in the administrator/components path. for pages that are intended for frontend access, there's a param in the CRM_Utils_System::url() method to indicate it is intended for frontend access. if flagged, civi strips the administrator path when building the url. kind of cludgy, but it does the trick. however -- it does mean we are explicitly determining what urls are intended for frontend access. so if you can find a way to overcome that in a more dynamic way, you might be able to achieve the desired results.

that said --
one could argue that Civi is actually in a better position (in terms of code architecture) to allow the flexibility you're looking for. most joomla components retain frontend pages in the root/components path and admin in root/administrator/components -- with no (easy) possibility of bridging the gap.

Thank you for the explanation = will have to study this before fully understanding and commenting.

nant · October 11, 2012, 01:46:41 am

Followup ---

The trigger appears the correct one to use.

I am thinking that the issue is perhaps with the civicrm caching?

When i manually visit the Cleanup Caches and Update Paths area and click on the Cleanup Caches button, the navigation menu is corrected.

Maybe the civicrmResetNavigation() function does not handle existing caching correctly?

Maybe cache needs to be purged here?

EdP · October 11, 2012, 05:32:32 am

Quote from: lcdweb on October 10, 2012, 07:41:10 pm

re: 2 --
I agree, but we just need to proceed cautiously. for most orgs, the front/back great wall of separation is really important.

I agree - it will be very useful to give some people access via the front end, but equally it will make understanding the long list of permissions more critical - if this gets implemented, please could the permissions page more clearly explain in context help what the permissions are for and do?

lcdweb · October 11, 2012, 08:35:26 am

the onUserAfterSaveGroup() event is a little weak in the documentation area. but I implemented it with the understanding that it is fired whenever an ACL group is saved -- including when permissions are changed for the group.

when those triggers are fired, they call CRM_Core_BAO_Navigation::resetNavigation( );
that is definitely the right CiviCRM method to call, and should take care of the user's navigation cache. the function clears the navigation value in the setting table (for the user) and also removes any navigation rows from the main cache table.

I suspect that in some scenario, onUserAfterSaveGroup() is not getting fired as we expect, and that's where the problem lies.

I'm not opposed to clearing the nav cache on user login. we would use the onUserLogin($user, $options = array()) event to do that. i'll take a look.

nant · October 11, 2012, 09:15:12 am

Quote from: lcdweb on October 11, 2012, 08:35:26 am

the onUserAfterSaveGroup() event is a little weak in the documentation area. but I implemented it with the understanding that it is fired whenever an ACL group is saved -- including when permissions are changed for the group.

when those triggers are fired, they call CRM_Core_BAO_Navigation::resetNavigation( );
that is definitely the right CiviCRM method to call, and should take care of the user's navigation cache. the function clears the navigation value in the setting table (for the user) and also removes any navigation rows from the main cache table.

I suspect that in some scenario, onUserAfterSaveGroup() is not getting fired as we expect, and that's where the problem lies.

I'm not opposed to clearing the nav cache on user login. we would use the onUserLogin($user, $options = array()) event to do that. i'll take a look.

Sounds great.

My hunch is that it is a caching issue of some sort.

CiviCRM Community Forums (archive)

News:

Author Topic: Fundamental confusion with Joomla + CiviCRM (Read 10865 times)

nant

Fundamental confusion with Joomla + CiviCRM

Donald Lobo

Re: Fundamental confusion with Joomla + CiviCRM

nant

Re: Fundamental confusion with Joomla + CiviCRM

sergeich

Re: Fundamental confusion with Joomla + CiviCRM

Donald Lobo

Re: Fundamental confusion with Joomla + CiviCRM

nant

Re: Fundamental confusion with Joomla + CiviCRM

Donald Lobo

Re: Fundamental confusion with Joomla + CiviCRM

lcdweb

Re: Fundamental confusion with Joomla + CiviCRM

Donald Lobo

Re: Fundamental confusion with Joomla + CiviCRM

lcdweb

Re: Fundamental confusion with Joomla + CiviCRM

nant

Re: Fundamental confusion with Joomla + CiviCRM

nant

Re: Fundamental confusion with Joomla + CiviCRM

EdP

Re: Fundamental confusion with Joomla + CiviCRM

lcdweb

Re: Fundamental confusion with Joomla + CiviCRM

nant

Re: Fundamental confusion with Joomla + CiviCRM