CiviCRM Community Forums (archive)

I have a CiviCase Case Type where <name> is set to "Follow up enquirer" in the XML definition file. I understand from http://wiki.civicrm.org/confluence/display/CRMDOC/CiviCase+Configuration and http://wiki.civicrm.org/confluence/display/CRMDOC/checkCaseTypeNameConsistency that this is legal.

On my CiviCase Dashboard, I see there are 2 resolved cases of type "Follow up Enquirer" and when I click on the link ( /civicrm/case/search?reset=1&force=1&status=2&type=1&case_owner=2 ) I get the WSOD, and when I hit the Back button I see an error pop up that says "Cannot load caseType with malformed name [Follow up enquirer]".

There doesn't appear to be a backtrace.

The error is thrown by line 89 of CRM/Case/XMLRepository.php when CRM_Case_BAO_CaseType::isValidName() returns false.

I think what's happening is that the database column "name" in the civicrm_case_type table corresponds to what the checkCaseTypeNameConsistency documentation calls the "Machine name" which allows underscores but no spaces, and the "title" column corresponds to "Display label".

If that's true, the error I have is that when my Case XML definition files were converted into civicrm_case_type rows, what should have happened is that the "name" column should have been set to the XML file name ("follow_up_enquirer").

Ken

I see now that, prior to upgrading to 4.5.beta4, my database had a civicrm_option_value row for this Case Type where both the "name" and "label" columns were set to "Follow up enquirer".

That suggests the documentation at http://wiki.civicrm.org/confluence/display/CRMDOC/checkCaseTypeNameConsistency is incomplete. The following situation is also possible prior to v4.5 ...

Display Label = "Housing Support"
Machine Name = "Housing Support"
File Name = "HousingSupport.xml"

May I make some suggestions?

• The Upgrade instructions at http://wiki.civicrm.org/confluence/display/CRMDOC/Upgrade+Drupal+Sites+to+4.5+-+Drupal+7 etc should advise people to rename their Case Type XML files before the upgrade.
• The upgrade process should set the "name" column (ie "Machine Name") in the civicrm_case_type table so it matches the name of the XML file. This requires a PHP script rather than SQL, as the civicrm_option_value record doesn't include the file name.

Aside: Since you mentioned the XML <name> tag... that tag is a mystery to me. As far as I can tell, up through v4.3, it simply wasn't used. In v4.4, we added hook_civicrm_caseTypes which allowed modules to auto-register case-types -- in that situation, we read the XML <name> and populate the civicrm_option_value.label (v4.4) or civicrm_case_type.title (v4.5). (As you note, the XML <name> is basically free-form -- which machine-names are usually constrained. Moreover, the workflow of naming/editing files is fairly brittle if the XML <name> must match the DB name.) But at any rate... if you've used the web-based workflow for registering case-types, then the XML <name> was ignored.

----

Generally, this issue is very conflicting. On one hand, I really want to preserve compatibility for existing case-type names; but on the other hand, I also really want names to behave in a simple way - because I found the old way rather confusing. To date, 4.5alpha/beta tries to balance the issue by (a) treating names in the conventional way and (b) using hacks to allow backward-compatibility (for the duration of 4.x at least). This bug indicates that the hack isn't working.

Could you try https://github.com/civicrm/civicrm-core/pull/3820 ? It's an attempt to resuscitate the hack which (in my test-case) allowed me to use an upgraded DB that had a case-type with an unusual machine-name.

FWIW, if we can treat the old names as deprecated but preserve backward compatibility (BC) within 4.5, then I think that produces the gentlest upgrade experience. On sites which are affected by the issue, we display the mis-match alert, and then the admin can simply edit the name via GUI (at their leisure).

There are some advantages to renaming before the upgrade (or during the upgrade), but the overall workflow is a bit more difficult -- and I don't want to foist that on anyone unless we simply can't find a way to keep BC in 4.5.

I'm sorry, @totten, I have other commitments at the moment that make it difficult to spend time on testing those PRs.