Uploaded image for project: 'CiviCRM'
  1. CiviCRM
  2. CRM-18651

Adding an event type with a non numeric value breaks functionality.

    Details

    • Type: Bug
    • Status: Done/Fixed
    • Priority: Major
    • Resolution: Fixed/Completed
    • Affects Version/s: 4.7.6, 4.7.7
    • Fix Version/s: 4.7.12
    • Component/s: CiviEvent
    • Labels:
      None
    • Documentation Required?:
      None
    • Sprint:
      4.7.10 Code improvement, 4.7.14 CiviEvent
    • Funding Source:
      Needs Funding

      Description

      Adding an event type with a non numeric value breaks functionality.

      Before 4.7.7, there was no warning or error, but the event_type_id is stored as 0 (I would expect some kind of schema error, as the types don't match).

      since 4.7.7, there is a "Unable to reach the server. Please refresh this page in your browser and try again." error popup when selecting the event type, and when trying to save the event, there is a "Invalid Entity Filter" fatal error. I first thought the bug existed since the CRM_Core_BAO_CustomGroupvalidate::SubTypeByEntity changes (see CRM-18594), but this isn't the case.

      For the default event types it works, as the option_value value is also a string, but it can be casted to an int, which is why it is correctly stored in civicrm_event.event_type_id column.
      But this isn't error proof. If you add a new event type with value "01" and create a new event with that type, it will store the event_type_id as 1, and the event becomes a Conference instead ...

      Just discovered another problem, you can actually add a new event type with the same value as an existing one, and it will override the exiting one in the option list.

      I can think of some solutions, but none of them is good:

      • Change the civicrm_event.event_type_id column type from int to varchar(512), but that doesn't solve the problem of non-unique values
      • Add a separate table for event_types (as for participant_status_types), and use real integer id's. This seems a lot of work to change the code and a little overkill as there isn't any extra information that has to be stored.
      • store the option_value id instead of the value, but this needs a migration process for existing installations.
      • Force the value for option_values for event_types to be numeric (through UI and API). IMO this is very bad (no consistency between values of other option groups) and will break existing installations, as you can't store an existing event type with a non numeric value.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              mollux Mattias Michaux
            • Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: