Answers.Body: <p>Not a direct answer but you could create a different membership <strong>type</strong> each year and disable the previous year's type. It sounds like you'd want these reported separately in reports anyway?</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-01-22T18:10:00.630Z
Answers.Text: Clever! But I think that will interfere with the people who genuinely *do* renew their memberships each year, for whom we *do* want to see a continual membership.
Answers.UserDisplayName: artfulrobot
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-01-25T15:43:26.077Z
Answers.Text: Or at the end of the year add a tag to people who were members that year? (e.g. 2018 member, 2019 member, etc.)
Answers.UserDisplayName: Laryn
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-01-22T18:02:14.560Z
Answers.LastActivityDate: 2019-01-22T18:02:14.560Z
Answers.UserDisplayName: Demerit
Answers.Body: <p>I do not believe this is possible as of CiviCRM 5.4 at least.</p>
  
  <p>The logic is coded in <code>civicrm/CRM/Member/BAO/Membership.php</code> so the only way to override this is with a core override file, which is a maintenance headache since it will need re-working on ever upgrade.</p>
  
  <p>This patch seems to make it work as I think it should:</p>
  
  
  
  <pre><code>diff --git a/civicrm/CRM/Member/BAO/Membership.php b/all/modules/civicrm/CRM/Member/BAO/Membership.php
  index 18269014..7713ee9e 100644
  --- a/civicrm/CRM/Member/BAO/Membership.php
  +++ b/civicrm/CRM/Member/BAO/Membership.php
  @@ -1860,6 +1860,14 @@ INNER JOIN  civicrm_contact contact ON ( contact.id = membership.contact_id AND
       $currentMembership = CRM_Member_BAO_Membership::getContactMembership($contactID, $membershipTypeID,
         $is_test, $membershipID, TRUE
       );
  +
  +    // -------Begin patch to create new memberships if last one had expired-------
  +    if ($currentMembership &amp;&amp; !$currentMembership['is_current_member']) {
  +      // Force a new membership.
  +      $currentMembership = NULL;
  +    }
  +    // -------End patch to create new memberships if last one had expired-------
  +
       if ($currentMembership) {
         $renewalMode = TRUE;
  
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-01-25T15:41:32.310Z
Answers.Text: If you leave the old membership expired and create a new one, does it open up potential false positives on searches for people with expired memberships?
Answers.UserDisplayName: Laryn
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-01-28T09:01:37.580Z
Answers.Text: Yes it does. It also means that if I search 'Current Member: no'  then there is a false positive because of the expired membership. I think this is the fault of the membership search though. I think the data should accurately reflect the truth, and I think the search should enable interpretation of that data back to real world truth. I don't think we should bend the data to fit the interpretation. But yes, this is important to understand and ultimately iron out!
Answers.UserDisplayName: artfulrobot
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-03-06T18:17:48.317Z
Answers.Text: Thank you so much for this! Far simpler than the other workarounds I'd seen. I am definitely happy to manually override this file to get this feature.
Answers.UserDisplayName: Andrew West
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-09-27T11:32:30.457Z
Answers.Text: @AndrewWest You may be interested in https://github.com/artfulrobot/patchwork which auto-patches core on the fly (as in if you upgrade core it notices the change and reapplies the patch).
Answers.UserDisplayName: artfulrobot
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-09-29T20:13:21.523Z
Answers.Text: Some of the false positives could be removed perhaps with an approach of setting a previously expired membership to a different status eg Previously Expired. I think we took this approach once but do not recall if the client was happy to manage it manually or if we had a script/fix to do it
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-09-05T17:55:03.483Z
Answers.Text: Just noting that this code is no longer in CRM_Member_BAO_Membership and has been moved to CRM_Contribute_Form_Contribution_Confirm. It's in a function called legacyProcessMembership() though so I imagine it'll change at some point
Answers.UserDisplayName: Andrew West
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-04-12T13:03:32.730Z
Answers.Text: The Link posted by @artfulrobot is now located at https://lab.civicrm.org/extensions/patchwork
Answers.UserDisplayName: emma
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-01-22T16:36:32.047Z
Answers.LastActivityDate: 2019-01-22T16:36:32.047Z
Answers.UserDisplayName: artfulrobot
Body: <p>Consider this:</p>
  
  <ol>
  <li><p>Wilma becomes a member on 1 Jan 2016, but does not renew at the end of the year.</p></li>
  <li><p>(so throughout 2017, 2018, Wilma is not a member)</p></li>
  <li><p>Wilma joins again in Jan 2019.</p></li>
  </ol>
  
  <p>According to the <a href="https://docs.civicrm.org/user/en/latest/membership/renewals/" rel="noreferrer">documentation</a>, CiviMember will find the original membership and change the start date to 1 Jan 2019 and the end date to 31 Dec 2019, and set the status to live (or new etc.)</p>
  
  <p>This now looks like Wilma has been a member since 1 Jan 2016, but that's not the case.</p>
  
  <p><strong>Is there a way to have CiviMember create a new membership and leave old expired ones (i.e. those with "member: No" configured for their membership status) as-was?</strong></p>
  
  <p>There's a <a href="https://civicrm.stackexchange.com/questions/27343/create-a-new-membership-rather-than-renew-an-existing-one">similar question</a> that seems to be focussed on a WordPress/Caldera forms environment, but I'm asking about CiviCRM's native forms, hence the separate question.</p>
  
Tags: <drupal><civimember>
Title: How to add new membership if renewed after old membership expired (native CiviCRM / Drupal)
ThreadText: # How to add new membership if renewed after old membership expired (native CiviCRM / Drupal)
  
  (Asked by: username_0 on 2019-01-22)
  
  Consider this:
  
  1. Wilma becomes a member on 1 Jan 2016, but does not renew at the end of the year.
  2. (so throughout 2017, 2018, Wilma is not a member)
  3. Wilma joins again in Jan 2019.
  
  According to the [documentation](https://docs.civicrm.org/user/en/latest/membership/renewals/), CiviMember will find the original membership and change the start date to 1 Jan 2019 and the end date to 31 Dec 2019, and set the status to live (or new etc.)
  
  This now looks like Wilma has been a member since 1 Jan 2016, but that's not the case.
  
  **Is there a way to have CiviMember create a new membership and leave old expired ones (i.e. those with "member: No" configured for their membership status) as-was?**
  
  There's a [similar question](https://civicrm.stackexchange.com/questions/27343/create-a-new-membership-rather-than-renew-an-existing-one) that seems to be focussed on a WordPress/Caldera forms environment, but I'm asking about CiviCRM's native forms, hence the separate question.
  
  **Tags:** drupal, civimember
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2019-01-22. Score: 6 | Accepted answer
  
  I do not believe this is possible as of CiviCRM 5.4 at least.
  The logic is coded in civicrm/CRM/Member/BAO/Membership.php so the only way to override this is with a core override file, which is a maintenance headache since it will need re-working on ever upgrade.
  This patch seems to make it work as I think it should:
  diff --git a/civicrm/CRM/Member/BAO/Membership.php b/all/modules/civicrm/CRM/Member/BAO/Membership.php
  index 18269014..7713ee9e 100644
  --- a/civicrm/CRM/Member/BAO/Membership.php
  +++ b/civicrm/CRM/Member/BAO/Membership.php
  @@ -1860,6 +1860,14 @@ INNER JOIN  civicrm_contact contact ON ( contact.id = membership.contact_id AND
       $currentMembership = CRM_Member_BAO_Membership::getContactMembership($contactID, $membershipTypeID,
         $is_test, $membershipID, TRUE
       );
  +
  +    // -------Begin patch to create new memberships if last one had expired-------
  +    if ($currentMembership && !$currentMembership['is_current_member']) {
  +      // Force a new membership.
  +      $currentMembership = NULL;
  +    }
  +    // -------End patch to create new memberships if last one had expired-------
  +
       if ($currentMembership) {
         $renewalMode = TRUE;
  
  > **Comments:**
  > **username_2**: If you leave the old membership expired and create a new one, does it open up potential false positives on searches for people with expired memberships?  
  > **username_0**: Yes it does. It also means that if I search 'Current Member: no'  then there is a false positive because of the expired membership. I think this is the fault of the membership search though. I think the data should accurately reflect the truth, and I think the search should enable interpretation of that data back to real world truth. I don't think we should bend the data to fit the interpretation. But yes, this is important to understand and ultimately iron out!  
  > **username_3**: Thank you so much for this! Far simpler than the other workarounds I'd seen. I am definitely happy to manually override this file to get this feature.  
  > **username_0**: @AndrewWest You may be interested in https://github.com/username_0/patchwork which auto-patches core on the fly (as in if you upgrade core it notices the change and reapplies the patch).  
  > **username_4**: Some of the false positives could be removed perhaps with an approach of setting a previously expired membership to a different status eg Previously Expired. I think we took this approach once but do not recall if the client was happy to manage it manually or if we had a script/fix to do it  
  > **username_3**: Just noting that this code is no longer in CRM_Member_BAO_Membership and has been moved to CRM_Contribute_Form_Contribution_Confirm. It's in a function called legacyProcessMembership() though so I imagine it'll change at some point  
  > **username_5**: The Link posted by @username_0 is now located at https://lab.civicrm.org/extensions/patchwork  
  
  ---
  
  ### Answer by username_1 on 2019-01-22. Score: 0
  
  Not a direct answer but you could create a different membership **type** each year and disable the previous year's type. It sounds like you'd want these reported separately in reports anyway?
  
  > **Comments:**
  > **username_0**: Clever! But I think that will interfere with the people who genuinely *do* renew their memberships each year, for whom we *do* want to see a continual membership.  
  > **username_2**: Or at the end of the year add a tag to people who were members that year? (e.g. 2018 member, 2019 member, etc.)  
  
  ---
  
  