Tyson

Can you provide example ticket information necessary to duplicate that behavior? Any custom changes to the H2o source, or the Support Manager plugin?

The LogicBoxes module does not look for configurable options to set. I imagine you would want to name the config option "protect-privacy" since that is what LogicBoxes uses (to be consistent). You would support it through the module's addService method.

Where's $config defined? Are your API credentials correct? Do any other requests return valid responses?

First, I would recommend not updating existing reports by editing source code. You can fetch any data you want from the system by creating your own custom report derived from your own query. You should think about the data that you want to retrieve and how you want it to be represented in the report. The additions of every custom client field and every purchased service for every client transaction is problematic. The relationship between these data are many-to-many. This does not bode well for a CSV report. You will either end up with numerous redundant rows of data, or you'll have to combine the services and the custom fields into a list in their own column row, per client. The latter limits much of the redundancy, but may make it difficult to interpret. I think breaking the data up into multiple CSV reports would be simpler.

Everything, really, since essentially everything has been updated. i.e. submit every form with good and bad data perform every action (including those in extensions) check for anything out of the ordinary like blank white pages, or pages with errors upgrade from version 3 to 4 create a new installation of v4 perform migrations from v2.5/whmcs to v4 check for obvious (or not so obvious) page styling issues see if anything comes across confusing that you think can be improved ensure current functionality still works try out the Mass Mailer plugin A dev system would be perfect, but where would you be importing data from? Not real data from a production environment, correct? Sometimes people insist to me that they want to test changes in a dev environment where the data mirrors what is on the production server. It sounds like a simple and convenient way to test what is and what will be, for comparison. They'll just disable emails from being sent and disable payments from going through in order to be sure real customers do not receive emails or get charged from the dev environment while they are testing it. However, this is a horrible, horrible, horrible idea for numerous reasons. Not only does it limit what you can test (e.g. can't test sending emails or making payments), but bugs may exist that send emails, make payments, etc., even when disabled. All data in a test/dev environment must be test data. I hope that's the intent of everyone that will be trying out the beta.

You can try setting the errors back to none. This may work: if (($errors = $this->Services->errors())) { ... // Reset errors $this->Services->Input->setErrors(array()); }

Is this plugin on the marketplace?

Both the admin and client whois tabs perform identical actions, so it's interesting that one works while the other doesn't. When you check the module logs, do you see identical requests/responses when updating the whois information? There must be something different in the input or output between submissions from the admin versus client interfaces. Can you include the logs (with sensitive data excluded/masked) from a successful and unsuccessful attempt?

Is this an issue from the UI in Blesta, or when you pass your own call to Invoices::edit? If the latter, it sounds like the work-around is to always set the invoice status.

No date yet. The details are a couple tasks need to be done and that necessitates redesigns to make them happen. When that's done, it's beta time.

You could implement those NonmerchantGateway methods in your gateway, but they would never be called. Neither Blesta core nor the Order plugin implement them for use. You could create an order plugin that does call them, which could work in a similar way as the current buildProcess. However, there will probably be some additional changes necessary to fully support an 'in-context' payment transaction.

We don't have any updates on a feature to renew services before their renewal date yet. CORE-2058 may be the task to do it.

I haven't looked at the importer, but from your code I don't see any problems. You may want to group on the service ID though. You mentioned you have 10k services. Fetching them all at once may exhaust memory. You can iterate over the records instead: ... $services = $this->Record->group(array('services.id'))->getStatement(); foreach ($services as $service) { $this->Record->where("services.id", "=", $service->id)->update("services", array('package_group_id' => $service->filled_package_group_id)); }

What is the loop here exactly? Someone emails in a ticket from their automated system, resulting in Blesta and some other automated system exchanging endless tickets? The Support Manager already rate limits itself so it would only send out (I think) 5 responses in a short period of time before it would stop responding to incoming tickets for a while. Normally, that should cease the ticket exchange. There currently is no setting to disable automatic replies for a support department, although such a feature could be added. However, besides this endless loop situation you described, what cases would it be useful to have it disabled? I imagine clients would like to receive a notification about the tickets they've opened with your support department.

A dedicated IP address needs to be set as a configurable option for the service as described in the docs. The port to use is chosen by Multicraft, which can select ports incrementally from 25565 and up. The next update to the Multicraft module will allow you to set a port for dedicated IPs to force Multicraft to use them.

I want beta too. I need to encase myself in a time bubble whereby everything outside the time bubble goes at a slower pace.

You would have to update the core (navigation model) to add support for icons. Then you would have to update the primary navigation output (structure template) to add support for displaying the icons. Your example shows a number of links in the sidebar. That works well with a large vertical sidebar, but not so much with a static horizontal link navigation like Blesta uses. The links + icons take up a lot of space, and wrapping can be an issue.

He's referring to SolusVM. This issue is related to what was added in v3.6.1 for CORE-1875 -- a bug in SolusVM with resetting passwords for KVM. I'm not sure if they've resolved the issue on their end, but if so, we can update it in Blesta.

Could you provide example input to the API request(s) you're calling that generates those responses?

FYI, explanation of operators. {"dedi_username":{ "format":{ "rule":["compares","!=","root"], "message":"Username must be other than root!" } }} That rule basically means that the module expects a field "dedi_username" to be given. The value of that field must not be "root", otherwise an error will be encountered and the message, "Username must be other than root!" will be displayed. Information on rules is described in Error Checking. While this page lists example rules in php, and the Universal Module (and your rule above) use JSON, the only difference is in formatting.

I believe the client information is already available to the templates, and your example will already work in those areas, except for the Support Plugin. In the Support Plugin, you will need to fetch the client information and set it to the view.

In what way? The structure template for order forms only contains one line, which is to output the content derived from the other templates (e.g. the order form).

Did you delete any client groups recently? Go to edit the Order Form that the customer used. Take a look at the field for "Default Client Group". If you had deleted a client group, it may show a valid client group (first in the list) even though that is not the value it is using. Re-save the order form to update the default client group to use for registrations.

How do you determine what the 'local' currency is? Local to you or local to the client? Presumably you already know what the local currency is, so it should only be a matter of converting from the invoice currency to the local currency using the exchange rate. If you don't want this value to change as exchange rates change over time, then you will need to store it. You may want to look at creating a plugin that ties into the Invoices.add and Invoices.edit events. I would imagine that you could create a plugin that defines a new database table that references an invoice and defines a field for the currency (and price if you need it). Then your plugin can be used to fetch that information when viewing the invoice so that it can be displayed. The last part, where you must fetch/display the additional information would require you to update core code to integrate it.

The API deals with CRUD actions on data. A page is not data in this respect, and is not available via the API. You'll want to either create your own pages using the data you retrieve via the API, or link to a Blesta order form, for instance, to have customers checkout.