Changing user group on change of Plan

Joomla! 3.9.18
CB 2.4.5+build.2020.05.07.21.35.06.e8f8a6125 (latest version)
CB Auto Actions 8.0.0+build.2020.04.17.17.38.41.bcf774668 (latest version)
CBSubs 4.4.0


Simplifying things, we have two types of membership subscription – Full Membership Plan and Restricted Membership Plan. Both Plans are exclusive and are parented to Top.

We also have two user groups – Full Access and Restricted Access. Both user groups are parented to Registered.

All members initially subscribe to the Full Membership Plan and are put automatically into the Full Access user group, which is the User Group specified in the Plan’s Access tab.

For the Restricted Membership Plan the User Group specified in the Plan’s Access tab is Restricted Access.

When the Full Membership expires we sometimes want to move the member to the Restricted Membership Plan. Note that this is always done after expiry, and always in the back end.

Instead of reactivating the Full Membership we ‘upgrade’ to the Restricted Membership. So far, so good. However:
• not only is the member placed into the Restricted Access user group but the original Full Access user group remains unchanged.
• The member’s previous expired Full Membership is not shown in the Subscriptions list as having been upgraded (Replaced By Subscription is empty) nor is his current active subscription shown as being an upgrade (Replaces Subscription is empty). This does sort of make sense, as the original subscription period has ended, but it’s a reactivation not a new subscription.
If we reactivate the previous Full Membership and immediately ‘upgrade’ to the Restricted Membership then the Replaces/Replaced By values appear correctly, but the user group is still wrong.

I have tried to set up a CB Auto Action to remove the unwanted user group but it’s not working so I’m obviously doing something wrong. It’s set up as:

Triggers: onCPayUserStateChange
Type: Usergroup
User: Automatic
Access: Everybody
Conditional 1: [var3] Equal To RESTRICTED_MEMBERSHIP_PLAN_ID
Conditional 2: [var2] Equal To A (should that be in quotes?)

Action 1:
Mode: Remove usergroups
Usergroup: Full Access
Action 2:
Mode: Add usergroups
Usergroup: Restricted Access

I need to sort the user group problem out since if the member reverts to a Full Membership the allocation to the Restricted Access user group remains set.

The usergroup change isn't working because the save of the backend user is overriding it. You need to manually change their usergroup if you're going to do this from backend to prevent double save issues. Note you can do this from frontend by going through the upgrade process on their behalf, use an offline payment gateway (could be restricted to just moderators), then pay the basket in backend. This would simulate a normal upgrade process, which backend user edit is not. Backend user edit directly acts on subscription objects so it can't be equated to a normal frontend process.

I had a sneaking suspicion that might be the case, as I am aware that at least some triggers are front-end only, so thank you for confirming it.

It's not very easy to find a list of all the triggers for CB Auto Actions and their associated variables (I've been looking for a long time and just happened to stumble on it while working on this problem), and even then I can't tell which work only in the front-end (or indeed, only in the back-end if such is the case).

CB Auto Actions is brilliant, but it does take some understanding!

Many thanks for your always helpful and quick response.

It's not very easy to find a list of all the triggers for CB Auto Actions and their associated variables (I've been looking for a long time and just happened to stumble on it while working on this problem), and even then I can't tell which work only in the front-end (or indeed, only in the back-end if such is the case).

Currently we only have the below documentation regarding triggers.

www.joomlapolis.com/documentation/279-community-builder/tutorials/18358-using-cb-triggers

While it does list the triggers and their variables some of the variable names are admittedly vague. There's not really a better way for us to document this at this time. We plan to redo our triggers API and implement an official inline documentation for those triggers where we can provide more information that can be used in generating some form of documentation, but for now the easiest approach is to just ask if there's a trigger available for X or to do Y.

Thank you for taking the time to send me the link, the contents of which I've stored for future reference.