Merge pull request #17625 from demeritcowboy/missing-activitytype-5.27

#1822 - Fix missing newly created activity types from the dropdown on the new activity form

CRM/Core/DAO/OptionValue.php

@@ -6,7 +6,7 @@
  *
  * Generated from xml/schema/CRM/Core/OptionValue.xml
  * DO NOT EDIT.  Generated by CRM_Core_CodeGen
- * (GenCodeChecksum:7aa11987c26800632c3798b4cfce95c1)
+ * (GenCodeChecksum:5997192c77d86867e8d13c353dd02351)
  */
 
 /**
@@ -281,7 +281,7 @@ class CRM_Core_DAO_OptionValue extends CRM_Core_DAO {
           'title' => ts('Filter'),
           'description' => ts('Bitwise logic can be used to create subsets of options within an option_group for different uses.'),
           'where' => 'civicrm_option_value.filter',
-          'default' => 'NULL',
+          'default' => '0',
           'table_name' => 'civicrm_option_value',
           'entity' => 'OptionValue',
           'bao' => 'CRM_Core_BAO_OptionValue',

CRM/Upgrade/Incremental/sql/5.27.beta1.mysql.tpl

 {* file to handle db changes in 5.27.beta1 during upgrade *}
+ALTER TABLE civicrm_option_value MODIFY COLUMN `filter` int unsigned DEFAULT 0 COMMENT 'Bitwise logic can be used to create subsets of options within an option_group for different uses.';
+
+-- To think about: This will update ones where someone has explicitly set it to NULL for their own purposes and they don't care about the dropdowns. How likely is that? How can we tell if it's one they created since 5.26 and didn't intend to set it to NULL?
+UPDATE civicrm_option_value ov
+INNER JOIN civicrm_option_group og ON (ov.option_group_id = og.id AND og.name='activity_type')
+SET ov.filter = 0
+WHERE ov.filter IS NULL;

xml/schema/Core/OptionValue.xml

@@ -82,7 +82,7 @@
   <field>
     <name>filter</name>
     <type>int unsigned</type>
-    <default>NULL</default>
+    <default>0</default>
     <comment>Bitwise logic can be used to create subsets of options within an option_group for different uses.</comment>
     <add>1.5</add>
   </field>