Answers.Body: <p>Not sure how else to mark this as answered, so I am accepting the explanation from Parvez in the comments below. Basically, it seems that once &quot;Expired&quot; status is achieved, it no longer gets changed.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-12-02T18:47:39.793Z
Answers.Text: if you have enough 'points' you should be able to ACCEPT your answer, and i think the way you are doing it is good enough, unless Parvez wants to claim the points (i doubt it) by changing his comments to an Answer.
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-12-01T22:17:19.203Z
Answers.LastActivityDate: 2020-12-01T22:17:19.203Z
Answers.UserDisplayName: The Amateur
Answers.Body: <p>We have the exact same problem, as described below. However, to cut to the chase:
  We were updating memberships by importing new membership end dates but status was never changed from expired. <em><strong>Finally we realized that importing an appropriate membership status (or for that matter <em>any</em> status that is not expired) is necessary. This produces a membership that now will be processed by the next run of the cron job and correctly categorized. Problem solved, and more importantly, problem understood!</strong></em>
  More details below -------------</p>
  <p>Once a membership is set to &quot;Expired&quot; it never seems to be examined again. We have 900 memberships, 350 of which should be either current, new or grace, but only 123 of which are currently indicated to be current, new or grace. Whenever we run the membership status rules, it only processes 123 memberships, and doesn't change any of those.</p>
  <p>We modify membership end dates via a membership upload process and maybe that is the issue. We know that the upload won't change the status, but when we run the update membership status cron job, it does not change the status of someone whose membership end date is months or years in the future. They are still &quot;expired&quot;, .
  and seemingly, once &quot;expired&quot; the membership stays that way. If I use &quot;edit&quot; on the membership and move the end date by one day, it then is evaluated as current and all is well. Somehow the membership status rules cron job doesn't examine any memberships whose status isn't current, grace or new.</p>
  <p>Update: Changing the order of status rules didn't change the behavior - we put the Expired rule at the top, and it still only seems to look at the 123 that were current memberships.</p>
  <p>UPDATE - as a test: exporting four of the incorrectly labeled Expired memberships and then importing them as New, Current, Grace and Pending, we find that all four memberships have their status's changed to these four, and then running the membership status cron job changes all of these to the correct &quot;current&quot; status.</p>
  <p>UPDATE 4-28-21 @petednz mentions that this answer isn't completely clear. So to clarify: updating membership end date using the membership import process requires that a membership status also be uploaded at that time. Just changing the end date to a future time does not remove the &quot;expired&quot; status, and the cron job doesn't apparently examine expired memberships. So importing any of the active statuses (new, current, grace, and pending) is all that is needed to make the memberships eligible for examination and categorization by the cron job. <em><strong>Don't upload just dates, but instead include an appropriate status.</strong></em></p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-02-25T18:17:35.063Z
Answers.Text: Can you reframe the above so it is more clearly an Answer before someone comes along and rejects it or suggests you make it a new Question
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-05-04T20:42:02.963Z
Answers.Text: Pete - thanks for mentioning this - I've updated it for clarity
Answers.UserDisplayName: Rick Cunningham
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-02-25T14:33:06.060Z
Answers.LastActivityDate: 2021-04-28T16:27:04.327Z
Answers.LastEditDate: 2021-04-28T16:27:04.327Z
Answers.UserDisplayName: Rick Cunningham
Body: <p>Using CiviCRM 5.31 on Drupal 7.75, but this has been a long-standing issue for me. It has never worked...</p>
  <p>I have several membership status rules as outlined in the screenshot below. All of them work as expected and membership status gets updated when it should, EXCEPT for the &quot;Old&quot; status. Memberships that are &quot;Expired&quot; never get changed to &quot;Old&quot;. We need that distinction in our system and I have had to do it manually for years.</p>
  <p>Any ideas on why this might not be working? Thanks in advance.</p>
  <p><a href="https://i.sstatic.net/Uxmvg.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Uxmvg.png" alt="enter image description here" /></a></p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-12-01T01:48:00.360Z
