Leaderboard

This is the reason the cron task is stalled: Error: Undefined property: stdClass::$precision #0 /home/*******/domains/billing.*******.co.nz/public_html/app/models/invoices.php(1255): UnknownException::setErrorHandler(8, 'Undefined prope...', '/home/*******/d...', 1255, Array) In v3.5.1, currencies were updated to include precision. The only reason you would not have currency precision when using Blesta v3.5.1+ is if the upgrade was not run. After you upload all of the files for a newer version of Blesta, you must make sure you run ~/admin/upgrade/ in your browser and follow the steps to upgrade (basically just click a button). After you run the upgrade, head over to [settings] -> [Currencies] -> [Active Currencies]. All currencies should have a precision set (i.e. number of digits after the decimal place). You may need to update NZD (and other currencies) to their expected currency precision.

Glad that fixed your issue, as it's not a bug I'm closing the thread.

@Paul the invoices were for the same service but i think it could have been something i done while trying to resolve the issue. @Tyson thanks looks like it is precision issue, just seen issue with currencies. Awesome you guys rock thanks for your time.

Did you complete the upgrade process by running /admin/upgrade? If the tasks are not completing, they may be encountering an error. If the database hasn't been upgraded, there could be errors related to a query which hangs the task.

^thank you!

<div class="col-md-4 col-sm-6 portal-box"> <a href="{client_url}login/"> <div class="well"> <i class="fa fa-cogs fa-4x"></i> <h4>My Account</h4> <p>Log in here to manage your account.</p> </div> </a> </div> <div class="col-md-4 col-sm-6 portal-box"> <a href="{client_url}plugin/support_manager/client_tickets/add/"> <div class="well"> <i class="fa fa-ticket fa-4x"></i> <h4>Support</h4> <p>You can open a trouble ticket here.</p> </div> </a> </div> <div class="col-md-4 col-sm-6 portal-box"> <a href="{client_url}plugin/support_manager/knowledgebase/"> <div class="well"> <i class="fa fa-info fa-4x"></i> <h4>Knowledge Base</h4> <p>Search the knowledge base for an answer.</p> </div> </a> </div> <div class="col-md-4 col-sm-6 portal-box"> <a href="{blesta_url}order/"> <div class="well"> <i class="fa fa-shopping-cart fa-4x"></i> <h4>Order</h4> <p>Visit the order form to purchase new products.</p> </div> </a> </div> <div class="col-md-4 col-sm-6 portal-box"> <a href="{client_url}plugin/download_manager/"> <div class="well"> <i class="fa fa-download fa-4x"></i> <h4>Download</h4> <p>You can access the downloads here.</p> </div> </a> </div>

Gateway properties need to be set. This includes a "meta" property. So you should set the meta data to the gateway from wherever you instantiate the gateway. Look at /components/gateway_payments/gateway_payments.php for an example in initGateway.

They never really versioned things properly which is why they were stuck on 11 for so long. They introduced numerous backwards incompatible changes and kept incrementing the minor release only. In a sense, their new versioning scheme just removes the redundancy and allows them to continue as they were. The bright side is that yes, it will probably be less confusing for people.

You can check manually but MaxMind / FraudLabsPro stop fraud as-well which are implemented at the moment. FraudRecord is on their to-do list and Blesta are looking at a way to use both MaxMind / FraudLabsPro & FraudRecord giving you double the security than other systems.

11 to 54, wow. I understand their reasoning, but why not 11.54, then 12, 13, 14 if they want to break semver. Interesting re OpenID, though their cPanel login screen is looking pretty confusing with so many options. Probably a much better way to present these options. 2FA is nice, sounds like they plan to implement TOTP. We implemented TOTP for Blesta in 2010. Some of the performance improvements sound really good.

See CORE-1864 I believe you are affected by this. A fix has been implemented for 3.6.1, and I'm including the hotfix here if you'd like to manually resolve it on your system in the interim. In /plugins/billing_overview/models/billing_overview_statistics.php update lines 44 and 45 FROM: $this->Record->innerJoin("transaction_types", "transaction_types.id", "=", "transactions.transaction_type_id", false)-> where("transaction_types.type", "=", "debit"); TO: $this->Record->on("transaction_types.type", "=", "debit")-> leftJoin("transaction_types", "transaction_types.id", "=", "transactions.transaction_type_id", false); In /plugins/billing_overview/models/billing_overview_plugin.php update line 16 FROM: private static $version = "1.3.0"; TO: private static $version = "1.3.1";

As Licensecart mentioned, the Payment Received email template is a receipt of payment, but does not include any invoice(s) as attachments, if any were paid with it, partially or otherwise. The only reason I can think that the amount applied appeared as twice the value you entered is if you had paid it twice. For example, perhaps as you were recording a payment, that invoice was paid via cron from a loose $100 credit, or the client happened to make a payment at the same time for the same amount you were recording. In any case, it's best to look at the Transactions table to see where the payment originated.