Leaderboard

Limestone's support has been great. Their back end is pretty impressive too, with bandwidth pooling and virtual racks and whatnot. My only gripe about Limestone is that they're very thorough with IP blocks. I've never been denied needed IPs, but they take their time and require details of all your other IP allocations elsewhere. I suppose that's going to become the norm as the IPv4 shortage looms, but that doesn't mean I have to like it. Otherwise, they've been great to work with. They were one of the few companies at HostingCon that actually sought us out and really wanted to meet us, tiny company that we are. If you chat with them, tell them Dave from Fresh Roasted Hosting sent you over!

I was think that it would be great if we had a average ticket response time so our clients would know how long they may be waiting for there ticket to be replied to and also it would be different for each department as some departments may reply to tickets before other departments

B7 is now ready for download. Also, another tip for speed improvement is to comment out or remove line 66 from whmcs_migrator.php: #"importMisc" // works The "importMisc" method imports email log data, configurations, calendar events, and todo events. So there's a lot of inserts there that may not be necessary. We have a small data set, obviously, but 26% of the import time is spent importing that data. Your results may vary, obviously.

That's expected. That's correct. For what module(s)? Install the Support Manager plugin before you run the importer, or set permissions after the importer finishes. Examples of what you're seeing? For domains or products/services (in WHMCS terminology)? Package pricings come straight from the tblpricing table. You shouldn't have any prices defined in Blesta that aren't defined in your tblpricing table. Fixed in the next release. To patch change line 845 of whmcs_migrator.php to: 'qty' => $product->stockcontrol == "on" ? $product->qty : null, Tickets numbers in Blesta must be numeric. To extract only numeric values from ticket number change line 1167 of whmcs_migrator.php to: 'code' => is_numeric($ticket->tid) ? (int)$ticket->tid : preg_replace("/[^0-9]+/", "", $ticket->tid), Ticket status mappings were fixed in b6. b7 with the above changes coming soon.

It's pretty low on our priority list, but something we're interested in adding support for. Have you tried contacting Kayako about it? Maybe they are willing to build in support like they have done for other billing applications.

^This. In v3.1.0

CORE-846 fixed in 3.0.6.

Install::tmpDir() method was updated in CORE-814 for version 3.1.0. For those that are curious, here's the new method: /** * Determine the location of the temp directory on this system */ private function tmpDir() { $dir = ini_get("upload_tmp_dir"); if (!$dir && function_exists("sys_get_temp_dir")) $dir = sys_get_temp_dir(); if (!$dir) { $dir = "/tmp/"; if ($this->getOs() == "WIN") $dir = "C:\\Windows\\TEMP\\"; } $dir = rtrim($dir, DIRECTORY_SEPARATOR) . DIRECTORY_SEPARATOR; return $dir; } The solution to the issue you are experiencing is to set your temp directory to the value you get from ini_get("upload_tmp_dir").

Added as CORE-858 so we can take a look into this issue.

ARIN requires 80% utilization in order to request more resources, if you're getting IPs directly from them. ARIN (and other RIRs) have rules for ISPs in how they allocate resources to end users but these ISPs may have more strict requirements as they try to avoid from running out of IPv4 addresses. ISPs use customer IPv4 justification forms to justify their requests for more IPs from their RIR. They probably care about your allocations elsewhere to help justify your need. For example, if you have an aggregate of /22 across all companies you do business with and are requesting a /24, you're increasing your network size by 25%.. not a big deal. On the other hand, if you have in aggregate a /22 and request a /21.. they are likely to reject your request unless you have 80% utilization on that /22 and are planning to migrate everything to them and release those other allocations. Edit: So, telling them what you have elsewhere is likely to help you get more IPs from them.

I think that's confirmation that this is a bug.

+1 for this from me

You can show the previous due, for example, in the "Invoice Delivery (Unpaid)" template: e.g. {% for invoice in invoices %} Invoice #: {invoice.id_code} Previous amount due: {invoice.previous_due | currency_format "USD"} Amount due on this invoice: {invoice.due | currency_format "USD"} {% endfor %} I'm not sure if you specifying the currency as a variable would work, but if so, it would be a better solution: {% for invoice in invoices %} Invoice #: {invoice.id_code} Previous amount due: {invoice.previous_due | currency_format invoice.currency} Amount due on this invoice: {invoice.due | currency_format invoice.currency} {% endfor %}

We are aiming to allow customers to start, restart, stop their services through the billing panel. In additional we are also looking at allow console commands through the billing panel. Basically cutting out the tcadmin panel portion out of way so they won't feel the need to open two things. Although we will keep the panel around so people can still access it if they feel more accustom to using the tcadmin panel.

+1 for someone excited about it...since I use wordpress for every site that I make...saving me a bit of integration would be nice

I always like to hear about plugins coming together for Blesta, especially when developed by third parties. So I'm happy to hear you're working on something to integrate with Wordpress. I'm sure there are several people that would jump at the opportunity to use it.

Confirmed and added as CORE-846 for v3.0.6.

I think it would be beneficial if it could be added in to a function so we can include it where ever we want in custom templates.

We are planning to add some overall ticket stats like average response time, average resolution time, etc in the admin area. Do you think these averages should be displayed to the customer so they have a rough idea of when they can expect a response? If so, how and where?