Hey Beat,

I am using CB 1.7.1

Right now, CB subscribes all users into two groups Registered and whatever the group was for that plan (which as I understand it is its default behavior, we're not telling it to assign anyone to Registered).

All groups are the same for parent and children plans (both are set to the same user group).

What exactly prevents someone from logging in and offers them a relevant renewal/upgrade scenario? For example, I have a user who has an expired record in the CB Subs subscription table and are still in the user group associated with their plan (after import as I've described.) If I try and login with them, CB Subs does nothing, and they login and no longer have to have a subscription. What triggers CB Subs to prevent them from logging in and give them the renewal/upgrade screen?

Anybody?

Thanks for your help Kyle. I had to abandon using the importer. It was taking up too much systems resources to run and would break on some of our imports. When it did this we had to reset everything and start over because of the changes it made (we were importing several thousands of users).

What I needed to know was how CB Subs prevents someone from logging in and prompts them for an upgrade. The answer is that it sets a flag, '1', in the jos_users table for the `block` field. This was the field that I was looking for earlier.

The results of my tests in trying to figure this out were muddled because sometimes Joomla's core user form would be presented when trying to login a user (instead of the CB login). This, a lack of ability to see the source, lack of information about how cb presents renew options, and trying to use the importer, wasted around 50 hours of work.

For someone else trying to migrate users over:

1) Put them in the plan's user groups
2) Assign them subscriptions in the cb subs subscription table
3) Mark them as blocked in the jos_users table if their subscription(s) has expired

Kyle, to be clear we're doing a full on migration. Doing blocks of a 1000 users at a time was taking hours- imagine what doing blocks of 200 users is like and the margin for user error. In addition, as I mentioned, if the importer runs into any trouble or times out, the process has to start from the top. The results also needed to be testable and repeatable on command (make changes and check end result across variety of user types) And we are syncing from a database that is continuing to grow and the process needs to be as automated as possible.

I do understand what you are saying with CB Subs needing to do it's own checks, and in fact that is why we attempted to use the importer in the first place. It was just too much overhead though and somewhat unpredictable in its results (costing a massive investment in time trying to get it working). We're not relying on an extensive cb sub plugin architecture and we've tested the results across a variety of user scenarios (again: automated, repeatable tests).