CRM-17636 Incorrect information recorded for back-office membership renewals using recurring

          Details

          • Type: Bug
          • Status: Done/Fixed
          • Priority: Minor
          • Resolution: Fixed/Completed
          • Affects Version/s: 4.6.10
          • Fix Version/s: 4.6.11, 4.7
          • Component/s: None
          • Labels:
            None
          • Documentation Required?:
            None
          • Funding Source:
            Contributed Code

            Description

            Customer report (verified on 4.6 & 4.7 'stock' civi'):
            If someone signs up for an auto-renewing membership online, all the correct info is being written to the civicrm_contribution_recur table but if we sign someone up for an auto-renewing membership in the Civi backoffice there is key info not being written to the civicrm_contribution_recur table.

            Missing info: modified_date, invoice_id, next_sched_contribution_date, is_email_receipt
            Fields recorded incorrectly: contribution_status_id, auto_renew

            contribution_status_id is set to 3 and should be 5
            auto_renew is set to 0 and should be 1

            NB: The row in civicrm_contribution_recur for that person is created, and the contribution_recur_id field in the civicrm_contribution table is populated correctly.

              Attachments

                Activity

                [CRM-17636] Incorrect information recorded for back-office membership renewals using recurring
                David Greenberg added a comment - - edited

                Merged 4.7 fix : https://github.com/civicrm/civicrm-core/pull/7336
                Merged 4.6 fix: https://github.com/civicrm/civicrm-core/pull/7337

                Evan added a comment -

                As far as I know, we have this fix added on our site, and we just did a back-office auto-renewing membership this morning. Everything seems to be recording correctly (including https://issues.civicrm.org/jira/browse/CRM-17653) except the auto_renew field is still being set to 0, and when a similar transaction is made on the front-end it is set to 1.

                  People

                  • Assignee:
                    Eileen McNaughton
                    Reporter:
                    Eileen McNaughton

                    Dates

                    • Created:
                      Updated:
                      Resolved: