We are finding that people are subscribing to our Annual Membership plan but the group change associated with the plan doesn't happen any more. We are having to do them manually.

Are you giving them usergroups using the "User Group" parameter under the Access tab or using CB Auto Actions?

Also, one of our upgrade plans which has always been visible to administrators in the back-end is no longer visible.

Do you have any conditions on the plan that could be blocking access? When I reviewed your install for your recurring payments issue you had some strange conditions on your plans where it was requiring the plans self to be registered or unpaid, but that was only for the recurring plan. A plan can't condition itself for upgrade.

These two problems may be related and also seem to date from the last general CB upgrade we carried out a few days ago.

It's possible you were using something in a way that was actually just a bug and the bug was then fixed. If the configuration doesn't make sense then it's often just a bug if it somehow works. For example if Plan A conditions for upgrade to have Plan A as active or unpaid it's an invalid condition; it may work for one reason or another, but it shouldn't.

We are using the "User Group" parameter under the Access tab.

Are all plans doing this or just the Annual Membership plan? Does it fail to give their usergroup in frontend only, backend only, or both? Note when subscribing from backend the user save may override usergroup changes made by the plan so you should change their usergroup during profile edit where you'd be selecting a subscription to give them.

I don't think we have any strange conditions set. The plan which has vanished is the Low Income confirmed.

I take your point that maybe we were maybe relying on a bug, but I'm not sure where. I've restored your permissions if you would like to have a look again.

Looks like you've the following condition on the plans upgrade check.

Any of the following plans subscriptions: PLANS_SELF and OTHER_PLAN
Must be in state: Active
Or can be purchased same time: No: those plan(s) must already be existing

So a user can only upgrade to the plan if they're already actively subscribed to OTHER_PLAN having PLANS_SELF selected does nothing here.

The usergroup change doesn't take affect unless the user has become completely active. So if they're pending payment for example the usergroup change won't happen yet. It sounds like either that's the case or something else is performing a user store after CBSubs causing the usergroup change to revert. I'm not seeing any usergroup assignment issues across 3 test installs so it's likely a conflict of some kind existing on your install. Are you using CB Auto Actions to modify users fields, etc.. after a subscription becomes active for example?