Why does this happen? I have several products configured as lifetime. When added to a user, they are scheduled for 1 day expiration. (start and end dates the same) I hope this is a simple fix. Before going live, I must set up MANY existing users, each of which have multiple lifetime downloads. Having to manually configure end dates for each and every one of these is far beyond my expectation of aMember (and my patience). Does this require the hourly cron job for correct operation?
I originally thought that if I ignored the dates on the "Add New Payment/Subscription" section, the script would use the expected default. Alas, not so. Which is why the "one day subscription" referred to in my initial post. These dates must be manually configured on manual entries. The bigger problem is the super-weirdo aMember database design. With a properly normalized database, there would be a separate table that links products to members. It would then be simple to export my existing customer base (which IS normalized) into a form that would easily import into the aMember MySql database. Instead, I must rely on the provided import mechanism, which makes provision for only one product per imported member. It turned out to be not terribly difficult to export the existing customer database with one product each, which were imported just fine. But that still leaves the task of manually entering the additional products many customers have. The manual procedure for adding these requires selecting a customer, then clicking the "User Payments/Subscriptions" link. Next, a product must be manually selected from the product droplist. At this point, although the selected product is defined as "lifetime subscription" in the database, the Period entries in the next column are defaulted to the current date for both start and end date. Hasn't it occurred to anyone that the script could automatically set the default period to the one defined in the database? Doh. but no, the script requires pulling down at least the ending year and setting it to a high number in order to make a manually entered "lifetime" product license last more than one day. Finally, click Add. Then repeat several hundred times. Then correct the inevitable human entry errors. Summary: The necessity of manually entering multiple products per customer is poor design. And the requirement to manually configure dates is also poor design.
Hi, This should work for lifetime subscriptions as well. I just tested on my local installation , when I add subscription to lifetime product manually, expiration date is set to lifetime automatically. amember_payments is the table that links members and products. If you can provide your current database example I will help with script that will import records automatically.
I am experiencing the same issue. No matter what I try when importing a user CSV with subscription info, the result is users all set to pending with no subscription data attached. I have tried 3 times with no success so I began to manually subscribe all my members. Several of my products are lifetime products and I am prompted to enter a begin AND end date. I am not getting the automatic lifetime setting as indicated by Alexander above. There must be a better way to do this than setting memberships for some date 20 yrs in the future. Also there must be a way to import subscriptions instead of having to manually add every member. I have thousands of members and this task is rather daunting.
Please contact me in helpdesk, specify what aMember version you have exactly and attach example of import file that you try to use.