Don´t agree.
There is a thing not functioning as expected:

You cannot subscribe backend created users to plans avaiable only for registration.

Also, if you make a choice on registration, and you failed, you cannot get back end redo your choice. (see my explaination earlier.)

This is because there is something wrong with the concept of "only on registration".

The concept should be: "with no other plans active", so in essence the registered no access member.

Of course, previous expired plans could be there.

If the programming is done properly, which I assume and up till now can only confirm, all the other functionality is there to prevent these kind of cutomers to reuse plans intended for one time use.

So my suggestion for a future upgrade would be to change the plans visible for selection, based on "no plans active", other then "I´m registering right now".

Please let me know if you share this view, or need more information or discussion to get things clear. If you don´t agree, thats fine as well, since then we knwo Why you don´t agree.

Thanx a lot in advance.

OK, understand your concerns about the special moment of registration. But in a pure workflow CBSUBS aproach, registration as such is not a special state within CBsubs itself.

That is why I tried to explain the difference in the concept "on registration" and "no plans".

However, there could be a desired fundamental difference between "no current plans" and "no plans ever". As far as I'm concerned, I cannot think of any usecase in which you would like to:
1 have the possibility to set the use number of a plan to 1
2 ànd have the possibility to check for no plans ever.

It would only make sense in a multiple plan setup where you want users to be inable to EVER change to another plan offered at first registration.

This is something you can never avoid anyway, because they will simply register under a new account, where theyhave the first time choice again.

So I stick to my analysis the check "on registration" should only be on the "absence of any current plans".

Right, missed that one in my analysis. So, in order to be clear about the result of this discussion:

There is a "bug" in the sense that when creating a backend user, you cannot assign him to a plan when you have no plans available for "upgrade", and just for "registration".

This could be fixed by adding a plan option, different from "registration", allowing to assign a plan only when there are no other plans active, say "no other plans active".

This would also fix the scenario in wich a user is allowed to subscribe to a choice of plans only on subscription, and you want them to be able to choose another plan from that group after his first choice is expired or cancelled.

So this is as far as I'm concerned the direction for the bugfix as well as the scenario problem.

Thanx for infoming me when and if it's going to be fixed, also if there's going to be another solution:)