Membership statuses 'stuck'

[benmoreassynt]

I have a small group of about 20 members (within a database of hundred of members) whose memberships are 'stuck' in a certain status. Initially they were stuck as 'current' even though the expiration date was past.

Manually editing a membership to change the status via override fails to save the status change, even though CiviCRM claims the change was saved successfully.

Using "Batch update members via profile" I can get the status to change, but that does solve the underlying problem: manual editing still fails, and the membership scheduled job does not work on these memberships.

I am thinking the most likely cause is some sort of foreign key constraint that has got out of whack during a long database import/export/schema issue I had last year.

Any ideas how I can get these memberships to auto-update again, other than simply deleting and re-entering them?

[benmoreassynt]

Apologies for the bump, but this is a bump.

The failure of memberships to update by any method is ongoing, and I really don't know where to start in terms of debugging what the problem is.

Appreciate advice and help, as always.

[benmoreassynt]

Following an update of CiviCRM to the latest version, I am now getting a bit more information about the problem.

When trying to manually set the status of a membership from 'current' to 'grace' from the edit membership screen, I get the following error:

Code: [Select]

Mandatory key(s) missing from params array: one of (activity_name, activity_type_id, activity_label)
Any idea what might be causing this error? I appear to have a growing number of memberships stuck in this status.

I thought it might be manual overrides, which are desigined not to update automatically, however I have established that that is not the issue.

[joanne]

So is it for every membership  that should be changing from current to grace?

Have you checked that everything is properly defined for both current and grace status.

[benmoreassynt]

Hi Joanne, thanks for the reply.

It appears to affect all memberships.

I've checked the membership status rules multiple times (check them again to be sure) and they all look good to me. They're basically the CiviCRM defaults

Current Membership Ends > Grace for 1 month > Expired starts one month after end of membership.

Is there anything else that could stop it working? The error above looks almost like a bad API call or something.

[benmoreassynt]

It's definitely an API call error, and I wonder if it is caused by missing fields in the database. Unfortunately this database has had it's problems over the years.

Possibly the civicrm_option_value table, based on comment on this thread: https://github.com/compucorp/civibooking/issues/47 ?

Attached is the full output of the error log, with names changed to protect the innocent.

[benmoreassynt]

I finally worked out the problem.

A missing entry in the  civicrm_option_value table triggered a fatal error when called from civicrm/CRM/Member/BAO/Membership.php (line 152).

CiviCRM was trying to record the 'activity' when a membership changes status and breaking because of the missing entry.

Solution was to put an entry into the civicrim_option_value table with the following values:

Code: [Select]

INSERT INTO `civicrm_option_value` (`id`, `option_group_id`, `label`, `value`, `name`, `grouping`, `filter`, `is_default`, `weight`, `description`, `is_optgroup`, `is_reserved`, `is_active`, `component_id`, `domain_id`, `visibility_id`) VALUES
(977, 2, 'Change Membership Status', '18', 'Change Membership Status', NULL, 1, NULL, 18, 'Change Membership Status.', 0, 1, 1, 3, NULL, NULL);
The key element being the presence of the 'Change Membership Status' name ... other values may change from database to database, and I have to admit to guessing values for some columns, however if stops the membership update cron, etc, from failing.

[bcobin]

I think I may be seeing the same thing - members being listed as current, when the end date is long past - this is a relatively new site (June 2014) and I'm just noticing this now. This is on 4.4.5.

I haven't tried to fix anything yet - the suggested SQL command looks like it may be specific to that particular installation and, not being a coder, I'd like to verify whether or not I should modify and run the command.

I also don't see this as an identified bug, so I'm assuming an upgrade wouldn't solve the problem. Anyway, I'm really not sure what I should do... any guidance greatly appreciated... thanks!

[Dan C]

Do you have the scheduled job enabled and a Cron job running on your server to trigger it?  And have you run into the same error as the original poster when trying to manually change one of the membership statuses?

[bcobin]

My bad. I was unaware that this (and other things) were handled via scheduled jobs. Once I ran the update membership job manually, the statuses updated properly. I'll set up the cron jobs Monday.

Thanks for the advice and for the prompt response - this is my maiden voyage with CiviMember (which is great) and we live and learn... thanks!

[Dan C]

No problem, that is an easily missed thing and you aren't alone .