Daniel B

Lol, neither am I, it's just fun to make fun of Paul from time to time lol

Lol. I'm not complaining about it
Loving Blesta so far!

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.

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!

+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

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 %}

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

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?

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 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. 

I like it +1
 
Though, I think the unlimited should be changed to -1, as what if we have a staff member that we want to not respond to tickets?

...haha bet your thinking what the hell is automatic tickets? I mean something like this... 
 
Blesta is smart, and powerful, so why not have a cool feature...
 
1 staff is online:
 
- Tickets don't get allocated to a staff member, they just show up as they do now.
 
 
2+ staff are online:
 
- Tickets get automatically assigned per staff member equally in order they came in. (Blue highlighted per staff).
 
 
Staff logs out:
 
- Their tickets get automatically re-assigned if a staff member has a free slot, the rest get re-assigned to the normal procedure (Removes back to Not Assigned).
 
---------------------
 
Settings (Staff section):
 
[    ] Enter number of tickets to assign to.
 
For example:
 
[0] - Michael (0 = Unlimited)
 
[5] - Callum (Callum only gets 5 tickets to deal with at a time).
 
[10] - Holly (Holly only gets 10 tickets to deal with at a time).
 
 
Thought I'd share this idea.

Maybe if enough people request it!

I talked to Dan Ushman earlier this year and they would very much like for us to build a module for integration with Tandem. We just haven't got enough requests for it yet to dig into it too much. So, definitely something we'd like to do, but we have some other things to finish up on first.

We need to get more done on the documentation, as well as the countless video tutorials that I'm planning to do. Maybe we can link those up somehow. In any case, anything that helps people learn how to use Blesta would be free.

Hi,

It would be great if you could maybe consider adding a basic internal knowledgebase so any admin/staff member can view for important internal information. It doesn't need to be all the features of the world but something where you can add a basic article or information piece for techs is great maybe also a basic ACL which prevents which admins/staff can edit, remove, add articles.

Knowledge Is Power

There are lots of arguments I can make in favor of a wiki.  At the core it boils down to this:
 
If you want a traditional Q&A / FAQ KB, it is VERY easy to make a wiki behave like one.
If you want a wiki, it is VERY difficult to make a traditional Q&A / FAQ KB behave like one.
 
So the wiki gives the best of all worlds.

I would love this, and I think it really is the way to go...specially since either way I'm guessing the KB will be coded from scratch...might as well push forward with technology and create a wiki based platform .
 
I'm pretty sure I posted a detailed explanation of why a wiki would be an awesome way to go during beta, but sadly I don't think that thread made it over to the live forums .

I think it may work in Canada, would have to verify that though. We are going to implement Docsaway as another option, which has better international support as far as I know.
 
 
We do have plans to add a delivery method fee that will allow you to cover costs for such delivery if you want to. I don't have an ETA on this yet.

Re-uploading that module seemed to fix it, thanks for the hint!

Great.  I think I might set up a simple wiki for now.  Crude but effective.
 
Speaking of, what are your thoughts on a wiki-driven KB?  It would still have the same article structure as a regular KB, and it would be easy to set up category / list pages so that it behaved like a conventional KB, but I think the wiki format encourages more reading.
 
Either way, as long as it hooks into the support system, I'm good.

The KB is moving up our priority list, and is tentatively scheduled for version 3.2. I don't have an ETA yet, but 3.1 is in active development and we are aiming for a beta release by the end of this month.. we'll see how it goes.

First...remember that if you make this change, you will most likely need to redo the change after updates, as this is editing a core plugin file that could be altered with new versions of Blesta.
 
You will need to edit this file: plugins/order/views/templates/standard/types/registration/main_signup.pdt
 
Find:
<?php $this->Form->fieldRadio("username_type", "email", ($this->Html->ifSet($vars->username_type, "email") == "email"), array("id"=>"username_type_email")); $this->Form->label($this->_("Main.signup.field_username_type_email", true), "username_type_email", array("class"=>"inline")); $this->Form->fieldRadio("username_type", "username", ($this->Html->ifSet($vars->username_type) == "username"), array("id"=>"username_type_username")); $this->Form->label($this->_("Main.signup.field_username_type_username", true), "username_type_username", array("class"=>"inline")); ?>  
Replace with:
<?php $this->Form->fieldRadio("username_type", "email", ($this->Html->ifSet($vars->username_type, "email") == "email"), array("id"=>"username_type_email")); $this->Form->label($this->_("Main.signup.field_username_type_email", true), "username_type_email", array("class"=>"inline")); ?>  
This will simply remove the username radio button, so the only option is to choose email.

Now I can see how to activate KVM machines. So I'm fine.
 
 
 
No, proxmox support KVM and OpenVZ.

Cheers!