On a particular Civi 4.6.4 / Drupal 7 installation, recently upgraded from 4.4, there are some misbehaving case types. They appear to have been created through the CiviCase UI since the 4.6 upgrade, as there are no corresponding xml files in CRM/Case/xml/configuration/ under the custom template directory. These case types have no activity types and no timeline specified. The xml in the definition field of the civicrm_case table is just this:

<?xml version="1.0" encoding="utf-8" ?>


When I try to edit one of these broken case types through the UI, e.g. adding activity types or adding a standard timeline containing Open Case, it does not save. No error is reported on screen, in CiviCRM.blah.log, Drupal watchdog, Firebug console or the web server error log.

The following civicrm/ajax/rest call is shown in Firebug on saving:

action: create
entity: CaseType
json: {"id":"4","name":"engagement","title":"Engagement","is_active":"1","is_reserved":"0","weight":"2","definition":[],"is_forkable":"1","is_forked":""}

Note "definition":[]. This I assume should hold details of the activity types & timeline I have just attempted to add. The response is as expected, given the data that was provided:


However I was able to create a new case type OK.

Any advice on debugging this would be much appreciated.

3 Answers 3


The commentary suggests that the history of this case-type may have allowed some weird data in.

In case one did want to dig in more, a couple debug tricks that might be interesting:

  • Open the case-type admin UI and edit the current URL to append ?angularDebug=1. This will cause it to display a panel with the "live" content of the CaseType and its definition. This is available in most Angular pages.
  • If you're experimenting on a dev/staging site, you might try unsetting the definition via SQL (UPDATE civicrm_case_type SET definition = NULL where id = ...). This is sometimes useful for forcibly revertig a definition (even if the UI is misbehaved).

I've found the same thing happening, but in our case it was because of an overridden CaseType.php file. It's possible to reproduce in older CiviCRM versions by saving a case type that contains an activity type with & in the name. This will be saved to the database, but when you try to edit it in the UI the ampersand (a reserved character) breaks the XML schema and the UI won't show a standard timeline. Pressing save on this screen will result in the dummy XML you mentioned in the problem:

<?xml version="1.0" encoding="utf-8" ?>


This was fixed a long time ago in CRM-16360 so shouldn't be a problem anymore.


Does it work to just delete the offending files?

  • D'you mean case xml files? There are none for the offending case types, they seem to have been created since the 4.6 upgrade, when case type setup became possible through the UI.
    – davejenx
    Commented Jul 29, 2015 at 20:21
  • Do you have any case types that are functioning correctly? Are there any cases tied to those misbehaving case types?
    – pmoz
    Commented Jul 29, 2015 at 22:56
  • Yes, there are other case types functioning correctly and I can create new ones. And yes, there are cases of the misbehaving case types.
    – davejenx
    Commented Jul 30, 2015 at 11:27
  • 1
    A little more info has come in from the user: they say they created at least one of the misbehaving case types themselves, before the upgrade (so on 4.4), despite not having access to create xml files! So it could be that this case type at least was never set up properly. If that's so, I'm surprised that they were able to create cases of that type in 4.4, I would have expected errors saying the xml file is missing. I'll update here if more info emerges. The inability to add activity types or timelines to these case types in 4.6 & the lack of error messages still needs tracking down I think.
    – davejenx
    Commented Jul 30, 2015 at 15:00
  • This doesn't qualify as debugging, but I have seen were improperly created old case types (prior to the shiny CiviCase UI) hung around and caused some issues. We ended up recreating the case types in the ui, moving the cases to the new types and deleting traces to the old ones. In the end we did it for all case types so we didn't have to deal with the extra work involved with the xml files. If i remember correctly, at the time of the ui improvement, there were some questions about the old xml files and whether or not we still needed them.
    – pmoz
    Commented Sep 27, 2015 at 21:53

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.