Answers.Body: <p>A real fix is still needed but the following procedure appears to provide a reliable workaround:</p>
  
  <ul>
  <li>Set the Grace period to the new value; </li>
  <li>Disable the status 'Expired';  </li>
  <li>Run the task 'Update Membership Statuses' so that memberships within the new Grace period are set to 'Grace'; (but don't just run Cron, as Cron only runs this particular update task once a day.) </li>
  <li>Re-enable the status 'Expired';  </li>
  <li>Run the update task a second time to check that memberships that really should have expired do indeed correctly show as 'Expired'. </li>
  </ul>
  
  <p>David</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-05-16T15:01:35.550Z
Answers.LastActivityDate: 2016-05-16T15:39:20.180Z
Answers.LastEditDate: 2016-05-16T15:39:20.180Z
Answers.UserDisplayName: David Hepper
Answers.Body: <p>The scheduled job calls the function <code>CRM_Member_BAO_Membership::updateAllMembershipStatus()</code> . This starts by getting all memberships that have types that are enabled, and don't have is_test set. For each:</p>
  
  <ul>
  <li>it then checks whether the contact is deceased (this seems to dominate over other rules)</li>
  <li>it skips inherited (non-primary) memberships</li>
  <li>it skips status overrides, and the specific statuses Pending, Cancelled and Expired</li>
  <li>it calculates the new status, and if that has changed, saves it.</li>
  </ul>
  
  <p>(Edit: My first answer confused is_active with is_current_member. But it stands that it excludes expired memberships further down.)</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-04T22:42:11.460Z
Answers.Text: So David, this means you should check if the contact is deceased, if its memberships are inherited from a group or a relationship, and if the membership is being overridden.
Answers.UserDisplayName: JohnFF
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-04T22:44:10.937Z
Answers.Text: He's talking about setting Expired back to Grace- I think the scheduled job ignoring Expired is deliberate.
Answers.UserDisplayName: DaveFF
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-05T07:44:05.103Z
Answers.Text: The scheduled task update should produce the same result as a manual re-save of the Membership, surely, except in the case where it cannot find a valid status and leaves the current status untouched. It should definitely recalculate if the current status is Expired; otherwise you can't use the rules to extend the Grace period.
Answers.UserDisplayName: David Hepper
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-05T07:46:19.167Z
Answers.Text: Workaround: - disable status Expired; - run the update task; - enable status Expired; - run the update task. Result!
Answers.UserDisplayName: David Hepper
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-06T19:26:24.270Z
Answers.Text: David - worth adding that as an answer.
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-04T18:35:20.187Z
Answers.LastActivityDate: 2016-03-04T18:35:20.187Z
Answers.UserDisplayName: DaveFF
Answers.Body: <p>Incidentally I know that there were a lot of bugs in 4.4 with regard to memberships not being transferred along relationships successfully. Have you looked at issues.civicrm.org?</p>
  
  <p><strong>Recommended solution:</strong> I would recommend updating to 4.4.18. You'll get so many bug fixes, and this may be one of them (I haven't checked). You'll also get important security fixes.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-04T16:20:26.843Z
Answers.LastActivityDate: 2016-03-04T16:20:26.843Z
Answers.UserDisplayName: JohnFF
Body: <p>There seems to be a bug in the scheduled task 'Update Membership Statuses' in 4.4.3. 
  We have just changed the rule for status 'Grace' to allow an extra month for the grace period. If I re-save a membership manually it changes the recently-expired membership back to a status of Grace. So far so good and it proves that the rules are in the correct order. 
  But I would now expect the scheduled task to change the others that have recently Expired back to Grace. <em>It doesn't.</em> It reports "Finished execution of Update Membership Statuses with result: Success (Processed 878 membership records. Updated 0 records.)"</p>
  
  <p>Scheduled status updates have worked in the past. </p>
  
  <p>I've looked at '<a href="https://civicrm.stackexchange.com/questions/3987/membership-statuses-not-being-updated">membership statuses not being updated</a>' and '<a href="https://civicrm.stackexchange.com/questions/9206/update-membership-status-automatically">Update membership status automatically</a>' and even the very old '<a href="https://forum.civicrm.org/index.php?topic=13921.0" rel="nofollow noreferrer">Membership status not updating from pending</a>' but these are all simpler cases.</p>
  
  <p>Clearing the Civi caches didn't help.
  Is the scheduled task logic different to the immediate logic?
  CiviCRM is so damn fragile!
  David</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-04T16:19:17.760Z
