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.