Paul

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.

Only one way to find out, my guess is, probably. They haven't changed much with their database schema I don't believe. However, it's probably better to copy your install, upgrade the copied version, and then import from that database.

Mike is right, you can upgrade.. however, couple things to note.. 1. If you upgrade from 3.0.x to 3.1.0-b1, you MUST run the upgrader via CLI, ie php ./index.php admin/upgrade 2. If you do a fresh install of 3.1.0-b1, you should be able to upgrade to 3.1.0-b2, and 3.1.0 final via GUI or CLI methods. This is due to a bug in 3.1.0-b1 that breaks the CLI upgrader.

What would be the benefit of a per-product override? You are either under EU rules, or you aren't, right?

Do you happen to have 4 client groups? If so, have you upgraded to 3.0.7?

Yes, the simplest thing would be to develop a plugin that calculates the price each month based on the # of days, and updates the package price prior to renewals. It can do so via an automation task it registers. Soon it will be possible to have packages defer their pricing to a plugin, in which case your plugin would be able to control the price directly vs updating the package.