2

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

Improve this question
6
  • 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.
    – Parvez Saleh
    Dec 1, 2020 at 1:48
  • Thanks for the suggestion Parvez. I tried adding an end adjustment to the Old status, but it has no effect unfortunately.
    – The Amateur
    Dec 1, 2020 at 16:32
  • 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!
    – Parvez Saleh
    Dec 1, 2020 at 17:11
  • 1
    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
    – petednz - fuzion ♦
    Dec 1, 2020 at 18:24
  • Thanks Parvez and petednz. That would explain things. I will give the suggestion to adjust the order a try. Cheers.
    – The Amateur
    Dec 1, 2020 at 22:12

2 Answers 2

Reset to default
2

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 "Expired" status is achieved, it no longer gets changed.

Improve this answer
1
  • 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.
    – petednz - fuzion ♦
    Dec 2, 2020 at 18:47
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 @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 "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.

Improve this answer
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
    – petednz - fuzion ♦
    Feb 25, 2021 at 18:17
  • Pete - thanks for mentioning this - I've updated it for clarity
    – Rick Cunningham
    May 4, 2021 at 20:42

Your Answer

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

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