Closed ChenglimEar closed 7 months ago
The existing code in /total_{contributions,expenditures}_calculator.rb should be using the From_Date and Thru_Date. The Rpt_Date is when the data was filed and not when the money was collected/spent.
@mikeubell I've made the requested changes and found some additional problems to clean up. Please review the recent changes. Hopefully this is now clean and ready to merge after the travis build is fixed.
When a candidate appears in multiple elections the calculator for
contributions by type
adds up contributions as though they were all attributed to only one of the many elections. This is due to a bug in the code as described below.It looks like the calculation runner is running for a list of all candidates:
When the calculator is created, the candidates by filer_id will have duplicates for candidates that were in more than one election:
Here's where we pull the candidate in the calculator:
Instead of a hash keyed by filer_id, we will wrap it in a hash keyed by election_name. This will ensure that candidates in multiple elections will have an entry for each election and contributions will be added to the correct election entry based on the election associated with the contribution.
This pull request is now extended to make sure all calculators take the election into account.
Some open issues
The
candidate_summary
view is inconsistent with existing SQL in calculators that join with candidates. The existing SQL uses thereporting date
instead of thefrom
andthru
dates. Should we change to be consistent?The data needs to be checked. As expected, the numbers should shift to the right elections. The overall total numbers, however, should remain the same. It appears that this is slightly off, so we have to check the data to determine why. Also, the totals from contributions based on type does not add up exactly to totals not based on type. This exists in the existing code, so there may be something else that needs to be totaled to get the numbers to match. Since the problem is not simply a bug that needs fixing, we have to do a data audit, so instead of holding up this PR for that, we will count on a future data audit to set things right.