0

This is an addition to the question I asked last week. I have been using Civicase for 4 years and now I am unable to use it at all. Below I have provided more details about the problem that I did not include the first time.

I upgraded successfully from Civicrm 4.6.4 to 4.7.3, running on Wordpress 4.4.2

When using the "Find Cases" option for Civicase, the program responds normally if no case is found. However, for any case that meets the search criteria, the following error message is given:

Warning: Invalid argument supplied for foreach() in /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/CRM/Case/XMLProcessor/Process.php on line 186

The number of error messages matches the number of cases found (5 matching cases will generate 5 of the same error messages above). The list will be followed by the following error message:

Warning: Cannot modify header information - headers already sent by (output started at /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/CRM/Case/XMLProcessor/Process.php:186) in /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/CRM/Utils/System/Base.php on line 895

If you use the civicase dashboard and click on any number for existing case types (for ex, 3 cases for case type X), it will generate the same number of error messages above the dashboard, such as the following for 3 existing cases :

Warning: Invalid argument supplied for foreach() in /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/CRM/Case/XMLProcessor/Process.php on line 186

Warning: Invalid argument supplied for foreach() in /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/CRM/Case/XMLProcessor/Process.php on line 186

Warning: Invalid argument supplied for foreach() in /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/CRM/Case/XMLProcessor/Process.php on line 186

Below these error messages, you will find the list of the three cases as it should provide normally.

However, if you click on "manage" for any of these cases, then you get the following error message:

#0 /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/CRM/Core/Error.php(362): CRM_Core_Error::backtrace()
#1 /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/CRM/Case/XMLProcessor/Process.php(75): CRM_Core_Error::fatal("Unable to load configuration file for the referenced case type: 'Emergency Fo...")
#2 /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/CRM/Case/Form/CaseView.php(200): CRM_Case_XMLProcessor_Process->get("Emergency Food", "CaseRoles")
#3 /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/CRM/Core/Form.php(540): CRM_Case_Form_CaseView->buildQuickForm()
#4 /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/CRM/Core/QuickForm/Action/Display.php(92): CRM_Core_Form->buildForm()
#5 /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Display->perform(Object(CRM_Case_Form_CaseView), "display")
#6 /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Case_Form_CaseView), "display")
#7 /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/CRM/Core/Controller.php(351): HTML_QuickForm_Page->handle("display")
#8 /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/CRM/Case/Page/Tab.php(110): CRM_Core_Controller->run()
#9 /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/CRM/Case/Page/Tab.php(197): CRM_Case_Page_Tab->view()
#10 /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(312): CRM_Case_Page_Tab->run((Array:4), NULL)
#11 /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(86): CRM_Core_Invoke::runItem((Array:13))
#12 /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(54): CRM_Core_Invoke::_invoke((Array:4))
#13 /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm.php(1214): CRM_Core_Invoke::invoke((Array:4))
#14 [internal function](): CiviCRM_For_WordPress->invoke("")
#15 /home/hillcrest/www/www/wp-includes/plugin.php(525): call_user_func_array((Array:2), (Array:1))
#16 /home/hillcrest/www/www/wp-admin/admin.php(236): do_action("toplevel_page_CiviCRM")
#17 {main}

[in yellow]
Sorry but we are not able to provide this at the moment.
Unable to load configuration file for the referenced case type: 'Case Type X' <a href="http://book.civicrm.org/user/case-management/setup" target="_blank" class="crm-doc-link no-popup" title="Opens documentation in a new window.">(learn more...)</a>.

Return to home page.
Improve this question

3 Answers 3

Reset to default
1

It's possible something has changed in 4.7.3 but at least for the earlier versions I'm familiar with this is usually a mismatch between the "name" column (not "label") for your case types in the civicrm_option_value table. That has to match what it's looking for. So for example your Emergency Food type might have originally had a different name. And yes if there's still xml files that get used in 4.7.3 then the <name> tag that's in there needs to match too. Can check with something like:

