Answers.Body: <p>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 <code>&lt;name&gt;</code> tag that's in there needs to match too. Can check with something like:</p>
  
  <pre><code>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;
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-22T01:58:36.017Z
Answers.Text: 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.
Answers.UserDisplayName: G H
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-21T18:20:08.843Z
Answers.LastActivityDate: 2016-03-21T18:20:08.843Z
Answers.UserDisplayName: Demerit
Answers.Body: <p>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)</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-22T14:20:07.137Z
Answers.Text: 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.
Answers.UserDisplayName: Demerit
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-22T15:21:18.537Z
Answers.Text: Whoa!  That sounds like a great idea.  Maybe you should put that in as a feature request over at http://issues.civicrm.org/
Answers.UserDisplayName: G H
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-22T15:41:31.753Z
Answers.Text: 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.
Answers.UserDisplayName: Demerit
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-22T02:14:57.980Z
Answers.LastActivityDate: 2016-03-22T02:14:57.980Z
Answers.UserDisplayName: Leslie
Answers.Body: <p>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? </p>
  
  <p>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?</p>
  
  <p>(Might add tags like wordpress and upgrade to the question too.)</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-22T01:05:56.040Z
Answers.Text: 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".
Answers.UserDisplayName: Leslie
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-22T01:16:44.080Z
Answers.Text: 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
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-22T01:17:17.110Z
Answers.Text: 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
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-23T15:24:44.013Z
Answers.Text: 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.
Answers.UserDisplayName: Leslie
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-23T17:54:00.200Z
Answers.Text: 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));
Answers.UserDisplayName: Leslie
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-23T19:16:12.777Z
Answers.Text: I'm running up against this on a case that was created in the 4.6.9+ branch, then upgraded to now 4.7.4.  HOWEVER, looking at the Civi logs, it's trying to add two of the same "relationshipType" fields, that are not a part of this case type at all.  (These are Case Manager relationships in the first case created.)  I think we've got a bug.
Answers.UserDisplayName: G H
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-23T19:18:16.740Z
Answers.Text: Why is it trying to add RelationshipTypes at all?  Here's what look like the most interesting line.  plugins/civicrm/civicrm/packages/DB.php(976): PEAR_Error->PEAR_Error("DB Error: already exists", -5, 16, (Array:2), "INSERT INTO civicrm_relationship_type_en_US (name_a_b , label_a_b , name_b_a ...")
Answers.UserDisplayName: G H
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-23T20:30:14.520Z
Answers.Text: So, I found the first created Case Type where the Role that was doubling the RelationshipType error was found.  I removed ALL of the Roles from that Case Type.  I saved the Case Type, without error.  Then I was able to re-add the Roles to that Case Type.  Now, it appears that things are working again without error, with new and old Case Types.  So, find the find the Case Type with the lowest ID that has the offending Case Role assigned, remove ALL of the roles, save, then re-add the Roles to the Case Type.  Clear as mud yet?
Answers.UserDisplayName: G H
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-21T17:41:35.320Z
Answers.LastActivityDate: 2016-03-21T17:41:35.320Z
Answers.UserDisplayName: G H
Body: <p>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.</p>
  
  <p>I upgraded successfully from Civicrm 4.6.4 to 4.7.3, running on Wordpress 4.4.2</p>
  
  <p>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:</p>
  
  <p>Warning: Invalid argument supplied for foreach() in /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/CRM/Case/XMLProcessor/Process.php on line 186</p>
  
  <p>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:</p>
  
  <pre><code>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
  </code></pre>
  
  <p>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 :</p>
  
  <pre><code>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
  </code></pre>
  
  <p>Below these error messages, you will find the list of the three cases as it should provide normally.</p>
  
  <p>However, if you click on "manage" for any of these cases, then you get the following error message:</p>
  
  <pre><code>#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-&gt;get("Emergency Food", "CaseRoles")
  #3 /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/CRM/Core/Form.php(540): CRM_Case_Form_CaseView-&gt;buildQuickForm()
  #4 /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/CRM/Core/QuickForm/Action/Display.php(92): CRM_Core_Form-&gt;buildForm()
  #5 /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Display-&gt;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-&gt;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-&gt;handle("display")
  #8 /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/CRM/Case/Page/Tab.php(110): CRM_Core_Controller-&gt;run()
  #9 /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/CRM/Case/Page/Tab.php(197): CRM_Case_Page_Tab-&gt;view()
  #10 /home/hillcrest/www/www/wp-content/plugins/civicrm/civicrm/CRM/Core/Invoke.php(312): CRM_Case_Page_Tab-&gt;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-&gt;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' &lt;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."&gt;(learn more...)&lt;/a&gt;.
  
  Return to home page.
  </code></pre>
  
Tags: <wordpress><civicase><upgrade>
Title: With an upgrade to 4.7.3, Civicase has become inoperable
ThreadText: # With an upgrade to 4.7.3, Civicase has become inoperable
  
  (Asked by: username_0 on 2016-03-21)
  
  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' (learn more...).
  
  Return to home page.
  
  **Tags:** wordpress, civicase, upgrade
  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_1 on 2016-03-21. Score: 1 | Accepted answer
  
  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  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;
  
  > **Comments:**
  > **username_2**: username_0, would you mind marking username_1's answer as the answer?  It's to everyone's benefit to have as many questions answered as possible.  
  
  ---
  
  ### Answer by username_0 on 2016-03-22. Score: 1
  
  After receiving GH's and username_1'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)
  
  > **Comments:**
  > **username_1**: 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.  
  > **username_2**: Whoa!  That sounds like a great idea.  Maybe you should put that in as a feature request over at http://issues.civicrm.org/  
  > **username_1**: 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.  
  
  ---
  
  ### Answer by username_2 on 2016-03-21. Score: 0
  
  username_0, 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.)
  
  > **Comments:**
  > **username_0**: Thanks to username_1 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".  
  > **username_3**: 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  
  > **username_3**: 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  
  > **username_0**: Ok, some problems continue and I think GH and username_1 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.  
  > **username_0**: Addressing GHs previous question, I can not find the original XML files in the upgraded files. I thought to use username_1'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 username_1'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));  
  > **username_2**: I'm running up against this on a case that was created in the 4.6.9+ branch, then upgraded to now 4.7.4.  HOWEVER, looking at the Civi logs, it's trying to add two of the same "relationshipType" fields, that are not a part of this case type at all.  (These are Case Manager relationships in the first case created.)  I think we've got a bug.  
  > **username_2**: Why is it trying to add RelationshipTypes at all?  Here's what look like the most interesting line.  plugins/civicrm/civicrm/packages/DB.php(976): PEAR_Error->PEAR_Error("DB Error: already exists", -5, 16, (Array:2), "INSERT INTO civicrm_relationship_type_en_US (name_a_b , label_a_b , name_b_a ...")  
  > **username_2**: So, I found the first created Case Type where the Role that was doubling the RelationshipType error was found.  I removed ALL of the Roles from that Case Type.  I saved the Case Type, without error.  Then I was able to re-add the Roles to that Case Type.  Now, it appears that things are working again without error, with new and old Case Types.  So, find the find the Case Type with the lowest ID that has the offending Case Role assigned, remove ALL of the roles, save, then re-add the Roles to the Case Type.  Clear as mud yet?  
  
  ---
  
  