Tyson

What module and pricing is available for each of the packages?

Can you give an example? What extra information would be shown?

The hostname validation is more of a best-effort approach. I don't see a way to validate a hostname with complete accuracy without knowledge of all TLDs. Perhaps it can be improved to be more accurate as long as it does not become restrictive. I think Blesta uses the same validation check on hostnames throughout the system, in plugins, modules, etc., so it wouldn't be isolated to just SolusVM.

You should have /app/client_controller.php that begins class ClientController extends AppController {

This is where it should be, in a non-publically-accessible location. But you can put it wherever you want on the filesystem and then update the Uploads Directory setting in Blesta under [settings] -> [system] -> [General] to set the correct absolute path of where you put the uploads directory.

This is fixed in CORE-1700 for v3.5. If you want to pre-patch it yourself, open /app/models/users.php, then find and replace: $this->Record->select(array("users.*"))->from("users")-> open()-> where("users.id", "=", $username)-> orWhere("users.username", "=", $vars['username'])-> close(); with: $this->Record->select(array("users.*"))->from("users")-> open()-> where("users.username", "=", $vars['username']); if (is_numeric($username)) { $this->Record->orWhere("users.id", "=", $username); } $this->Record->close();

Thanks for the info. I tried "123test@gmail.com" and was able to login successfully, so there may be something else going on. In any case, I'll look into it and see if there is anything out of the ordinary.

Could you provide more information as described in How to Report a Bug? I am able to login with usernames beginning with numbers. I do notice a strange issue if a username begins with "1", but that is a very specific case. What username(s) are you having a problem with?

This is fixed for v3.5

You may want to try a different order form template (Wizard/Ajax/Standard).

I don't encounter that issue, and I'm not seeing where this logic would occur unless the page has been modified. It might help to see screenshots of the service and its options. You could also check the POST data being submitted when editing the service renew date to see if it contains a 'configoptions' field (it shouldn't). Is the service an old service that perhaps contains old configurable options that are not valid any longer? For instance, in 3.4 it was possible to change a service's package/term without any config options being changed. So if you changed the service to a different currency/term that a config option doesn't support, then that option would no longer be valid. Attempting to change them in the future might result in the error you mentioned.

If the service is added with "Use Module" checked, the module's ::addService method is called. If the service already exists for the client, and you are updating it, then ::editService is called.

The behavior you described doesn't seem correct. If you encounter that error, it should occur whether or not the prorate checkbox is checked. However, the rule that generates that error should never be triggered anyway because the change of renew date action does not include any config options from which to validate. Have you made any modifications to the service management page, or are you trying to perform this action over the API?

If the credit doesn't cover the required payment cost, then the client would need to also select another payment method. You don't find it confusing that they may need to enter credit card details and also select an Apply Credit box on the right? I imagine if they entered a new credit card, they would need to fill out the new payment details, then scroll all the way back up to check the "Apply Credit" box, then scroll all the way back down the page again to hit the Review button. That doesn't seem like a better UI design to me.

Can you be more specific as to where you are changing the renew date? Is this when managing a service in Blesta? If so, renew dates have always been required to be in the future, or greater than the last renew date if the service had previously renewed.

Thanks for the report. CORE-1699.

The currency converter does work. Features like "Merge Client" could be removed until it has been fully integrated, but that is not always necessary.

I don't follow. Can you clarify what page you're referring to?

It's not possible until that task is complete.

I think Cody was just mentioning a work-around to the problem.

We're going to discuss notification tags on the Universal Module more next week, and probably re-organize how they are passed along. See CORE-1698.

Make sure PayPal is setup to accept GBP. You can check this under [settings] -> [Payment Gateways] -> (Manage PayPal Payments Standard).

Blesta has four set by default: cash check money_order in_house_credit Each of them has "Use Language Definition" checked. While you don't need to have any of them, the in_house_credit one is used in the system in places where credits are issued.

Edit the domains? Once you've setup a module, like Namecheap, then you create a package, where you define TLDs to accept and nameservers to use.

This is in beta 5 of v3.5 as apart of CORE-1693.