Tyson

Not sure why clicking the same link would have differing results. I don't experience that issue. Logging in can take you to the last place you visited, even if that happens to be the client interface. For example, if you're looking at support tickets, but you go idle long enough that you've been automatically logged out, you can login again and be redirected straight back to the support tickets.

All of those results shouldn't be sent? The cron would deliver invoices from that list, and there isn't a way to change this behavior short of deleting those records or marking them sent by setting a sent date.

Sending invoices manually is independent of the cron delivering invoices. You can view what invoices are queued to be printed from [billing] -> [Print Queue], but there is no way to view what other invoices are queued for delivery (via email, Interfax, etc.) through the interface. Instead, you can run a query on your database to fetch the invoices that the cron would send if that task were enabled: SELECT * FROM `invoice_delivery` WHERE `method` != 'paper' AND `date_sent` IS NULL;

The client number and user ID couldn't be the same in v3. User IDs are split for admins/clients, and the client number is purely cosmetic.

The welcome email wouldn't have had anything to do with fixing that error. It sounds like you inadvertently fixed it by updating the package, which re-saves all package fields, including the selected cPanel server.

What is PayPal's response during a recurring payment? I'm not sure what information PayPal tells Blesta, but it may be best to simply cancel that recurrence and setup a new recurring invoice, and let the customer pay it via PayPal subscriptions.

Services are validated independently of one another, so you wouldn't know anything about a second service at the time the module is attempting to add the first. Any validation on multiple services before any have been added must be done at a higher level. The Order plugin, for example, iterates over each service when adding them. Before that happens, you could correlate all service data and perform your custom validation. There would likely be more involved in this than simply creating a new validation rule.

Be sure to backup your database before making any changes to it directly. If you are wanting to change all clients from one group to another, then you can run: UPDATE `clients` SET `client_group_id` = '2' WHERE `clients`.`client_group_id` = '1'; That will result in all clients from group 1 (the default group) being changed to group 2.

Moving this to feature requests..

In this case, you should place your custom language in the _custom language file.

The translator doesn't allow for corrections per se, it determines the 'most accurate' translation by repetition. Any corrections you have would need to be maintained yourself, unless you have yet to translate them in the translator.

You can go to the client's profile page in the admin area of Blesta, click the "Recurring" link in the Invoices section, and edit the recurring invoice to your preferences. Future invoices should be created based on your updates.

We haven't gotten to CORE-851. If you're able to create some styles related to that task, then that may help us get to it quicker.

The only way I see this being possible is if you: Re-used the same email address as a Billing Contact for multiple clients Explicitly sent an invoice to that email address from the mail log Explicitly checked an invoice from the client's invoice listing and sent it to that email address So if I were you, I would check if #1 is true. Look through the client whose invoice was sent, and see if the wrong email address is used for the client or any of the contacts.

The module row may not yet be known when selecting package fields. Most modules that need it will default to the first module row, similar to how the cPanel module currently works. What is the output? $types['packages']['@attributes'] should be fine as long as that is an array of key/value pairs.

Settings are inherited by default, so this is normal behavior. v3.3 adds a field for whether to inherit specific company settings, but it is not used to limit the inheritance of 'sensitive' settings, although it may be in the future.

What has changed since you last visited that page? You should check your error logs, or enable error_reporting in Blesta to see what error is causing the issue.

Unfortunately, you couldn't do it without negating the changes added in CORE-611 and CORE-1262 which were to automatically set the order-id on add/edit, respectively. You could, at least temporarily, update the module to not attempt to fetch an order-id. I haven't tested this, but you could try to update /components/modules/logicboxes/logicboxes.php (around line 318) from elseif ($status == "active") { if ($package->meta->type == "domain") { $api->loadCommand("logicboxes_domains"); $domains = new LogicboxesDomains($api); $order = array_intersect_key($vars, array('domain-name' => "")); $response = $domains->orderid($order); $this->processResponse($api, $response); if ($this->Input->errors()) return; $order_id = null; if ($response->response()) $order_id = $response->response(); return array( array('key' => "domain-name", 'value' => $vars['domain-name'], 'encrypted' => 0), array('key' => "order-id", 'value' => $order_id, 'encrypted' => 0) ); } } to /* elseif ($status == "active") { if ($package->meta->type == "domain") { $api->loadCommand("logicboxes_domains"); $domains = new LogicboxesDomains($api); $order = array_intersect_key($vars, array('domain-name' => "")); $response = $domains->orderid($order); $this->processResponse($api, $response); if ($this->Input->errors()) return; $order_id = null; if ($response->response()) $order_id = $response->response(); return array( array('key' => "domain-name", 'value' => $vars['domain-name'], 'encrypted' => 0), array('key' => "order-id", 'value' => $order_id, 'encrypted' => 0) ); } } */

Well, the behavior is to fetch the order-id if it's missing, and your cron is trying to activate the service without it. And an active service should have all of the fields set. Are you creating an invoice for those services? Simply not paying them would resolve the API errors--it won't attempt to activate an unpaid service.

Are you adding it through the admin interface? If so, you could change the service status to pending first. But when you go to edit the service and make it active, it will fetch the order-id anyway. So I guess it depends on what you're trying to do here.

That error is rather generic. Curious why you're using brackets for associative arrays. I'm not familiar with that syntax. The data values look fine, except for the due date, which is expected to be after the bill date, so the error is occurring on or before rule validation.

I can understand that. But Blesta does not make data available to views that it doesn't use, since that would be a waste of resources. It sounds like your template customizations need to be supported through a plugin instead, but since you don't want to use a plugin, there is no proper alternative than to change core files to do what you want. That said, I would not recommend anyone do this for reasons already mentioned, but you could technically load a model in the view and call it: $obj = new stdClass(); Loader::loadModels($obj, array("Clients")); $client = $obj->Clients->get(1);

Helpers can be available to templates, but none perform database actions, nor should they. Helpers are geared toward formatting, which is useful for display purposes, and is why they can be used in views. With any MVC framework, there is a logical design separation between Models, Views, and Controllers. Business logic, like database queries, are in the models, and views do not access models--they only get data by way of their controller. So like I mentioned above, the correct way to go about getting data for a view is to update the controller to make it available to the view.

What's in the Module Logs (under [Tools] -> [Logs]) related to the creation of that service?

The validation is only concerned with user input for a package per order, and the universal module does not validate the uniqueness of any fields. You can validate the user input yourself to check for duplicates in a callback method, likewise you can query the database to check for existing duplicate data as well. Here's a general example. You would just expand on the callback method to perform the necessary checks.