Tyson

This issue is a race condition between the creation of a service invoice and the cron running paid pending services. This is assigned CORE-2581 and a work-around is described in that task.

Looks fine. The "/10" might be preceeded with an asterisk, i.e. "*/10", but if the cron is running every 10 minutes currently then it's working as expected. Did you check the cron log in Blesta to see if the autodebit task ran on 1/31 and what its output was?

Both of those look good. I don't see anything obvious that would have caused those invoices to be autodebited the day after unless the cron failed to run that task as expected, or those clients did not have autodebit setup.

What do you think of two new settings?: Invoiced Today (Proforma) Invoiced this Month (Proforma) We'd keep the current "Invoiced Today" and "Invoiced this Month" settings the same as they are now, but add those two new settings that only refer to proforma invoices. Thoughts?

It could be due to the cron (perhaps it failed to run?) or due to the time that the cron is set to run and the time/timezone set in Blesta versus your own. What is the value of the setting Auto Debit Days Before Due Date under Settings > Billing/Payment > Invoice & Charge Options (or under the Client Group settings if you're overriding the setting there)? What time of day does the automation task run for Auto Debit under Settings > Automation? And in what timezone? Is it the same timezone that you're in?

What kind of limitations would exist for this option? For example, can you merge a closed invoice with an open invoice? Having this option may be useful, but it can be very complicated since it affects other parts of the system, e.g.: Services that renew may be tied to the invoice. If merging invoices containing renewable services, the affected invoices must be updated in `service_invoices`. (there may also be other limitations to this) Transactions apply to invoices, so any payment must be updated to unapply from invoices and applied to another Invoices are expected to exist and not be changed (which Blesta doesn't yet entirely support), but some laws in your area may not allow for this behavior, or have additional requirements

I can see a status field being useful. However, if you chose a status that is not "Approved", then you could not apply the transaction to specific invoices.

Allowing cron tasks, database access, etc. for modules makes them basically plugins at that point. We're re-evaluating the design of these extensions to be more accommodating.

Just to reiterate, the form returns a success message even if the username does not match a user account in order to hide information. Knowing what valid usernames exist can open up attack vectors. As @BlestaStore mentioned, you can update the Blesta.default_password_reset_value config value to false to instead show an error message if the username does not match an account.

Directories 755, files 644. Be sure that the web server (and cron) run under an appropriate (owner) user with sufficient privileges.

If the settings in Blesta haven't been changed recently, the cron may not be running. Have you checked Settings > Automation to see if the "Auto Debit" task has run recently?

What's in your gateway log regarding that transaction? My guess is Authorize.net responded to Blesta's payment request with a failure of some kind, so there wouldn't be any automatic follow-up to accept the payment later. Manually paying the invoice would be required at that point.

Thanks for the report, we'll take a look. CORE-2594

Unless you are logging metrics, it's impossible to say for sure how many times the average user is submitting the form. The sample size is also pretty small. Most customers aren't as familiar with and as fluent as us in filling out information on a website, so they're prone to making more mistakes, which makes 123 additional checks not sound so far-fetched. There are a couple things that prevent fraud checks from working that way: Some people may want it to check against incomplete data (e.g. @timnboys) Knowing whether the data is incomplete or not depends on the rule validation when creating a new client, so in that case you would need to create the client before running the fraud check to determine whether or not you can create the client (a circular pre-requisite)

Assuming a 'credit' is used each time an API call is made to FraudLabs API, 36 new client sign ups would result in a minimum of 36 credits subtracted. If the new users encountered an error, or some users never completed the sign up form with valid information, then that number would be higher, and 123 is not necessarily unrealistic. The fraud check would occur before attempting to create a client on sign up since that is the action a rejected fraud score intends to prevent. I took a look at the fraud verification checks and everything appears to be working as it should. The only improvement I can foresee making is possibly caching specific customer information and not performing the verification check again if that information hasn't been changed. This might reduce the number of fraud verifications performed to some extent, but it is still easy to spam sign ups and cause additional verification requests as previously mentioned.

Do you have a lot of user sign up attempts? There could be spammers/bots continuously making POST requests to the sign up form, but providing insufficient information to create a client, which would a fraud check to be performed each time without resulting in any orders or new user accounts. I can only speculate as to what actually occurred in your particular case, but I can say that Blesta's order plugin will only attempt to perform fraud checks for new sign ups and when checking out.

When Blesta provisions a service and attempts to use your module to register a domain, it expects that the service be made active, so the module should create the domain and return success, or not create the domain and return failure. So you should determine whether the registrar creates the domain on the account regardless of any technical issues that might arise which they will later attempt to resolve.

The FraudLabs integration is a component used by the Order plugin, but yes, it was originally written by another party (Hexasoft Development). The FraudLabs integration is rather simple, making an API call to verify the customer information against a fraud score to determine whether to deny either: The customer from creating an account during signup The customer from creating an order during checkout In either case (depending on your configured Anti-Fraud Frequency setting), if the customer encounters an error with these actions and re-submits their information again, another fraud check will be triggered.

This affects the server Blesta is installed on. The server must support TLS v1.2 in order for Blesta to communicate with Authorize.net since they are disabling support for TLS v1.0 and v1.1. You should contact your web host to ensure TLS v1.2 is supported.

I'm not sure yet if that field is something we would change the default behavior of, but if you'd like to set that behavior yourself you can update this file: /app/views/client/bootstrap/client_accounts_cc_info.pdt Find and change: isset($vars->save_details) to: $this->Html->ifSet($vars->save_details, 1)

What was the error?

I'm not sure I follow. Are you suggesting there is a bug that caused three invoices to be created for the same service?

The current logic exists to prevent customers from receiving the service for free for a period of time. The cutoff for voiding the invoice is when it is past due since that is the point we can reasonably assume the customer is entirely liable to pay the invoice for services rendered. If a customer has a service, but does not pay the invoice for it, it will become canceled after a period of time. During that time, they have received the service for free, but you are still due the amount of the invoice for having rendered the service to the customer. If, instead, you void the invoice at that point, you accept that you are letting the customer have the service for free for that period. This behavior can be taken advantage of by customers to repeatedly receive free services for a length of time. For example, they can purchase a service, not pay for the renewal, and get the service for free until it's canceled and the invoice is voided. Then they can re-purchase it and repeat the process to get some time for free without worrying about paying an open invoice. If you would like to offer free service time to customers in such cases, that sounds like it would be a business decision on your part, and we could add a new option to allow past due invoices to be voided upon cancellation, e.g. Open Invoices that are X Days Past Due Will be Voided Options: - Any - (always void a past due invoice on cancellation) 0 Days (default, current behavior) 1 Day 2 Days 3 Days ... 60 Days

Based on the template parse error you received, I think you pasted that code into the WYSIWYG as HTML, so the WYSIWYG encoded the text as HTML. When pasting code, it is best to do so in "Source" mode--that is, you click the "Source" button in the WYSIWYG so you can see the HTML source, and that's where you paste the code. If you see any HTML-encoded characters like   or % in between template tags then some of the characters were inadventently HTML-encoded and will cause a parse error. A valid conditional tag would not have any HTML-encoded characters, e.g.: {% if service.multicraft_login_username %} But while it may look correct in HTML, it may be wrong Source mode (which is what matters). If the spaces were HTML-encoded, Source mode would show: {% if service.multicraft_login_username %} In this case, the spaces were HTML-encoded to  , which is invalid syntax for tags and causes a parse error.

Is the invoice past due at time of cancellation? If so, the invoice will remain open. Are there any other line items on the invoice besides those related to the service? If so, the invoice will remain open, but the items related to the service will be removed.