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' and 'Update membership status automatically' and even the very old 'Membership status not updating from pending' 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! David

  • Thanks, JohnFF, but iIn this case all memberships are Individual and there are no relevant Relationships. Mar 4, 2016 at 16:19

3 Answers 3


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'.



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.


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.)

  • 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.
    – JohnFF
    Mar 4, 2016 at 22:42
  • He's talking about setting Expired back to Grace- I think the scheduled job ignoring Expired is deliberate.
    – DaveFF
    Mar 4, 2016 at 22:44
  • 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. Mar 5, 2016 at 7:44
  • 1
    Workaround: - disable status Expired; - run the update task; - enable status Expired; - run the update task. Result! Mar 5, 2016 at 7:46
  • David - worth adding that as an answer.
    – petednz - fuzion
    Mar 6, 2016 at 19:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.