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

logging revert: boolean breaks if reverting to null

    Details

    • Type: Bug
    • Status: Done/Fixed
    • Priority: Trivial
    • Resolution: Fixed/Completed
    • Affects Version/s: 4.6.10
    • Fix Version/s: 4.7
    • Component/s: Core CiviCRM, NYSS
    • Labels:
    • Documentation Required?:
      None
    • Funding Source:
      Core Team Contract
    • Payment Status:
      Paid

      Description

      to reproduce:

      • create a custom data set with a boolean (yes or no) field and one other field
      • enable enhanced logging
      • enter a contact record and set a value for the other field
      • enter edit the block again and set the boolean field to yes
      • visit the logging tab and revert the last change, which should revert the boolean from yes to null (no selection)

      result: fatal error. one of the parameters is not of type boolean.

      the problem is that when the parameters are passed to the SQL, an empty value is not valid using the boolean type rule.

      one option to fix it is to add a new case here:
      https://github.com/civicrm/civicrm-core/blob/master/CRM/Logging/Reverter.php#L157

      case 'Boolean':
        $value = (empty($value)) ? 0 : 1;
        break;

      that just forces an empty value to be 0 which allows the Boolean rule to pass successfully. however – it's not really an accurate handling of the data. an empty value is not the same as a false value for boolean fields. if the field is not required, the fact that it has not been answered may be meaningful, and not equivalent with a "no".

      but I'm not sure the best way to handle it. should the Boolean rule be modified to allow a null value? that rule is used all over the place, and I'm sure in many of those cases a null value should not be accepted. should we build our own validation directly in this function and then set the parameter type to String so that it passes the standard query execution validation? I can help work on this, but would like some input from the core team as to the best way to approach.

        Attachments

          Activity

            People

            • Assignee:
              monish.deb Monish Deb
              Reporter:
              lcdweb Brian Shaughnessy
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 2 hours
                2h