Comments.Text: Thanks, JohnFF, but iIn this case all memberships are Individual and there are no relevant Relationships.
Comments.UserDisplayName: David Hepper
Tags: <civimember><scheduled-job>
Title: Bug in the scheduled update of Membership Statuses?
ThreadText: # Bug in the scheduled update of Membership Statuses?
  
  (Asked by: username_0 on 2016-03-04)
  
  There seems to be a bug in the scheduled task 'Update Membership Statuses' in 4.4.3.
  We have just changed the rule for status 'Grace' to allow an extra month for the grace period. If I re-save a membership manually it changes the recently-expired membership back to a status of Grace. So far so good and it proves that the rules are in the correct order.
  But I would now expect the scheduled task to change the others that have recently Expired back to Grace. *It doesn't.* It reports "Finished execution of Update Membership Statuses with result: Success (Processed 878 membership records. Updated 0 records.)"
  
  Scheduled status updates have worked in the past.
  
  I've looked at '[membership statuses not being updated](https://civicrm.stackexchange.com/questions/3987/membership-statuses-not-being-updated)' and '[Update membership status automatically](https://civicrm.stackexchange.com/questions/9206/update-membership-status-automatically)' and even the very old '[Membership status not updating from pending](https://forum.civicrm.org/index.php?topic=13921.0)' but these are all simpler cases.
  
  Clearing the Civi caches didn't help.
  Is the scheduled task logic different to the immediate logic?
  CiviCRM is so damn fragile!
  username_0
  
  **Tags:** civimember, scheduled-job
  
  > **Comments:**
  > **username_0**: Thanks, username_2, but iIn this case all memberships are Individual and there are no relevant Relationships.  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_0 on 2016-05-16. Score: 1
  
  A real fix is still needed but the following procedure appears to provide a reliable workaround:
  
  * Set the Grace period to the new value;
  * Disable the status 'Expired';
  * Run the task 'Update Membership Statuses' so that memberships within the new Grace period are set to 'Grace'; (but don't just run Cron, as Cron only runs this particular update task once a day.)
  * Re-enable the status 'Expired';
  * Run the update task a second time to check that memberships that really should have expired do indeed correctly show as 'Expired'.
  
  username_0
  
  
  ---
  
  ### Answer by username_1 on 2016-03-04. Score: 0
  
  The scheduled job calls the function `CRM_Member_BAO_Membership::updateAllMembershipStatus()` . This starts by getting all memberships that have types that are enabled, and don't have is\_test set. For each:
  
  * it then checks whether the contact is deceased (this seems to dominate over other rules)
  * it skips inherited (non-primary) memberships
  * it skips status overrides, and the specific statuses Pending, Cancelled and Expired
  * it calculates the new status, and if that has changed, saves it.
  
  (Edit: My first answer confused is\_active with is\_current\_member. But it stands that it excludes expired memberships further down.)
  
  > **Comments:**
  > **username_2**: So username_0, this means you should check if the contact is deceased, if its memberships are inherited from a group or a relationship, and if the membership is being overridden.  
  > **username_1**: He's talking about setting Expired back to Grace- I think the scheduled job ignoring Expired is deliberate.  
  > **username_0**: The scheduled task update should produce the same result as a manual re-save of the Membership, surely, except in the case where it cannot find a valid status and leaves the current status untouched. It should definitely recalculate if the current status is Expired; otherwise you can't use the rules to extend the Grace period.  
  > **username_0**: Workaround: - disable status Expired; - run the update task; - enable status Expired; - run the update task. Result!  
  > **username_3**: username_0 - worth adding that as an answer.  
  
  ---
  
  ### Answer by username_2 on 2016-03-04. Score: 0
  
  Incidentally I know that there were a lot of bugs in 4.4 with regard to memberships not being transferred along relationships successfully. Have you looked at issues.civicrm.org?
  
  **Recommended solution:** I would recommend updating to 4.4.18. You'll get so many bug fixes, and this may be one of them (I haven't checked). You'll also get important security fixes.
  
  
  ---
  
  