Paul

I don't believe there are any restrictions for file types. Did you have trouble uploading such a file?

That raises a question for Cody -- can the importer now, or with some minor tweaks, import token payment accounts from WHMCS? I'm guessing something will need to be done to get Blesta to import or link these up with Stripe properly.. but it may or may not be very complicated.

No Vault yet. I'm pretty sure though, since you're using offsite storage of card details that a migration to any other gateway would necessitate customers re-enter their card details. If they are able to get the card details to you (Quantum Vault), we could potentially write an importer to bring those into Stripe. I'll defer to Cody on how complex that would be, but it should be possible, assuming there's a way to "export" these details from Vault. This is, of course, the biggest problem in my opinion with token based storage.. it becomes much more complex to switch to a different gateway.

Did you go to Settings > Company Settings > Plugins, and make sure the Support Manager plugin is the current version? If you see an upgrade button there, click it. install.php is safe to leave generally, but you may delete it if you like.

I was hoping Cody would see this and respond. The importer will import credit card numbers into their own payment accounts, but I am not sure about tokens. If you are using CDG Commerce, but are storing credit cards locally they will be imported locally and you can use whatever merchant payment gateway that you want. The Stripe module works for both local storage, and remote storage of card numbers. I believe if you import, use Stripe, and have stripe set to offsite (token) storage of cards, these imported payment accounts will just work.. though they will not be converted to token based. Then, newly saved payment accounts will use their token method.

We are planning to have it ready for public consumption, at least at a beta level by the end of the month. Being that it's been in production for us since 3.0.0-a1, it's pretty stable.. it's just a matter of a few tweaks, really.

The simpler solution, with the example the OP provided is to be able to independently create groups of custom client fields, and then assign one or more of them to client groups.

This would make for a really good plugin *hint hint*. I'm not sure this is something we will build into the core, because for those with large databases it could time out part way through, lock them out and generally screw up everything. It's much better to restore via CLI.

No news on this one just yet, we are still working out all the details.

Good to see you again!

Restoring a large backup could be problematic through the UI, and potentially dangerous if abused.

It's included in 3.1, upgrade and you'll have it!

http://docs.blesta.com/display/user/Upgrading+Blesta

We recommend setting up ntpd to keep sync'd up with a time server. On RHEL/CentOS this should work.. yum install system-config-date ntpdate pool.ntp.org chkconfig ntpd on service ntpd start

Do you have mod_security rules that may be interfering? You definitely want to have CSRF enabled, it provides a major security advantage.

I would wait for the final release to upgrade to 3.1. It's actually in QA now, so it may be released tomorrow.

That's interesting.. try logging out, and logging back in.

You're right, if a staff member has permissions to manage staff and staff groups, they can create staff groups for other companies -- but only from the company where they have these permissions. If they are logged into a company where they don't have these permissions, they won't be able to do so, even if they have permission to do so in a different company. The result is that an admin with this level of access to one company, can grant themselves access to other companies. But, that's how you give yourself access to new companies you create too. What you're asking is worth considering though, we'll take a look.

Is this out already? It looks like it may just require different embed code for the PayPal button, if so, this would be pretty easy to implement. First I've seen of it.

Maybe Tyson can take a look at this. Anyone else getting this error?

Email sales FTP details, and I can FTP a copy of beta 2 to your server for you.

Ok, that makes sense.. that's what I was looking for.

That sounds fun. I'm guessing many EU companies simply issue proforma all of the time, to avoid this, even if there is a contract in place. Just speculation on my part, trying to understand how it works in practice, and how important/practical a package level proforma option might be.

Yes, the feature is available in the current 3.1.0-b1 beta release.

That makes sense. In that case, what happens if the customer drops off the earth and breaks contract? I'm assuming you'd then be liable for the tax on on this non-collectable amount. Or is there a way around it? My assumption has been in part that creating a proforma invoice first not only ensures that the customer agrees to renew, but that they pay before you're liable for any tax. I'm not sure how chargebacks are accounted for, but maybe broken contracts are handled similarly? I'm curious whether proforma invoices are a big problem, or a minor inconvenience for contracted services, and whether its common practice for companies to issue proforma invoices in these cases.