Hey Beat,

The object was moscomprofilerUser and the field names that were being asked for were firstname, lastname, and username. I wasn't asking for them, the importer was, and it was dying with a fatal error because moscomprofilerUser doesn't have a get() method.

We have many thousands users and so I'm using this format:

This text file is multiple lines (one line per user) comma-separated list with following format: userid,planid,statusSingleChar,SubscriptionDateISO.
Status: A = Active, X = Expired, C= Unsubscribed/Cancelled.
Example: 63,1,A,2009-01-01 00:00:00

Everything entered is correct. I'm literally taking the example line and replacing it with a valid user, a valid plan, and a time period within the plan's length (1 year subscription starting 2011-01-01 00:00:00) and the subscription is imported and immediately expired. The importer says Success and that the plan is active, but a check of the database reveals that it was expired. There are no other subscriptions -at all- the _cbsubs_subscriptions table is empty and only this one line is being imported.

The only way to keep the subscription from expiring is to put the starting date some time in the future.

Originally, I wrote a db import script that I just plugged directly into the _cbsubs_subscriptions table however users that were expired did not have their groups re-assigned when they renewed their subscription.

Any idea what would cause this?

Thanks for your comments. I've had in my head that the plan length is for a year, however for testing we recently shortened all the plans to 5 minutes. I've looked at them so many times that it didn't click that this might cause the importer to expire them, which it should, and did. Once I updated the length to a year, my test plan imported fine.

On that topic, I believe that you said in another post that you guys could implement more flexible plan durations and that you had planned them for a future release. This is really important to us because right now we're relying upon grace periods to get plans out of the defined time sets (we're migrating from AEC and had durations like 1 year 2 weeks). The drawback is that we can't use the expiration event to fire off emails, other cb actions, etc. Kyle has already answered that he wasn't sure whether this was planned for the next release of CB Subs. I bring it up now because you might know and because it would be great to test plans at less than 5 minutes (5 minute wait to see if settings had desired effect).

I appreciate your help in this and am sorry to say that I've ran into the same problem I was having with my own importer. The situation is this: I'm migrating many users over from a previous installation and having problems with expired plans.

If I put the users in their correct groups (associated with their plans), and their plan is expired, they receive access to the site without having to renew their subscription (CB Subs does nothing). If I remove them from the user group associated with their plan and just keep them as Registered, CB Subs will renew them into the correct plan, but will not re-assign them to the group associated with the plan. Catch-22.

My hypothesis is that users should be assigned to a group, but that there is a field in one of the tables that must be switched and will cause CB Subs to prevent users from logging in and instead having to choose a plan. Is this correct? If so, what field? If not, why aren't registered users being re-assigned to their correct group on renewal?