CiviCRM Community Forums (archive)

Due to a couple of silly mistakes I had to reinstall Civi last night and the ACLs have all got set to "inherited" for everyone. Therefore no-one other than the admins has access. So the normal solution is to go to Admin>>Access Control etc and try to give access, but when I press "save" or "save and continue" the screen transfers to the Joomla Site config screen and doesn't save any permissions.

Why would it do that - what is it doing? This may be a joomla issue not a Civi one of course..

Alternatively which database fields from my backup should I copy into my live database to grant these permissions? I don't merely want to install my last backup database as I'd probably lose some subsequent transaction data, and I don't know any front-end way of giving permissions except through that screen.

EDIT: I should add that I keep my CiviCRM in a different database to Joomla, so when updating Joomla I have no ACL issues if I do not update the (pointless) copy of the Civi tables in the Joomla database, but if I run the CiviCRM upgrade script on them too then the ACLs seem to get wiped. Up to now I've always been able to reset them but this bug is preventing that and so everyone is locked out until I can grant ACLs.

Not really. The partial solution was to extract the relevant bit of the civicrm_domain table from backup and stick it back in. That gave everyone back the permissions they had before, but I can't change anything new.

Wanted to give an update, I found a workaround for this, unfortunately it includes updating the mySQL #_assets database manually.  I installed a clean copy of Joomla with only CiviCRM and copied the "Rules" from the civicrm row.  I worked through the logic and was able to move the entire section (example seen below) into notepad and I updated it on my live database.  So far it works well, just manual.   

This may not be useful to everyone, but the logic was the difference between killing this project and moving forward.

In the rules I copied all the permissions with the following example (this is a snip-it, all the permissions should be included as listed below).

{"core.admin":[],"core.manage":{"23":1,"25":0},.......}

