Tyson

You mentioned that you activated the service in the admin area. Does that mean you have the associated order form "Require Manual Review and Approval of All Orders" checked, such that you activated the service manually? If so, the order needs to be marked Accepted first from the order widget under the Billing Overview before it can be added correctly.

Thanks - CORE-1399

I need more concise steps to duplicate. Placing an order through the order form as a client indeed sets the cancellation date for me.

I think what you're describing is an extension of a separate issue (CORE-1389). I don't experience your issue otherwise.

I don't see an issue with the way it currently works. Setting a package to 'single_term' is identical to creating a service and then scheduling it for cancellation at the end of its term. Service data takes precedence over package data from which it was created. Upgrading/downgrading packages doesn't manipulate pre-existing service information, like a cancellation date. Otherwise, I can imagine clients working around a pending service cancellation (for whatever reason) by switching packages, then switching back.

I don't much use the events, but it looks like your reference to "this" should be an object, not a string.

Check your service creation email template, and the Welcome Email content for the service's package. Did you write the tag {package.*}? If so, that's not a valid tag.

Here is my *very legitimate* mathematical proof: -1 MINUS = (-1) (MINUS) = (-1)(-) = (-1)*(-) = (-)(-1) = +1

-(-1) = +1!

-1 MINUS!

I can't see from your screenshots whether the above are true. The client belongs to the client group that you set these settings for? The only other thing that comes to mind is that some files may not have been uploaded.

I think that setting is the source of the original problem. Your issue sounds identical to what was fixed in CORE-1345. I suspect "Use Package Pricing for New Services Only" led to a misconfiguration problem. As described in that setting's tooltip, "This option requires package pricing to be set in the specified currency to be available for creating new services." It sounds as if you had that setting checked and only 1 or 2 currencies defined for the package, but additional currencies were defined for the order form. The other currencies available on the order form are not supported by the package, but are required based on the aforementioned setting. No conversion takes place because the setting "...requires package pricing to be set in the specified currency...". So this particular issue wouldn't be a bug, but rather the result of a configuration conflict. In this case, you would need to be sure the currencies set on the order form are all supported by the package(s) on the order form.

Clients can only change packages (upgrade/downgrade) if "Allow Clients to Change Service Package" is checked under [settings] -> [Company] -> [billing/Payment], or if being overridden by the client group, this is checked under [settings] -> [Company] -> [Client Groups] -> (edit) The client has a service The package for the client's service is in the same package group as at least one other package The two (or more) packages have similar pricing periods (i.e. both are recurring, or both are one-time) and belong to the same group type (addon or standard) The two (or more) packages belong to the same module row Clients can only change terms if "Allow Clients to Change Service Term" is checked under [settings] -> [Company] -> [billing/Payment], or if being overridden by the client group, this is checked under [settings] -> [Company] -> [Client Groups] -> (edit) The client has a service The package for the client's service has multiple recurring pricing periods I think that should be it.

Thanks. CORE-1393

That is the expected behavior. Even if your credits will cover the entire invoice amount, you still need to select a payment option (non-credit) to continue. If the system has the setting enabled to "automatically apply credits to open invoices", then it's possible those credits will be applied by cron (possibly to different invoices), and you wouldn't be able to continue without making a payment using one of the gateways anyway.

What's contained in the module log in Blesta after you attempt to add the service?

Sounds like $_POST['names'] is actually blank. What is the value? I notice the key is plural, perhaps your form is using "name" rather than "names"?

It sounds like 1 is a valid daemon ID, but Is 101 a valid daemon ID? What are valid daemon IDs, and what happens when your attempt to provision on a valid daemon fails?

Not sure why you have two accounts and posted a duplicate thread, but I responded to your other one.

500 internal server errors preceed php's error handling. You should check your webserver logs for more info.

Usually an internal error regarding a missing default value means that a required parameter is missing, i.e. the system is not receiving a 'vars' parameter. The solution would be to make sure each parameter is set: $data = array( 'vars' => array( 'client_id' => 1, ... ) ); $api->post("invoices", "add", $data);

Not likely to make it into v3.3.

FYI, the conditional Paul described hasn't been added yet, and wouldn't work. But you can refer them to the ticket {update_ticket_url} so they can see it.

Merging clients isn't yet available. She probably had "Specify a username" checked and "Use email as username" unchecked, so she chose to create her own username instead.

You should have plans setup in Plesk. Then in Blesta, when you select a Server, an API request is made to fetch the plans from Plesk, which are then shown in the drop-down, as your screenshot shows. The names of the plans/packages don't matter. However, you may want to avoid using the default plans from Plesk. I've seen default plans fail to provision on service creation.