Jonathan

This query indeed returns an incorrect plan, the plan that it's basing everything on. All up/downgrades on this plan were done via Blesta, and in manage service Blesta does show the correct plan. "Package Name: SSD-5" MariaDB [blesta]> SELECT * FROM `service_fields` WHERE `key` = -> 'solusvm_plan' AND `service_id` = 12126; +------------+--------------+-------+------------+-----------+ | service_id | key | value | serialized | encrypted | +------------+--------------+-------+------------+-----------+ | 12126 | solusvm_plan | SSD-1 | 0 | 0 | +------------+--------------+-------+------------+-----------+ 1 row in set (0.02 sec) Hoping you have an idea as to what's going on here.

SolusVM extra_memory and extra_disk logic appears flawed. When adding/removing extra disk it does calculation incorrectly as if always based on the first listed plan with a similar-pattern name to what you're working with. To recreate it: Create 2-3 plans in SolusVM. Title them SSD-1 (1GB RAM), SSD-2 (2GB RAM), etc. Tie these to plans in Blesta. Create an extra_memory configurable option using a quantity field. Min 0, Max 1024, Inc 256 Create a new SSD-2 service (0 value on the configurable option). Add lets say 512MB of extra memory. The service should now have 2.5GB of memory since it's an SSD-2 with 2GB base, and we added 512. Problem is, we only have 1.5 because Blesta when adding extra, added it based upon the SSD-1. We take this even further: Remove the 512MB addon memory. Now we have 1GB of memory because again Blesta did this based upon the SSD-1 for some reason. The only way to get back to correct plan values using Blesta is to (with the addon values at 0) upgrade/downgrade the plan to another one.

+1

The Solus module will accept and pass through an ObnOxIoUs mixed case hostname. Since they're not case-sensitive, it'd be nice to have this run through strtolower() before saving it and handing it off to Solus for VPS creation.

I'm pretty sure I've ruled this down to a bug in the front-end theme (custom) which is rendering sliders as text input that's letting people input incorrect values.

I finally tied it to service validation. I can edit the service, taking the approach of nuking all service_options rows related to the service_id and saving the manage service page fresh so I know for a fact there's good data there. Set the service_changes.status back to pending and it fails again on the exact same error. Saving without using pro-rata so it doesn't queue up works perfectly.

Verified in 3.4.4 with default email templates that regardless of a client's auto-debit settings, date_autodebit in the DB isn't set and the customer is prompted to setup auto-debit (when it should tell them the auto-debit date).

Any action resulting in an invoice generated by means of pro-rata. Upgrades/downgrades including configurable options. What's the logic behind not queueing them for delivery? Seems like it should so the customer will know about the invoice if say for example they opened a ticket to have the given change done. It's done via admin side thus queueing it in service_changes pending their payment. The invoice should be sent to them for payment.

Upon invoice generation (verified over days now) date_autodebit isn't filled in the "invoices" table, thus all email tell customers they need to enable auto-debit causing a pretty good bit of confusion with them. Is it supposed to always be null? If so, how is "invoice.autodebit_date_formatted" in email template supposed to work?

I was able to confirm that this is due to no row getting inserted to invoice_delivery for the invoice when it's created. Should be a simple fix

Invoices generated by pro-rata actions are never getting sent and remain in the "unsent" state. Sending manually works, the cron does not catch these and send them, though. Modify a service, generate a pro-rated invoice, invoice is generated, invoice remains un-sent. You have to manually edit and send invoice. Should be flagged to be caught by the Deliver Invoices cron when generated. All three times the cron reports: Attempting to deliver invoices scheduled for delivery. No invoices are scheduled to be delivered. The deliver invoices task has completed.

A whitespace at the beginning or end of a search string results in no results found. I can't think of any case where it'd be warranted to need to search for whitespace at the beginning or end of a string, so perhaps a trim() here could fix it right up

Service changes are failing at times, seemingly randomly. There are no module logs corresponding to the time of the failure making me think it's happening before the module processing is attempted. MariaDB [blesta]> select date_added,date_status from service_changes where status='error'; +---------------------+---------------------+ | date_added | date_status | +---------------------+---------------------+ | 2015-06-07 19:44:48 | 2015-06-07 19:45:23 | | 2015-06-08 13:44:15 | 2015-06-08 13:45:16 | | 2015-06-08 15:39:00 | 2015-06-08 15:40:24 | | 2015-06-08 18:07:25 | 2015-06-08 18:10:25 | | 2015-06-08 16:08:54 | 2015-06-09 05:20:25 | | 2015-06-08 15:04:27 | 2015-06-09 14:45:25 | | 2015-06-09 05:08:01 | 2015-06-09 15:55:25 | | 2015-06-09 05:07:15 | 2015-06-10 01:25:25 | | 2015-06-08 13:44:55 | 2015-06-10 16:55:24 | | 2015-06-10 17:54:17 | 2015-06-10 17:55:25 | | 2015-06-11 08:53:43 | 2015-06-11 08:55:25 | | 2015-06-12 01:07:57 | 2015-06-12 01:10:12 | | 2015-06-12 20:49:23 | 2015-06-12 20:50:26 | | 2015-06-14 05:06:43 | 2015-06-14 05:10:27 | | 2015-06-14 18:28:22 | 2015-06-14 18:30:39 | | 2015-06-15 15:52:36 | 2015-06-15 16:04:27 | +---------------------+---------------------+ It's happening on brand new VPSs and older ones alike. I've spot checked and on some of these payment was made before the first cron attempt so that rules out potential lack of payment resulting in an error.

