Issue with expired plans not correctly changing user group membership (??)

The plan usergroup assignment under the Access tab adds that usergroup if they don't have it on plan activation and on plan deactivation should take it away. A plan can only control 1 usergroup at a time. For example if Plan A gives Group A and Plan B gives Group B and they upgrade from Plan A to Plan B they will lose Group A in favor of Group B since Plan A just deactivated.

CBSubs will not touch a usergroup it is not configured to assign. So if Registered is the new usergroup for new registrations as per User > Options configuration and no plan is configured to assign Registered they should always have Registered usergroup.

If you need finer controls of usergroup assignment you will need to use CB Auto Actions with the below in a Usergroup action.

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

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

Replace PLAN_ID_HERE with the ID of the plan you want this to act on.

Actually, the default usergroup configuration:
( 'registered' on registration - this group stays always)
( add 'Free' on free account subscription - remove Free on expiry or on upgrade to Paid)
( add 'Paid' on Paid account subscription - remove paid on expiry)

is exactly what we need, and for the most part, it works.

But at various times in the past, it's evident that 'removing' Free on upgrade has NOT happened, and also 'removing' Paid on expiry has NOT happened.

Do you have a handy account assignment clean-up script that I can adapt to removing Paid usergroups from ('expired Paid subscriptions') users that are stuck with them?

Do any recent subscriptions have this issue? It's possible older subscriptions could be subject to a bug long fixed as there were issues with usergroup assignment in the past. As for clean-up you could use the batch tools in CB > User Management to mass change usergroups for selected users.

It SEEMS that the system is silently applying a three day grace period?? :blink:

As of today I currently have about 40 users whose subscription expired 07-feb-2020 or later, all of which are still holding the "Paid" group membership.

It seems that members whose subscription expired 06-Feb-2020 or earlier are all correctly removed from the "Paid" group ... ( still checking...)

Yes, confirmed that going back several days, all the expired Paid subscribers are being correctly reverted to "registered" group membership only. ( which is important for us - as they will get reminded to renew their paid membership whenever they log in...).

But this three day 'grace period' should not be happening... bug?? (We have 0 set for grace period in the plan settings...)

hmmm.. I think I found it:

Automation settings
Mass expiry settings
Mass expire subscriptions method

Maximum subscriptions to expire per cron task run.

this was set to admin only (without a cron task)... Is this a new setting?

--- but ( weird) - I got this error when I manually ran the suggested URL:

Invalid mass-expiry link: link is in global CBSubs settings.

Yet, after running it, it did immediately clear off those 40 users - they are all ( properly) set to just "registered" group now ( their "Paid" group memberships removed...)

So, what's up with that? We do have cbpaidsubsbot running ( just default setting there)

I'm thinking I'd like to set the Mass-expiry selection as shown:


And just run the cron daily... kinda weird to get the 'invalid mass-expiry link' message though... can you please clarify that??

CBSubs Settings need to be saved after changing that parameter. It generates a key for the URL and stores it for verification. Once settings have been saved the URL should work fine as long as "Mass expire subscriptions method" is set to allow CRON. In your case I recommend setting it to "Cron task and admin access (100 max/page) " and setting up a wget CRON task to run daily on "Url of cron task" URL.