CB Subs Importer Breaking

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?

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).

When a user registers they're given the default Registration usergroup as configured in Joomla. On J1.5 this gets replaced if you set a new usergroup in your CBSubs plans. However, on J1.7 it simply adds the usergroup instead of replaces it. This is working as designed. We've plans to expand the usage further for J1.7 however.

What triggers CB Subs to prevent them from logging in and give them the renewal/upgrade screen?

You need to ensure from CBSubs > Settings > Global you don't allow free registrations. This would force a user to have an active subscription of some kind or their account gets "Blocked". I don't know exactly how this would behave with the subscription first being imported however. You can experience this type of setup on our CBSubs demo site though. I believe you also need at least 1 parent plan set to Exclusive.

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

(we were importing several thousands of users).

You should never do such large imports. Image going through the purchase and assignment process of a subscription 1,000 times all at once. It'd kill your server. You need to break your imports up into chucks of say 200-300 users per import. Import is subject to PHP memory limits and PHP timeout limit just as much as anything else.

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

For others trying to import do not add subscriptions via database. It fires none of the triggers and performs none of the security checks. It's not a proper way to add a subscription. For example if your plans utilize CBSubs SQL Actions and you add a subscription via database then SQL Actions will not execute.

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).