Callum MacGregor

I stand corrected, thank you @Daniel F

I hate to tell you, but I downloaded 4.7.19 before I made these posts to be double sure, and the issue is still present. if ( !$this->_checkCondition( $maxMind->riskScore !== NULL ? $maxMind->riskScore : round( $maxMind->score * 10 ), $this->maxmind, $this->maxmind_unit ) ) This is still incorrect, the api result returns risk_score, not riskScore. I literally told you which file, which line, and what exactly to change and yet you still get it wrong?

So basically, this:

Laughable that you gave me a warning for "abusive behaviour" @Marc What is abusive behaviour is the way you treat paying customers, but god forbid we have an opinion on that.

Well here we are another 3.5 months later and its still not fixed. What the actual faeces are you guys doing over there?

No, I guess you can consider this issue dealt with. I'll check back in another year to see if it has been fixed.

Does it require a lot of resources to change one line of code?

I mean I am glad to see your list of updates....but how are you prioritising bugs? Its a one line fix, I even told you the file to change, and its something that has a direct financial impact on anybody using maxmind in two ways: Anybody paying for maxmind for the last year has been completely wasting their money as the Invision integration is broken Anybody relying on maxmind for fraud prevention will almost certainly have seen an uptick in fraudulent payments, which almost certainly ends up in a chargeback and a fee incurred. To the end user, everything works as expected, maxmind gives no errors and looks like its working as intended, but its only when you dig into it you see the fraud score isn't being used at all. Are you going to be reimbursing customers for this financial loss, considering you have been aware of the bug for a year and have done nothing about it? Maxmind is a core component of Invision, not a third-party addon, and it is STILL BROKEN after almost a year.

So its nearly a full year since I reported this and it still hasn't been fixed @Marc. V5 hasn't even been released yet and V4 has already been forgotten about?

To be clear, it is not just one user. It is a large and increasing number of users. With one user I checked their browser plugins and they didn't have anything that should affect it. Also, this same user fixed it by using a Edge rather than Chrome. This leads me to believe its a HTML/Javascript/browser compatability issue, but I am of course speculating. I can try and find a user willing to help test and see what happens after disabling plugins/apps.

Hello, yes I updated to 4.7.16 and cleared all caches, the problem persisted. I can't very easily disable all applications as that will cause service disruption. But if it was a plugin/application surely it would affect all users, not just _some_ ?

Hello, I am not sure exactly when the issue started, but we are seeing an increasing number of users unable to login. This happens after a purhcase is made, at which point 2fa is required by the user. Upon trying to login, the user gets kicked backed to https://<domain>/?_mfaLogin=1 but no 2fa popup appears and the user cannot log in. I know this is definitely a problem with users on Chrome, unsure about other browsers. The issue has steadily been increasing for the last few months now and is causing a serious problem. Any help appreciated, thanks.

It is a standard product with renewals.

I've encountered a bug in the commerce application whereby a user can generate a renewal invoice for their current active product, then change their renewal term after generating the invoice. Upon paying the invoice the amount paid is that of the original renewal, but the renewal term is whatever the user changed it to. So for example. Let's say I generate my renewal incvoice for 1 day at £1. Before paying it, I can change my renewal term to 30 days for £30. I then pay the invoice for £1 but the renewal term given to me is 30 days. I therefore got £29 worth of product for free. This also works inversely.

Thank you for the clarification.

Yeah, until they scrap pages too 😄

I got it working now. Thanks @Adriano Faria for offering to help. I had to create a dummy extension in admincp, then the extensions.json was created correctly. This is exactly why I am so reluctant to upgrade Invision to newer versions.

I don't have an extensions.json file, its an old application. I'll try and create it myself.

Its my own application. For a bit more information, in the admincp the extension does show up as expected: However, I logged what ItemsIterator collects from \IPS\Application::allExtensions call, and my extension is no longer listed there:

I have an application that creates a custom commerce package, extending \IPS\nexus\Invoice\Item\Charge. Up until the latest update it worked fine, but since the latest update the ItemsIterator expects all extensions to be in the 'nexus' application, and therefore cannot load the class of my package object. How it works now, I don't think its possible any more to create custom chargable items, but I desperately need this functionality.

You're right, its working as intended. I would say that opting to store billing details wouldn't necessarily count as giving consent for continuous billing; but that's a separate issue. But back to the main topic: please could I officially request the ability to disable automatic billing for account credit? Or if its not possible to do it on a granular level, to disable automatic billing entirely for all payment methods.

There is no such setting for account credit, so payment is taken for users automatically who have enough account credit to cover it. EDIT: Sorry I forgot to clearly clarify in the original post that this affected account credit only.

In the automated task generateRenewalInvoices.php, Commerce will try to automatically take payment when a renewal invoice is generated (and a billing address is stored). While I don't think this is wrong necessarily, its not behaviour I desire, and my customers definitely do not want this. The offending line of code is: /* Try to take payment automatically, but *only* if we have a billing address (i.e. the customer has a primary billing address set) otherwise we don't know how we're taxing this and the customer will need to manually come and pay it - we can skip this if tax has not been configured */ if ( $invoice->billaddress OR \count( $availableTaxes ) === 0 ) I would request to have an option to disable this, as right now I have to comment this code out manually to prevent my users from being charged automatically (even if it is to account credit). Kind Regards.

Thanks for reporting it as a bug. I'll await the fix as it does appear to still be an issue even in the latest update.

User ID: 105995 The user is banned now, for obvious reasons, but wasn't at the time. EDIT: I actually think I might know why. Maybe Maxmind changed their API results format, because in the code within Rule.php, the expected syntax is 'riskScore'. But in the maxmind API response, its 'risk_score'. Rule.php: /* Score */ if ( $this->maxmind ) { if ( !$this->_checkCondition( $maxMind->riskScore !== NULL ? $maxMind->riskScore : round( $maxMind->score * 10 ), $this->maxmind, $this->maxmind_unit ) ) { return FALSE; } } Maxmind API response for this particular transaction (redacted): risk_score : 99