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.



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.

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.