Paul

Pending services are activated if paid. The default flow for a new order is "In Review" > "Pending" > "Active". Approved orders go from "In Review" to "Pending" when they are approved. If you check the "Require Manual Review and Approval of All Orders" for your order form, then orders will only be activated if you approve them. When you approve them, they go from "In Review" to "Pending". Once in Pending, the system will activate them automatically if they are paid.

Welcome and thanks for the feedback, we appreciate it!

Awesome, great to hear! Nice work @ModulesBakery!

We recommend marking the client as inactive. This will hide them from view, but you will retain a history of all of their past invoices, services, transactions, etc. If all of that were to be deleted, it would affect reporting on transactions/revenue

You could use an addon company, and separate your clients that way. In each company you would only create the packages you wish each to have.

What do you think of the URLs in beta 2?

The passwords are lost either way, as the encryption key in each of your /config/blesta.php config files is likely different. Copying them from phpMyAdmin will not work.

Can you confirm if Allow Reissue is NOT selected, whether the client can actually do a re-issue? Does it actually work? I suspect it will not work, but the fact the client can see the option is undesirable. If the option is displayed but does not work if "Allow Reissue" is not selected, then I'll create a task to simply hide the option in those cases.

Maybe it would be ideal to have a setting in the Plugin that would allow you to enable/disable each independently. [x] Ticket System [x] Knowledge Base

Try clearing the cache. Go to Settings > System > Staff > Staff Groups. Edit your staff group and simply save it. Extensions are upgraded automatically in most cases when running an /admin/upgrade

Hey, welcome back PauloV! The domain manager is indeed very important, but it also takes 20x more time to build than a mass mailer plugin.

Combining 2 Blesta installs into 1 is a bit of a challenge right now, because there's no automated way to do it. It's likely we will be creating a migrator for Blesta 3 -> Blesta 3 in the future, but at the moment no such thing exists. My recommendation is to manually import your 50 clients into an addon company for the 300 client install. It will take some time, and manual work but hopefully moving 50 clients isn't too tedious.

I think we need more information on how you want this to work. If you're selling the domain with Blesta, then you'll want to create your domain packages, put them in the same package group, and assign them to the order form using the "Domain & Other" template. This will put a whois at the beginning of the order process for domain ordering.

I like the Beetles, but I couldn't find the off button and had to mute my computer.

I haven't heard any complaints and from what I've seen webhostingbuzz is a solid company. I have no problems recommending them.

I haven't checked pricing, but you could also check out site5.com, webhostingbuzz.com, vps.net, uk2.net, delimiter.us to name a few.

Great, glad to hear it is working! Sounds like some permission issues for the reseller user may have been out of whack.

That's the issue, they disabled escapeshellarg(). Blesta tries to execute mysqldump to produce the backup, and some providers disable the necessary functions to do so. You may be able to convince them to re-enable it for your account. If not, you'll need to use some other method to backup your database, or move to a virtual server with Webhostingbuz where you have more control.

Mass mail will probably come before affiliate system. Everywhere I look, people are asking about mass mail.

This was a restriction in Blesta for versions 1.x-2.x. It's no longer an issue in v3, their is no reason to reserve a range of ID's for staff any longer. Previously, staff and clients logged in at the same place and could use their ID or their email so it was necessary to prevent overlap to distinguish staff and client accounts. No longer.

Yup!

A custom module should be able to do that for you. The only potential issue I see is that modules typically don't have access to transaction data, but you can probably assume that based on the package price. Also, if these are donations are they pre-defined? If the user enters the donation amount, a more complete solution may be required.

That's a business decision you'll have to make, and for some people having super fine grained control over the resources may be what they need. In my experience, most of the time that overwhelms people more than it helps. Having fewer, simpler, well defined options makes it easier to make a decision. Imagine going to the super market and trying to buy corn on the cob. Rather than charging per ear they charge per kernel. Every ear of corn is a different price and the kernels vary from 400-600 per ear, which one do you get?

Blesta isn't a payment gateway, do you mean to have Blesta process payment for something (through a payment gateway) and then update another database? When a service is provisioned, the module it uses is called. With a custom provisioning module, you could have those services perform a query on another database when the order is activated, suspended, unsuspended, or cancelled. Is that what you're looking to do?

The best way to do with with the least overhead would probably be to calculate it when a new article or category is saved, and store the counts in the database.