{"push_id":723767499,"size":2,"distinct_size":2,"ref":"refs/heads/4.4","head":"bfb3834e8c2b4436731ebf19c8ecc3192767e000","before":"af9b65bb6db2b726349a0f2d0dc638aafe86f03a","commits":[{"sha":"459be062de89ad1b46b1da9116eb987b00c215bf","author":{"email":"0c4ef17994f82486b6796a3c46585026e0b2f05d@digitalcourage.de","name":"Olaf Buddenhagen"},"message":"Upgrade: Fix `value` for added `option_value` entries in various places\n\nIn several places, the highest existing option value for a group was\nbeing determined using max(value), which breaks as soon as there are\nvalues above 9, because `value` is defined as a varchar rather than\ninteger for lulz. In most instances, this is taken care of by using\nmax(round(value)) instead -- but not everwhere. Fix the wrong ones.\n\n(BTW, convert(value, decimal) would be more obvious than round()\nIMHO...)\n\nNote that while this patch is against master, it should be backported to\nall maintained branches.\n\nPS. Database normalisation is only for wimps who can't handle the\nanomalies, right?...","distinct":true,"url":"https://api.github.com/repos/civicrm/civicrm-core/commits/459be062de89ad1b46b1da9116eb987b00c215bf"},{"sha":"bfb3834e8c2b4436731ebf19c8ecc3192767e000","author":{"email":"64517a7a8e5ab470725947eb472340f4fbdb9e12@mcnaughty.com","name":"Eileen McNaughton"},"message":"Merge pull request #5620 from sfe-ev/fix-upgrade-option_value-4.4\n\nUpgrade: Fix `value` for added `option_value` entries in various places","distinct":true,"url":"https://api.github.com/repos/civicrm/civicrm-core/commits/bfb3834e8c2b4436731ebf19c8ecc3192767e000"}]}