It looks like one-time coupons appear to apply correctly in the order process, but on the final price confirmation page get removed and are not reflected on the invoice. Recurring coupons work fine. Recreation: Create a package with a monthly price and a setup fee of something non-zero (haven't tested on a package with no setup fee). Create a one-time coupon similar to the following: http://jonathanwright.me/shots/shot-2015-06-15-10%3A11%3A48.png Place an order using this coupon. It will apply correctly at first but when you finish the order process it's removed and not reflected on the invoice.

On a whim I did this. Load the service's manage page with all options set as they are. Delete from service_options where service_id=<serviceid> Save the page thus setting these options back. Now there are 5 rows, and the date change works. Why is this error only thrown by date changes and not any other change? It seems as if something getting removed in the GUI isn't getting removed properly in the DB when saving the page.

Nope, but here's something interesting. Order of events: Set configurable option limit on that item. Load service page Attempt date change - fail reload page save with all existing options (no pro-rate, no use module) - success database drops from 10 to 9 rows for this server. attempt date change again - fail convert back to unlimited quantity load service's manage page. save with no changes (no pro-rate, no use modules) - success database drops to 8 rows related to this service attempt date change again - fail The quantity of this field is 1 for whatever it's worth. The two that already have a cap and are sliders have a quantity of 0. The 8 rows in the database all have a quantity of "1". Knowing that only 3 of the fields are of type quantity, shouldn't there still be 10 rows with a value of 1 for the dropdowns/checkboxes? Some checkboxes are checked, some are not. 1 of the 7 is checked.

There are 13 possible options in the GUI. There are 10 database rows. I can successfully "edit" any of these options and save the service. Renew date change fails. Out of the 3 options: 3 are dropdowns 7 are checkboxes 2 are quantity with a max (slider) 1 is quantity with no upper limit so it's raw number input

Doing that save doesn't seem to do the validation check, or proves that the error is indeed erroneous in it's return as I can do any other task on the page except change renewal date. It's hit or miss and I can't figure out why. If there were legitimately an invalid option, I shouldn't be able to change options and save without getting this same error, but I can change options, save successfully, try again to change renew date and it still fails. I can't change every single option listed on the page to something else, save that successfully, try again, still fail with the error.

Data entered into this field via the client side does not save. This field appears to be a dead field. There is no admin-side equivalent I can find. To replicate, add a payment account, login as client, try to save something in company name field.

Would changing a config option and clicking "edit/save" not fix this in theory, or at least trigger the same error? Does that not do the same type of checking?

It does happen even with "pro-rate" ticked. Here's what the page is POSTing: _csrf_token <redacted> action change_renew cancel term date_canceled 2015-06-10 date_renews 2015-06-18 section action Old renew date: 7/17/15 New renew date 6/18/15 Pro-rate not ticked. There is no cancellation set, nor am I trying to cancel this one. Not sure why that's getting passed. date_canceled in the database for this service is NULL.

Looks like this is out now: https://developer.paypal.com/docs/classic/express-checkout/in-context/integration/ Would indeed be pretty neat to have from the looks of it.

3.5b4. When working with a service with a price-override set, if the client attempts to add a configurable option Blesta wants to generate an invoice for an amount higher than the configurable option they're trying to add even cost. Price previewer in admin works and shows the correct price with or without price override being in place. Without the price override the client side works properly. With price override: http://jonathanwright.me/shots/shot-2015-06-09-14%3A47%3A27.png Without price override: http://jonathanwright.me/shots/shot-2015-06-09-14%3A52%3A43.png Only difference is Litespeed which is $32. This is monthly billing cycle. Admin with and without price override: http://jonathanwright.me/shots/shot-2015-06-09-14%3A53%3A57.png

I think the option of requiring a previously accepted order would be the best approach, unless you make an interim "in review" client status they'd be kept in if their first order gets flagged, which the system would remove them from upon acceptance of an order.

Obviously, but that's no solution to keeping someone from bypassing it to start with. Lets say I'm asleep and can't mark them as fraud (or better yet, just letting Blesta "do it's thing") and they order, fail fraud. Order again, lets say 5 times, get setup, and setup spam bots. Now what? Blesta let someone circumvent the fraud system by taking advantage of a flaw in the logic. EDIT - your second assumption is the correct scenario.