[SOLVED] How to track down subscription set to expired by 'System'

It looks like they just expired normally. System is used when a specific user didn't make the change. In this case it's just expirations being triggered. The IP Address is likely that of the server that performed the CRON operation if you're using CRON to trigger expirations. Could also be a expiration triggered by the payment gateway, but you should have a notification for that.

Ahhh ... that makes sense now.

I had 'Mass expire subscriptions method' set to 'Front-end (10 max/page) and admin accesses (100 max/page) (cbpaidsubsbot)'

So I'm guessing that the non-US IP address was just the address that hit the front-end and triggered that mass expire.

[I'm changing that to cron job now. Not sure why it wasn't set that way before.]

Hower, I'm still perplexed why the Subscription record shows:

- Last renewal date: 9/13/2017
- Expiration date: 9/8/2018

yet the status was set to expired on 8/2/2018 - more than a month before the listed Expiration date of 9/8/2018.

We are not using recurring billing for subscriptions, so I'm not sure why a payment gateway would cancel a subscription early. (And we don't have any notifications on-or-about that date for this user.

Any other ideas?

Also, we have checked with Authorize.net and there was no 'transaction' or other 'activity' on or about that date related to this subscription/user.

So I'm guessing that the non-US IP address was just the address that hit the front-end and triggered that mass expire.

Yup.

yet the status was set to expired on 8/2/2018 - more than a month before the listed Expiration date of 9/8/2018.

Are you sure that was the stored expiration date? The displayed expiration date will include the grace period if you have one configured, but they shouldn't have expired yet if they were within the grace period.

I don't have anything to suggest beyond maybe you had the date wrong or were looking at the wrong date? What's the duration of the plan and when exactly did they subscribe?

Subscription data:
- Subscription date: 08/26/2012
- Last renewal date: 09/13/2017
- Expiration date: 09/08/2018
- Status: Expired
- Autorenew Type: Not autorecurring
- Payment basket id: 346
- ID: 605
NOTE: These dates match the raw data in the #__cbsubs_subscriptions table

Subscription change log - last entry data:
- Event time: 08/02/2018
- Change log: User subscription deactivated with status Expired
- Change data:
- previous_expiry_date: 2017-09-09 21:16:16 > 2018-08-02 15:12:00
- previous_status: X > A
- status: A > X
- Username: System
- ID: 58441

Payment Basket Data:
- Gateway account: Credit/Debit Card
- Status: Completed
- Initiated on: 09/13/2017
- Completed on: 9/13/2017
- Id: 346

Plan details:
- Regular Validity duration: 1 year
- Renewable in advance by: 1 year
- Grace period before real expiration: none
- Manual renewal extends expiration date as follows: Renewal stars at expiration date or at payment date - whichever happens last (allows free gap)


So, based on all this, it sure looks like the change that happened on 08/02/2018 was not proper - or has no real reason behind that action. All previous dates related to this subscription were well after that date (anywhere from 8/26 - 9/13).

My client is very concerned at how subscriptions can just get changed by the system without any reason. And I'm concerned also that there is at least no complete log entry to explain the problem.

We've had other 'random' oddities like this in the past couple years with how CBSubs works, but this is really concerning that we can't identify why a subscription expire got changed, and thus, can't necessarily rely on the system to work as it should.

I guess we can just consider this a 'random oddity'; however,if this happens again that won't be an option the next time.

Please PM backend super administrator login credentials and will take a look. Please include in the PM the username of the user this is affecting.