Paul

Yeah, and it would be pretty outdated anyway.

It's ok, the license module is worthless without the license manager plugin, which acts as the license server itself. We haven't accidentally released that one yet.

Mandrill is pretty good for outgoing mail also, and it's free for like 12k emails a month.

You may be thinking of the license module we accidentally shipped during the alpha.

Some of your portal links appear to be using https, you should change those under Settings > Company > Plugins > Available > Portal - Manage. No links in Blesta force https anywhere, they are all relative, so any other pages that are coming up https other than the portal are probably a result of the webserver configuration.

Which demo extensions? The only ones I can think of are the demo gateways, merchant and nonmerchant.

Moving this from bugs to support.

In the manual now - http://docs.blesta.com/display/user/Removing+Branding

To remove client area branding, edit the file app/views/client/default/structure.pdt and look toward the bottom of the file for a line that starts with "<p>Powered by" and remove the line. To remove admin area branding, edit the file app/views/admin/default/structure.pdt and look toward the bottom of the file for a line that begins with "Blesta © 2007-" and edit as desired.

They have probably seen an influx of these emails since 3.0 was released, hopefully they'll stop blocking them by default. I assume no matter what we have it say, they would block it, so it's probably a good idea to customize it anyway.

Did the cPanel account exist previously? If so, Blesta would not have been able to create it and the service would remain as pending. If it did not exist, and Blesta created it but left the service pending, it's likely the cPanel server returned an error even though it created it. I'd check Tools > Logs > Module Log for a record of that, it may indicate what happened.

The email address for PayPal does need to match the email address configured in the PayPal gateway in Blesta. We are planning to add an option to add additional email addresses that should be accepted by Blesta.

I think if we do that it should be an option, and not the default option.

Check the mail log for that customer. If a payment was processed, an email should have been attempted and you can resend a transaction email from the log. Also, do these invoice reminder emails show up in the logs? The query that determines when to send a late notice or reminder starts with open invoices. So, if an invoice is closed it shouldn't ever send a notice.

This always shows that message, so as not to leak your usernames to a potential attacker. We may add an option to display an error if there is no match, but for security reasons we recommend leaving it this way.

The mystery price may be a price override. Since Blesta doesn't support service price overrides yet, these are imported into the package.

If you think it may be the content of the message, try changing that. Google uses a lot of criteria to determine whether they spambox email though, most of which are not content based.

We met the Vision guys a couple years ago, really good people. http://www.flickr.com/photos/48176820@N04/6028837095/in/photolist-abKnea I look high in that picture, though.

You'll need an active license, but, nothing is stopping you from signing up for another trial license. As long as it's on a different domain/subdomain/host, during installation, selecting 30 day free trial should get you going.

We have not set a date for the beta, it'll be ready when it's ready! (Hopefully by the end of this month)

temp tables may be created automatically by mysql

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.

Some configurations may be overwritten by the importer. You should be ok changing the company name, and modifying email templates though. However, I would suggest doing the import on a fresh install, then going through all settings prior to going live. If you want to have 2 installs, configure things how you want, and then compare/copy information over post-import to your imported install, we can issue a dev license.

It's going to get even tougher once ARIN gets down to their last /8. They are expecting to be completely exhausted December next year. Other RIR's like RIPE are already on their last /8 and things are pretty tight there now. From what I recall, you can only get a /22 (nothing larger) at RIPE, and you must get IPv6 addresses also. http://www.potaroo.net/tools/ipv4/index.html has some interesting stats. I'm on ARIN's mailing list, and there are very interesting discussions happening. Now, if you want some IPv6 addresses, easy.. problem is IPv6 isn't going to be replacing IPv4 anytime soon (probably never).

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.