Details
-
Type:
Bug
-
Status: Done/Fixed
-
Priority:
Minor
-
Resolution: Fixed/Completed
-
Affects Version/s: 3.3.1
-
Fix Version/s: 3.3.2
-
Component/s: None
-
Labels:None
Description
Patch coming shortly as per irc discussion with dgg:
<josephmurray> If an admin membership status is configured, currently the cron updates won't change away from that status. However, they do change other statuses into that status. this seems like a bug. One place this is clear in the code isapi/v2/MembershipStatus. php civicrm_membership_status_calc about line 242 in 3.1: CRM_Member_BAO_MembershipStatus::getMembershipStatusByDate( $dao->start_date,
<josephmurray> $dao->end_date,
<josephmurray> $dao->join_date );
<josephmurray> There is a possible fifth parameter $excludeIsAdmin that is not passed and thus defaults to false.
<josephmurray> I'm concerned about patching this as it may be relied upon by others as an 'undocumented feature' 
<josephmurray> dgg: should I ask dlobo about this or can you indicate if this is something that is a bug or intended behaviour?
<dgg> josephmurray: seems like a bug
| <-- chastell has left freenode (Quit: Leaving.) <josephmurray> good <josephmurray> i'll roll a patch <dgg> what's the use case for that api function? <josephmurray> not sure about all of them, but it is used by bin/UpdateMembershipRecord.php <josephmurray> that's the one that is causing me grief <dgg> so just to make sure i understand the problem <josephmurray> about line 180 in 3.1 <dgg> currently the call to that api isn't passing excludeIsAdmin flag - so the cron job is setting some membershps to "admin only" statuses <dgg> is that the issue? <josephmurray> yes <dgg> so i definitely agree that UpdateMembershipRecord.php should pass that flag in the parms to the api, and the api should check for that flag <josephmurray> agreed <dgg> since the BAO default is false for that flag, that should also be the default in the api (so existing behavior for other situations than the cron job call are unaffected) <josephmurray> okay <josephmurray> yes <dgg> and patch should be against 3.3 branch svn |