Cody

Gotcha. I'm just fascinated with this type of deployment strategy. Have you considered using automated use testing with something like Selenium?

That's interesting. Seems a bit redundant to test on both staging and live if you ask me. After all, then what purpose do the testing and staging servers serve? Perhaps that's just my particular engineering bias, coming from the notion that you shouldn't ever go into production if you haven't already satisfied 100% of your tests.

Yeah, an authorization won't help you here. Paul is correct, a sale is the same as an authorize and capture. If the sale fails then the authorization would fail. The last time I looked at BluePay they did support payments without card security codes, so it may be a particular setting for your merchant account. Have you tried contact BluePay to see if they will remove that restriction to allow you to process autodebits? It may be that they simply don't want your account processing card not present transactions. If BluePay has modified their payment terms to disallow autodebit then we should certainly update the gateway to prevent autodebits from being processed.

I'd actually recommend creating a plugin to do this. Your plugin can create a cron task, and you could have it evaluate if today is the 1st, and if so create your necessary invoices. Your plugin would interact with the API locally, from within the Blesta environment, so it would be more efficient than running a bunch of HTTP API requests. Wow... every time I explain how some part of the plugin system works I'm reminded just how incredibly awesome it is.

Curious as to why you find yourself constantly switching between the test and live accounts. I find generally people don't bother with test accounts unless verifying payments actually work prior to going live. After the system is live there's no need to test any longer. Perhaps you'd be better off testing in a development environment, as opposed to your live installation?

Yup. Blesta won't add orders to the system that are certifiably fraud (based on your Maxmind reject settings).

Whoa! That didn't take long.

Click the order record in the Orders widget under [billing] > [Overview] to view the fraud details.

Blesta rejected the order because your setting to reject is 80 and maxmind gave it 99 (which is clearly > 80). If you don't want Blesta to reject any order regardless of score set the minimum score to reject to 100. The maxmind score is completely separate from the other options.

You should create a plugin for this search using the Navigation.getSearchOptions event. For an example of that, take a look at the Support Manager plugin which does just that to create the "Ticket Search" option. All plugins can automatically extend the API too.

Moved to feature requests as not a bug.

Definitely sounds like your webserver is setting cache headers. Sounds like a configuration issue. Moved to support forum, as not a bug.

It's definitely possible to create an HTML invoice as a substitute for PDF invoices. For that, take a look into the /components/invoice_templates/ directory. Unfortunately, documentation on invoice templates is sparse at the moment. As for displaying invoice details on the client pay page, you may need to modify /app/controllers/client_pay.php to pass invoice details to the appropriate views (/app/views/client/default/client_pay.pdt, client_pay_method.pdt, client_pay_confirm.pdt). Since Blesta allows a single payment to pay multiple invoices, Blesta doesn't display or set individual invoice details in the view (/app/views/client/default/client_pay_multiple_invoices.pdt). Yup, no doubt changing banks is easier said than done. Hopefully you have more than one banking option available to you, as this bizarre requirement may be only the beginning of their torturous business dealings.

I haven't seen your entire conversation with the bank, but again, from the snippets you've provided it sounds like all they want to see is the payment page. That sounds like any easy enough request to satisfy. If they're requesting something Blesta does not do, which again doesn't appear to be the case, then likely your only option is to find another bank.

Excellent. Closing this as fixed for 3.0.4 (CORE-781).

Try the attached file. Place it in /plugins/support_manager/models/. CORE-781. support_manager_tickets.php

You shouldn't have to uninstall any modules after making language changes. The language changes should appear right away unless the section is being cached. You can clear the cache in the /cache/ directory by deleting all files. If you still don't see the change take effect you might be editing the wrong file.

Sounds like the answer might be to group by all non-aggregate columns, which is actually ANSI SQL requirement, so we really ought to be doing that anyway. I'll see if I can come up with the solution when we head back to the office. Would be great, since you're able to reproduce the issue, if you could test it out.

Discussion continued in your original Bug Report.

Sounds like there may be an issue with recalculating invoice totals when appending services to an existing invoice. I've added CORE-774 to investigate.

Hm... not sure what the problem could be then. The pipe.php file works for me using cPanel. Of course our cPanel account added the hashbang a little differently as #!/usr/local/bin/php -q, but I'm sure that's an OS difference.

A user is a essentially a log in account. Any user type that can log into Blesta is a user (Staff, Clients, etc.). A client is essentially two parts: A user and a contact. The client record simply associates the user and the contact together to produce the client. This type of contact is known as the primary contact. Clients can have any number of non-primary contacts, but only one primary contact. Hopefully that sheds some light on the design.

Did cPanel add that hashbang automatically?

Sounds to me like your bank simply wants to see the payment page, not an invoice. Just send them a screen of the final pay page a client sees after clicking the "Pay" link in Blesta.

The issue is you don't have a path to PHP in your pipe and your pipe.php doesn't have a hashbang identifying the path. You nee to either: 1. Configure your pipe to contain the path to PHP as in the example I listed in my previous post 2. If you do #1 above, in cPanel, cPanel will ask you if you want to modify pipe.php to include the hashbang. cPanel REQUIRES the hashbang be present in pipe.php because they do not support using the path to PHP.