mohsho wrote: Is it possible for admins to see a users subscription history? I've just imported all of my subscriptions from aMember. I've attached a screenshot showing what I'm looking for. Also, I think that each user should be able to view their full subscription history as well.

I see in the forums that we should be able to see all past invoices for each user, but I guess that the import function doesn't generate an invoice?

If this is not possible, what files should I be looking in if I wanted to add this functionality?

Please advise.

Thank you.

You can filter both Subscription icon area and Payment icon area by username.

But this is no way to import past invoices or payment from other systems.

1. I tried to import multiple subscriptions for many of our members, but I ended up with pretty much just 1 line per member in the _cbsubs_subscriptions table. The exception was when a member had more than one subscription type. Is it only possible to keep track of the latest subscription information?

Don't understand the question. You are wanting the same history for a subscription multiple times? Like the history of its renewals? That's in CBSubs > Payments as it's their payment history for a subscription. CBSubs doesn't create a new subscription on renewal for example; it just renews the existing subscription.

2. I was also planning to do the import via mysql insert statements, but I read in the forums somewhere (can't find where...) that I shouldn't because the import script also inserts into other tables (baskets & payments?). However, once I did the import, I couldn't find any entries in any other tables having to do with payments or baskets?

Do not tamper with the database. If you need to import use CBSubs > Import. Giving a user a subscription from backend does not create a payment as no payment was made nor was a basket used.

3. I would REALLY like to have the historical membership data available in cbsubs. How can I find out what's involved in inserting all of my payment data directly into the _cbsubs_payment(s) tables?

You don't, do not tamper with the database. You are on your own in this regard. We are strictly against this as you can end up completely messing up internal calculations. Payments are generated for frontend purchases only. They serve no purpose for backend subscriptions as there is no payment workflows in backend; it has no idea what gateway should be used or anything of the sort so there's no totalizers, no payment items, etc..

Set their registration date as the date you have in aMember.

Aside from that you can make a dummy purchase on frontend then review your database tables afterwards and use what it inserted as a basis to insert your own custom entries; that at least would give you a complete insert if you insist on altering the database. You'll want to review _cbsubs_payments, _cbsubs_payment_baskets, _cbsubs_payment_items, _cbsubs_payment_totalizers after the dummy purchase.