SELECT ov.name FROM civicrm_option_value ov inner join civicrm_option_group og on (og.name='case_type' and ov.option_group_id = og.id) order by ov.name;
Improve this answer
1
  • Leslie, would you mind marking Demerit's answer as the answer? It's to everyone's benefit to have as many questions answered as possible.
    – G H
    Commented Mar 22, 2016 at 1:58
1

After receiving GH's and Demerit's suggestions, I began to examine the case types more closely. Some had matching Name and Title, others did not. Previously, you could change titles but not the Name as they were created in the program files and had to remain as they were. In any case, next to the Name display there is a lock. I unlocked the lock and then saved. After doing this for each case type, everything began to work fine again. I do not know why this worked nor if it will be permanent but for now, the program works fine. (btw, I had upgraded to Civicrm 4.7.4 before doing this, but the upgrade did not solve the problems at all)

Improve this answer
3
  • It's unfortunate that name is a string and not a number, and isn't called "key" or something like that. If name were a number nobody would think twice about changing it when they change the label. For example if the label "Housing Support" had name "1", then if you change the label to "Housing Assistance", you wouldn't change the "1". The whole point of name vs label is to have an unchanging key that represents that case type that can be used in code or elsewhere without breaking if somebody changes the label.
    – Demerit
    Commented Mar 22, 2016 at 14:20
  • Whoa! That sounds like a great idea. Maybe you should put that in as a feature request over at issues.civicrm.org
    – G H
    Commented Mar 22, 2016 at 15:21
  • Except that I believe the design of the option_value table was originally intended for maximum flexibility, at the expense of a little complexity. There is a value column which is often a number, and case types do have numbers there. Having name,label,value gives you more flexibility, and the table is used for more than just case types. I'm just saying in this situation think of the case type name as if it was a number and it will keep you out of trouble.
    – Demerit
    Commented Mar 22, 2016 at 15:41
0

Leslie, it looks like you've been up, down, and all around on this issue. However, have you gone into Administer -> CiviCase -> Case Types, made a change to an existing case type, and saved it, then checked? You may also want to do the same for Activity Types. Some things definitely changed for CiviCase and I wonder if something in your XML file got deprecated perhaps?

It looks like your cases were initially set up under the file based XML setup. Did 4.7 remove the file based XML hooks for CiviCase and move only to DB based?

(Might add tags like wordpress and upgrade to the question too.)

Improve this answer
8
  • Thanks to Demerit and GH for their suggestions. We have in the past made changes to the case types but they have worked fine until this upgrade. I will continue to play around with the case types to see if I can get something to work. We have been using this database since 2012 with many upgrades so perhaps something did get "corrupted".
    – Leslie
    Commented Mar 22, 2016 at 1:05
  • we had some issues with older sites that had civicase types built before the new approach was adopted - really sorry i can't remember the detail but yes involved the name/label issue as part of it
    – petednz - fuzion ♦
    Commented Mar 22, 2016 at 1:16
  • i think at one point i rebuilt a very similar case via the new interface just to work out what was different in terms of names/labels in the db
    – petednz - fuzion ♦
    Commented Mar 22, 2016 at 1:17
  • Ok, some problems continue and I think GH and Demerit have been answering them but as I am somewhat a novice to this, I do not know how to proceed. The changes I make to the case types are not being saved. I can not save activities, or roles, or timelines, or anything. When I first unlocked the "name" field, I noticed it was not unlocked when I opened the case type again. I think the problem is in the XML and database files, but do not know how to rectify this.
    – Leslie
    Commented Mar 23, 2016 at 15:24
  • Addressing GHs previous question, I can not find the original XML files in the upgraded files. I thought to use Demerit's previous reply to merging case types as a fix for the current problem. I created a new case type with default activities and timeline and tried to merge an old case type into it but no data was transferred in my database using Demerit's script: UPDATE civicrm_case SET case_type_id = CONCAT(CHAR(1), '8', CHAR(1)) WHERE case_type_id = CONCAT(CHAR(1), '1', CHAR(1));
    – Leslie
    Commented Mar 23, 2016 at 17:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.