CiviCRM
  1. CiviCRM
  2. CRM-4989

Contact's contribution totals/averages shouldn't cover pending contributions

    Details

    • Type: Improvement Improvement
    • Status: Reopened
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 3.0
    • Fix Version/s: 3.1
    • Component/s: CiviContribute
    • Labels:
      None

      Description

      Currently, the total/average contribution amounts on a contact's tab cover pending contributions.

      We should make a call whether we should stick to this approach (because we assume pending contributions will come in eventually, and the total/average should be about what a given contact pledged) or whether we should change these numbers to reflect only the contributions which are complete - i.e., only 'hard cash' that we indeed for sure know was contributed by that contact already. If the latter, we need to fix the code. :)

        Activity

        Hide
        Donald A. Lobo added a comment -

        we were tacking on an additional clause for cancellations which checked the cancel date rather than the status id. I fixed this to get the totals of only contributions that are completed
        Show
        Donald A. Lobo added a comment - we were tacking on an additional clause for cancellations which checked the cancel date rather than the status id. I fixed this to get the totals of only contributions that are completed
        Hide
        Yashodha Chaku added a comment -
        assigning for 3.1 verification
        Show
        Yashodha Chaku added a comment - assigning for 3.1 verification
        Hide
        Rahul Bile added a comment -
        Checked in r-25215
        Show
        Rahul Bile added a comment - Checked in r-25215
        Hide
        Brian Shaughnessy added a comment -
        I think this should be revisited. The same summaryContribution function is used for contribution searches and can yield confusing results. For example, someone might search for contribs in a date range and have the search return a different number of records than is counted by this summary block. Or someone may conduct a search to find out how many pending contributions are in the system, but the summary block states a count of 0 and no total (because only completed records are calculated).

        I propose we add a parameter $completed = 1 to the function and default to that behavior (for use on the contact tab per the issue). But for the contrib searches we pass $completed = 0 and bypass the status = completed where clause.

        let me know if that sounds ok and I'll submit a patch.
         
        Show
        Brian Shaughnessy added a comment - I think this should be revisited. The same summaryContribution function is used for contribution searches and can yield confusing results. For example, someone might search for contribs in a date range and have the search return a different number of records than is counted by this summary block. Or someone may conduct a search to find out how many pending contributions are in the system, but the summary block states a count of 0 and no total (because only completed records are calculated). I propose we add a parameter $completed = 1 to the function and default to that behavior (for use on the contact tab per the issue). But for the contrib searches we pass $completed = 0 and bypass the status = completed where clause. let me know if that sounds ok and I'll submit a patch.  

          People

          • Assignee:
            Rahul Bile
            Reporter:
            Piotr Szotkowski
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development