Details
-
Type:
Bug
-
Status: Done/Fixed
-
Priority:
Major
-
Resolution: Fixed/Completed
-
Affects Version/s: 4.6.3
-
Fix Version/s: 4.6.4
-
Component/s: CiviContribute, CiviMember
-
Labels:None
-
Documentation Required?:None
-
Funding Source:Core Team Funds
Description
The contribution and membership details report contained an error wherein the total was based on more rows than were presented in the report. Here's the summary at the end of the report:
Row(s) Listed 41
Total Amount $ 1,320.00(44)
Average $ 30.00
The report actually contains 41 rows and the total membership contributions for those 41 is less than the $1,320.00 reported in the summary.
I traced the problem to a few contacts that somehow possessed two rows in civicrm_address where is_primary = 1. Once this was fixed the report was correct and consistent.
I do not yet know how two addresses ended up as being primary for the same contact, but our principal user thinks it may be related to merging duplicate contact records, although I was not able to replicate the error in followup testing.
While the ultimate source for the multiple is_primary problem remains undetermined, the report itself should be consistent such that the detail records are based on the same rows as the total.
Attachments
Activity
The atttached pdf (bug-report.pdf) documents how to create the situation that causes the bug in detail.
Please reply back if you are still unable to replicate.
Leo I agree with your point but the DB flaw will not only affect this contribution and membership details" report but also to other reports wherever it uses address attributes, also I have checked for the possibilities that may cause such redundancy to contact's primary address(including merge, export) but I didn't find any. So in my opinion, its better to fix the flaws in DB as the inconsistency in count is not due to some discrepancies in code, also I think we should allow queries to be built like it is - pretending primary address to be one, otherwise we won't be able to know figure the flaw and reports are meant to show what it is. What ya say ? 
I agree that the underlying error (duplicate is_primary = 1 values) needs to be fixed and will bug report it if I can replicate the problem. The fact that it manifests in the reports suggests that the design used within reports executes one query to retrieve the individual rows and a separate query to retrieve the totals. If so, that is an error waiting to happen because it exposes the risk that one query can be edited/adjusted without doing the same adjustment to the other one. In this case, why does the detail portion of the report correctly adjust for the problem while the total does not? The underlying error would have been more self-evident, for example, had the donor with the bad data appeared twice.
PR submitted at: https://github.com/civicrm/civicrm-core/pull/6023
Tested above PR working fine.
Hi Leo,
I can't recreate this issue on my local.
The report contains proper row count for "Total Row(s)" and "Total Amount" columns. For primary address, the condition is already handled in CRM_Report_Form_Member_ContributionDetail::from() at line 523. Hence it is giving proper count for "Total Row(s)" and "Total Amount" for contribution and membership details report.
Following mentioned is the link of screen-shot from my local:
http://snag.gy/ew9Tm.jpg
It would be really helpful, if you could be more specific with the steps.
Thanks.