Comments.Text: From a quick look I'd suggest you need to add an end date adjustment of at least 9 months. Otherwise it doesn't quite make sense i.e. the Old status starts after end date + 9 months and ends at the end date, which seems a bit illogical. I'd try it set to maybe +100months or something to test it out.
Comments.UserDisplayName: Parvez Saleh
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-12-01T16:32:44.977Z
Comments.Text: Thanks for the suggestion Parvez. I tried adding an end adjustment to the Old status, but it has no effect unfortunately.
Comments.UserDisplayName: The Amateur
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-12-01T17:11:09.483Z
Comments.Text: oh wait, I think I know what it is. Expired is basically a status that civi turns into no longer active and it wont touch it again. In effect its like a status override - I think because the member flag is set to No. So from that point the status rules will no longer apply. I'm 99% thats the case! Funnily enough there was a question about why CiviRules wouldn't allow status change of memberships, I couldn't see a user case for it before but this is probably one!
Comments.UserDisplayName: Parvez Saleh
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-12-01T18:24:58.630Z
Comments.Text: would it work to change the order (conceptually) ie so you have Expired as the final status (renamed if necessary), so it works as eg Newly Expired (which would be a custom status) and then Long-time Expired (renamed Expired status)? Not sure how this will work retrospectively so may require some sql to give effect to the changes
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-12-01T22:12:29.377Z
Comments.Text: Thanks Parvez and petednz. That would explain things. I will give the suggestion to adjust the order a try. Cheers.
Comments.UserDisplayName: The Amateur
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-12-01T22:19:56.533Z
Comments.Text: Now that I think about it, it remains to be seen if it is the "Expired" status or the condition of the member flag being "No" that prevents any further status updates. If the latter, then I am out of luck, since the "Newly expired" are not members. We'll see.
Comments.UserDisplayName: The Amateur
Tags: <civimember><status>
Title: Why are only some membership status rules working?
ThreadText: # Why are only some membership status rules working?
  
  (Asked by: username_0 on 2020-11-30)
  
  Using CiviCRM 5.31 on Drupal 7.75, but this has been a long-standing issue for me. It has never worked...
  
  I have several membership status rules as outlined in the screenshot below. All of them work as expected and membership status gets updated when it should, EXCEPT for the "Old" status. Memberships that are "Expired" never get changed to "Old". We need that distinction in our system and I have had to do it manually for years.
  
  Any ideas on why this might not be working? Thanks in advance.
  
  [![enter image description here](https://i.sstatic.net/Uxmvg.png)](https://i.sstatic.net/Uxmvg.png)
  
  **Tags:** civimember, status
  
  > **Comments:**
  > **username_1**: From a quick look I'd suggest you need to add an end date adjustment of at least 9 months. Otherwise it doesn't quite make sense i.e. the Old status starts after end date + 9 months and ends at the end date, which seems a bit illogical. I'd try it set to maybe +100months or something to test it out.  
  > **username_0**: Thanks for the suggestion username_1. I tried adding an end adjustment to the Old status, but it has no effect unfortunately.  
  > **username_1**: oh wait, I think I know what it is. Expired is basically a status that civi turns into no longer active and it wont touch it again. In effect its like a status override - I think because the member flag is set to No. So from that point the status rules will no longer apply. I'm 99% thats the case! Funnily enough there was a question about why CiviRules wouldn't allow status change of memberships, I couldn't see a user case for it before but this is probably one!  
  > **username_2**: would it work to change the order (conceptually) ie so you have Expired as the final status (renamed if necessary), so it works as eg Newly Expired (which would be a custom status) and then Long-time Expired (renamed Expired status)? Not sure how this will work retrospectively so may require some sql to give effect to the changes  
  > **username_0**: Thanks username_1 and username_2. That would explain things. I will give the suggestion to adjust the order a try. Cheers.  
  > **username_0**: Now that I think about it, it remains to be seen if it is the "Expired" status or the condition of the member flag being "No" that prevents any further status updates. If the latter, then I am out of luck, since the "Newly expired" are not members. We'll see.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2020-12-01. Score: 2 | Accepted answer
  
  Not sure how else to mark this as answered, so I am accepting the explanation from username_1 in the comments below. Basically, it seems that once "Expired" status is achieved, it no longer gets changed.
  
  > **Comments:**
  > **username_2**: if you have enough 'points' you should be able to ACCEPT your answer, and i think the way you are doing it is good enough, unless username_1 wants to claim the points (i doubt it) by changing his comments to an Answer.  
  
  ---
  
  ### Answer by username_3 on 2021-02-25. Score: 2
  
  We have the exact same problem, as described below. However, to cut to the chase:
  We were updating memberships by importing new membership end dates but status was never changed from expired. ***Finally we realized that importing an appropriate membership status (or for that matter *any* status that is not expired) is necessary. This produces a membership that now will be processed by the next run of the cron job and correctly categorized. Problem solved, and more importantly, problem understood!***
  More details below -------------
  
  Once a membership is set to "Expired" it never seems to be examined again. We have 900 memberships, 350 of which should be either current, new or grace, but only 123 of which are currently indicated to be current, new or grace. Whenever we run the membership status rules, it only processes 123 memberships, and doesn't change any of those.
  
  We modify membership end dates via a membership upload process and maybe that is the issue. We know that the upload won't change the status, but when we run the update membership status cron job, it does not change the status of someone whose membership end date is months or years in the future. They are still "expired", .
  and seemingly, once "expired" the membership stays that way. If I use "edit" on the membership and move the end date by one day, it then is evaluated as current and all is well. Somehow the membership status rules cron job doesn't examine any memberships whose status isn't current, grace or new.
  
  Update: Changing the order of status rules didn't change the behavior - we put the Expired rule at the top, and it still only seems to look at the 123 that were current memberships.
  
  UPDATE - as a test: exporting four of the incorrectly labeled Expired memberships and then importing them as New, Current, Grace and Pending, we find that all four memberships have their status's changed to these four, and then running the membership status cron job changes all of these to the correct "current" status.
  
  UPDATE 4-28-21 @username_2 mentions that this answer isn't completely clear. So to clarify: updating membership end date using the membership import process requires that a membership status also be uploaded at that time. Just changing the end date to a future time does not remove the "expired" status, and the cron job doesn't apparently examine expired memberships. So importing any of the active statuses (new, current, grace, and pending) is all that is needed to make the memberships eligible for examination and categorization by the cron job. ***Don't upload just dates, but instead include an appropriate status.***
  
  > **Comments:**
  > **username_2**: Can you reframe the above so it is more clearly an Answer before someone comes along and rejects it or suggests you make it a new Question  
  > **username_3**: Pete - thanks for mentioning this - I've updated it for clarity  
  
  ---
  
  