购买收费自定义用户组时，扩展积分数据更新错误【附bugfix】

今天做一个积分相关扩展时，发现dz最新版[Discuz! X3.2 正式版【2014-06-18】]中这个bug依旧存在。


bug重现
后台新建两个自定义收费用户组：
假设为用户组A  和 用户组B， gid 分别为 21  和 22 , 收费用户组的购买金钱分别设置为20 和 30.
现新注册一用户，后台修改其金钱(extcredit2) 为  100.
此用户先购买用户组A, 然后再购买用户组B.
然后你会发现pre_common_credit_log 积分日志表中两条购买记录的relatedid 都是21


其实上面购买了两个用户组，一个gid = 21 ， 另一个gid = 22 ,但是这里全记录为21了。。。

测试发现，在X 3.2 更新中并没有修复这个bug.


BUG 分析
bug产生的原因是，
$extgroupidsarray 是包含当前要购买的新用户组的id的所有收费用户组的ID数组，

1. $extgroupidsnew = implode("\t", $extgroupidsarray);

复制代码

pre_common_credit_log 积分日志表中的更新由以下语句带入：
//下面这句是没问题的，因为extgroupids的类型为 `extgroupids` char(20) NOT NULL DEFAULT '',

1. C::t('common_member')->update($_G['uid'], array('groupexpiry' => $groupexpirynew, 'extgroupids' => $extgroupidsnew));

复制代码

1. 
   
2. //下面这条语句就是bug产生的地方了，因为`relatedid` int(10) unsigned NOT NULL, 但是，这里传的第5个参数，是一个string类型的.
   
3. //注意这里pre_common_credit_log 积分日志表中的relatedid是 int类型，假如先购买了gid = 21的组，那么再购买gid = 22的用户组时，
   
4. //$extgroupidsnew 的值为21\t22 , 在插入数据库后，这个字段的值就变成了21了，因此，最终，在数据库中你会看到两个relatedid = 21的数据（如上图示)
   
5. updatemembercount($_G['uid'], array($creditstrans => "-$amount"), true, 'UGP', $extgroupidsnew);
   

复制代码

bug fix
修正为$groupid 就是了：
/source/include/spacecp/spacecp_usergroup.php line 98:

1. 
   
2. updatemembercount($_G['uid'], array($creditstrans => "-$amount"), true, 'UGP', $groupid);
   

复制代码

修正之后，测试OK了（灰色为没有修正bug之前不正确的数据， 红色圈起的为正确的数据）：