Renewals when previous_status = I or X not getting user access added

We have several subscription plans set up.
All of the plans assign a user group to the user when they purchase the subscription.
(via ACCESS | Subscribers User access level settings | User Group).

The assignment is happening fine for all new subscribers and for most renewals; however we were having a few each week that were getting the subscription renewed OK (the new subscription is showing in the CB user panel); however, the user group is not being assigned.

After tracking much of the data related to these 'problem' accounts for a couple weeks, about the only thing that I can determine common between them is that on the change notice the 'previous_status' was either "I" or "X" (mostly "I").

Most of these subscription records were also manually migrated over from a previous installation of AkeebaSubs, and these items also had a rather old last_renewed_date as well as having previous_expiry_date that is usually 0000-00-00.

Most of the renewals are happening before the current expire date.


Any ideas what might be causing this?

Would it be best if I just change the previous_status of all of these to some other setting? Or change the previous_expiry_date to some valid date?

How did you migrate those subscriptions? Directly insert into the database or did you use CBSubs Import? It sounds like you may have directly inserted into the database making the subscription rows basically incomplete. Their next renewal should be ok since the last renewal should've corrected any missing data. Best I can suggest is compare a database row from a subscription that works to one that doesn't and see what's missing exactly. Alternatively you can use CB Auto Actions for more control over usergroup assignment using the below usage.

Plan Active
Global
Triggers: onCPayUserStateChange
User: Automatic
Access: Everybody
Conditions
1: [var3] Equal To PLAN_ID_HERE
2: [var2] Equal To A

Plan Expired
Global
Triggers: onCPayUserStateChange
User: Automatic
Access: Everybody
Conditions
1: [var3] Equal To PLAN_ID_HERE
2: [var2] Not Equal To A

Yes, we did that with a manual migration of data directly to the DB.

I like using the autoactions approach (as we already use autoactions for lots of things).

Thanks!