In the above example only super admin will have core.admin rights, and for core.manage the superuser and group id 23 (and all group id's below it) will have access, while group id 25 will not have access (this assumes group id 25 is a subset of group 23). 


Translates to:
{"PERMISSION":{"GROUP ID":yes/no}, "PERMISSION":{"GROUP ID":yes/no}, ......}

[] = only superuser with permission
GROUP ID = the group you want to allow/deny permission, all group id's below the chosen group id will inherit the permission.  If you want a sub-group to not have the same permission you would need to call that group id and have :0. 

Yes = 1 while No = 0


Example of entire rule with only Super User and Group ID 23 having access.

{"core.admin":[],"core.manage":{"23":1},"civicrm.add_contacts":{"23":1},"civicrm.view_all_contacts":{"23":1},"civicrm.edit_all_contacts":{"23":1},"civicrm.delete_contacts":{"23":1},"civicrm.access_deleted_contacts":{"23":1},"civicrm.import_contacts":{"23":1},"civicrm.edit_groups":{"23":1},"civicrm.administer_civicrm":{"23":1},"civicrm.access_uploaded_files":{"23":1},"civicrm.profile_listings_and_forms":{"23":1},"civicrm.profile_listings":{"23":1},"civicrm.profile_create":{"23":1},"civicrm.profile_edit":{"23":1},"civicrm.profile_view":{"23":1},"civicrm.access_all_custom_data":{"23":1},"civicrm.view_all_activities":{"23":1},"civicrm.delete_activities":{"23":1},"civicrm.access_civicrm":{"23":1},"civicrm.access_contact_dashboard":{"23":1},"civicrm.translate_civicrm":{"23":1},"civicrm.administer_reserved_groups":{"23":1},"civicrm.administer_tagsets":{"23":1},"civicrm.administer_reserved_tags":{"23":1},"civicrm.administer_dedupe_rules":{"23":1},"civicrm.merge_duplicate_contacts":{"23":1},"civicrm.view_all_notes":{"23":1},"civicrm.access_ajax_api":{"23":1},"civicrm.access_contact_reference_fields":{"23":1},"civicrm.access_civicontribute":{"23":1},"civicrm.edit_contributions":{"23":1},"civicrm.make_online_contributions":{"23":1},"civicrm.delete_in_civicontribute":{"23":1},"civicrm.access_civimember":{"23":1},"civicrm.edit_memberships":{"23":1},"civicrm.delete_in_civimember":{"23":1},"civicrm.administer_civicampaign":{"23":1},"civicrm.manage_campaign":{"23":1},"civicrm.reserve_campaign_contacts":{"23":1},"civicrm.release_campaign_contacts":{"23":1},"civicrm.interview_campaign_contacts":{"23":1},"civicrm.gotv_campaign_contacts":{"23":1},"civicrm.sign_civicrm_petition":{"23":1},"civicrm.access_civipledge":{"23":1},"civicrm.edit_pledges":{"23":1},"civicrm.delete_in_civipledge":{"23":1},"civicrm.access_civimail":{"23":1},"civicrm.access_civimail_subscribe_unsubscribe_pages":{"23":1},"civicrm.delete_in_civimail":{"23":1},"civicrm.view_public_civimail_content":{"23":1},"civicrm.access_civireport":{"23":1},"civicrm.access_report_criteria":{"23":1},"civicrm.administer_reserved_reports":{"23":1},"civicrm.administer_reports":{"23":1},"civicrm.access_civigrant":{"23":1},"civicrm.edit_grants":{"23":1},"civicrm.delete_in_civigrant":{"23":1},"civicrm.delete_in_civicase":{"23":1},"civicrm.administer_civicase":{"23":1},"civicrm.access_my_cases_and_activities":{"23":1},"civicrm.access_all_cases_and_activities":{"23":1},"civicrm.add_cases":{"23":1},"civicrm.access_civievent":{"23":1},"civicrm.edit_event_participants":{"23":1},"civicrm.edit_all_events":{"23":1},"civicrm.register_for_events":{"23":1},"civicrm.view_event_info":{"23":1},"civicrm.view_event_participants":{"23":1},"civicrm.delete_in_civievent":{"23":1}}


I hope this is ok to post and it helps someone.  I was pulling my hair out (and I have none to begin with) and this saved the day.

dont think anyone has reported this issue on a clean new install of civicrm

you might want to create a new forum topic with more details of your specific bug. Will also help a lot if you can debug and figure out whats happening and why

lobo

i have found a better workaround, reduce the number of joomla groups that you have an it will fix it, delete any that you dont need ie, the demo groups

I'm new to civiCRM and I'm having a similar problem. I'm running with Joomla 3.1.5 and civiCRM 4.3.5. When I try to configure global permissions for a user group, I get an 'Internal Server Error' every time I try to save any change made. I can change and save other component permissions okay. Any suggestions for resolving or working around this issue? I have 21 groups so limiting it to 12 doesn't appear to be a viable option. I need to configure Joomla/civiCRM so that only a very select group of users and access it via the backend without being able to access other components.

Here are some additional details. The problem occurs whenever I try to save any change made in the global configuration for civiCRM via the Joomla global permissions panel accessed via Joomla System > Global Configuration > Permissions > com_civicrm or from within CiviCRM via Administer > Users and Permissions > Permissions (Access Control) > Joomla Access Control. Unlike the other components, when I click on CiviCRM, it takes quite a bit of time for the options panel to show up. I would provide a screen shot, but the editor I'm using here doesn't give me an option to insert an image. The problem occurs when I try to save any changes I make. For example, I want to Allow Access to a group that I call civiCRM admin, so I select that group, then change the action Access Component from Inherited to Allowed. I then select Save or Save & Close. At this point in the process, the systems seems to hang, then after a few minutes, I receive an 'Internal Server Error' stating that the system was unable to complete my request. I get the same results when I try this on a localhost system or production server system.

I´m having the same problem.  Fresh Joomla 3.3 and Civicrm 4.5.
Would be grateful for a fix here:-)

Hi, I had the same situation here, so I'm registering what worked for me just in case someone got in trouble.
Taking a look at Apache log, I found that:

[Tue Dec 09 16:37:10.669746 2014] [:error] [pid 21787] [client xx.xx.xx.xx:xxxxx] PHP Warning:  Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0, referer: https://xpto.com/administrator/index.php?option=com_config&view=component&component=com_civicrm

So I found the line that deal with max_input_vars in php.ini, uncommented it and set the value do 2000. That seems to resolve the problem. I think this form is just too long, so PHP can't deal with that using its default.