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

Donald Lobo · October 11, 2012, 09:22:39 am

resetNavigation is a fairly heavy duty function and should be sparingly used, IMO.

We should find and figure out when permissions change instead of doing it on user login. will definitely have a performance impact for medium - large sites

lobo

nant · October 11, 2012, 09:42:49 am

Quote from: Donald Lobo on October 11, 2012, 09:22:39 am

resetNavigation is a fairly heavy duty function and should be sparingly used, IMO.

We should find and figure out when permissions change instead of doing it on user login. will definitely have a performance impact for medium - large sites

lobo

I believe the proposal is to somehow force cache purging after user login.

In case you missed it, see my comment on manually using the Cleanup Caches and Update Paths area and click on the Cleanup Caches button, the navigation menu is corrected.

Donald Lobo · October 11, 2012, 11:16:26 am

yes, thats my point. purging and rebuilding the cache is expensive

user login is cheap and happens multiple times a day (for a medium sized site). Doing so on every user login is a recipe for trouble

lobo

nant · October 11, 2012, 11:58:32 am

Quote from: Donald Lobo on October 11, 2012, 11:16:26 am

yes, thats my point. purging and rebuilding the cache is expensive

user login is cheap and happens multiple times a day (for a medium sized site). Doing so on every user login is a recipe for trouble

lobo

Is there a separate function to just purge the cache?

lcdweb · October 15, 2012, 07:04:54 am

I agree that purging the navigation cache is expensive.
However -- we only need to purge it for backend admin users -- not people logging into the frontend. That happens infrequently -- typically only once a day.
And because we would trigger on login, it would happen before the user enters CiviCRM. So I suspect the user experience would be minimal.

But I also agree that it would be preferable to pinpoint exactly where the ACL group change is happening so that it's not necessary to handle it via login. If that point is difficult to identify, and/or there is no Joomla event trigger that easily captures it, then I vote for just handling via login as the safer route.

Donald Lobo · October 15, 2012, 09:05:02 am

agreed on the "lets do it right if we can, if not lets ensure we fix it"

lobo

lcdweb · October 15, 2012, 09:05:49 am

I dug extensively, and it doesn't look like Joomla currently has an event triggered when permissions are changed for groups. So the most reliable way to address this is during login. Lobo -- I understand the concern about expense, but we can pass the contact ID, so it only needs to rebuild the navigation cache for a single contact, which in my testing, has no perceivable load impact.

nant -- would be good if you can test and confirm. Here is the revised plugin:
http://paste2.org/p/2338924

nant · October 15, 2012, 12:55:22 pm

Quote from: lcdweb on October 15, 2012, 09:05:49 am

I dug extensively, and it doesn't look like Joomla currently has an event triggered when permissions are changed for groups. So the most reliable way to address this is during login. Lobo -- I understand the concern about expense, but we can pass the contact ID, so it only needs to rebuild the navigation cache for a single contact, which in my testing, has no perceivable load impact.

nant -- would be good if you can test and confirm. Here is the revised plugin:
http://paste2.org/p/2338924

are you sure?
how did you test this?

lcdweb · October 15, 2012, 02:17:28 pm

how did I test what -- the absence of an event trigger? I searched through the code. no event is triggered in com_config when ACL perms are updated. there's probably some dispatch/rendering events triggered, but those aren't "properly" what I would want to work off.

of course, if you find an event that I missed, feel free to say so. but I don't think triggering off login will have enough performance impact that we really need to worry about it.

nant · October 16, 2012, 04:41:29 pm

Quote from: lcdweb on October 15, 2012, 02:17:28 pm

how did I test what -- the absence of an event trigger? I searched through the code. no event is triggered in com_config when ACL perms are updated. there's probably some dispatch/rendering events triggered, but those aren't "properly" what I would want to work off.

of course, if you find an event that I missed, feel free to say so. but I don't think triggering off login will have enough performance impact that we really need to worry about it.

Ok - I have also just verified that the trigger is only fired when someone visits the group definition page on joomla backend (where you just give a name and a parent) and click save.

This trigger is not fired if you change any permissions related with the group.

I have posted on Joomla google group to see if there is a better trigger we can use.

Will post back when I have some feedback.

nant · October 17, 2012, 01:05:09 am

Waiting for google group responses I had a thought - maybe we should create our own Joomla event for the case where a user executes the URL that opens the popup ACL at url:

civicrm/administrator/index.php?option=com_config&view=component&component=com_civicrm&tmpl=component

lcdweb · October 17, 2012, 06:08:57 am

When the permissions are set, that action is all happening outside of Civi. And the page is not reloaded, as the permissioning is all handled in a modal popup. So we have no way of triggering via a hook.

And I don't think it's worth the effort anyway. I think we should just move forward with the fix I included above, and clear nav on login. I'm 90% sure there's no Joomla event triggered, so login is our best solution. I'll see if I can get the J team to consider adding an event, but in the meantime, login is our best solution.

lcdweb · October 17, 2012, 06:11:14 am

actually, I see that a suggestion was given in the joomla dev group.
I'll try that change and post if it works.

lcdweb · October 18, 2012, 05:59:49 am

we've had some conversation in the Joomla dev list and determined that there is no existing event triggered at the interface where permissions are saved. the Joomla team agrees there really should be an event triggered, so that may make it into a future version.

for now, our best solution is to trigger on admin login.
I filed a Jira issue with a patch here: http://issues.civicrm.org/jira/browse/CRM-11091

nant · October 18, 2012, 08:44:48 am

Quote from: lcdweb on October 18, 2012, 05:59:49 am

we've had some conversation in the Joomla dev list and determined that there is no existing event triggered at the interface where permissions are saved. the Joomla team agrees there really should be an event triggered, so that may make it into a future version.

for now, our best solution is to trigger on admin login.
I filed a Jira issue with a patch here: http://issues.civicrm.org/jira/browse/CRM-11091

Great, I will be following up on the joomla tracker side

CiviCRM Community Forums (archive)

News:

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

Donald Lobo

Re: Fundamental confusion with Joomla + CiviCRM

nant

Re: Fundamental confusion with Joomla + CiviCRM

Donald Lobo

Re: Fundamental confusion with Joomla + CiviCRM

nant

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

lcdweb

Re: Fundamental confusion with Joomla + CiviCRM

nant

Re: Fundamental confusion with Joomla + CiviCRM

nant

Re: Fundamental confusion with Joomla + CiviCRM

lcdweb

Re: Fundamental confusion with Joomla + CiviCRM

lcdweb

Re: Fundamental confusion with Joomla + CiviCRM

lcdweb

Re: Fundamental confusion with Joomla + CiviCRM

nant

Re: Fundamental confusion with Joomla + CiviCRM