Affects Version/s: 4.7.7, 4.7.9, 4.7.10, 4.7.11, 4.7.12
Fix Version/s: 4.7.14
Versioning Impact:Patch (backwards-compatible bug fixes)
Funding Source:Contributed Code
This appears to be a re-emergence of a bug
CRM-19094 with different consequences, but essentially the same problem. A munging of the entity_table value in the LineItem BAO results in the misuse of the entity_id. It looks like the attempted fix for CRM-19094 has been removed in master, but is present with a code-comment referencing the issue in recent versions.
Actually the code is still there: https://github.com/civicrm/civicrm-core/blob/master/CRM/Price/BAO/LineItem.php#L443
I don't fully understand all of the code involved, but it looks like work was done recently on ARB that is maybe causing the BAO logic to get invoked multiple times, including one time when the entity_table and entity_id are not yet properly set to that of the membership.
The correct values are used to invoke the function a second time, and the target records are updates as they should.
HOWEVER, when the LineItem BAO is invoked the first time, the entity_id is that of the contribution for the LineItem, and IF a Membership is found with that ID, a Membership Payment record is generated and the Membership is erroneously updated.
NOTE, that a collision of membership and contribution ID's is necessary for this bug to manifest.
This gist contains SQL code that can be used to audit memberships that are improperly associated with a contribution through an erroneous Membership Payment:
I inspected the history of commits and found the following issues to be related. This was caused by a convergence of multiple changes activating some very old code.
Here is the code in question in the form of a commit to remove it (PR forthcoming):
I propose that the inference that the presence of a membership type ID means that the entity_table should be set is a bit of magic that has turned bad as the calling logic has changed.