Paul

I'd pay $4 for 512GB of RAM.

Did that work? Installation should only take a few seconds at the most. If it's taking longer than 30 actual seconds, there may be another issue.

One thing you could do is create an invoice with a future bill date. The invoice will not be delivered to the client until that date, nor will they see it in the client area. You can edit the invoice to add new items as they come up, and on the bill date the invoice will be visible and delivered. I did see that you don't want invoices delivered, in which case you can just set the client group to paper. Invoices will be "queued" under Billing > Print Queue, but you can periodically just mark them printed. If you will have services under their accounts, the above method won't work, but you can always sync service renew dates to a specific day. Prorata can also be used to to this as well, but it works for a specific day of the month, so you can't say that you want everything to renew on January 1st for example, it would be the 1st of each month. EDIT: So, if they order on March 15th, and it's a 1 year term, it will charge them for either March 15 -> April 1, or both March 15 - April 1 and April 1 to April 1 of the following year, depending on your "cutoff" day in the prorata settings. You can bill for x hours of support, but Blesta will not track that support automatically. I'd suggest using a sticky note to track that for each individual customer.

Does anyone here instead prefer a "queue" of suspended service that match the criteria for cancellation with a bulk option to schedule the cancellations for a specific day? ie now, or some future date? I ask because cancelling a service is irreversible and some clients may just need an extra nudge to pay. Personally I'd prefer to see services that have been suspended for X days, even if briefly, and choose to cancel them myself. Thoughts? Too much work, should be automated? Or good idea?

Yeah we've discussed this pretty extensively internally. So that we can get it out, the plugin will probably not yet tie into any third party mailers, however it will have a mechanism to queue and deliver mail systematically. So, if you're sending to a lot of people and leave the page or your browser crashes, it will still complete.

Tyson responded while I was typing, so just to add to what he said -- We carefully consider every core feature, if it doesn't make sense to be part of the core then it's implemented as an extension. Take a look at the Order System and the Support Manager. Both very well used, often necessary major features.. but we understand that other developers may create something that people prefer to use instead. Some future features -- KB, Mass Mailer, Affiliate System.. all of these will be plugins. (The KB will actually be part of the Support Manager plugin) Some features just make sense to be part of the core and forcing them to be extensions when they shouldn't be would fragment the system and de-stabilize the most basic function of Blesta. I ask the following questions when considering a new feature - 1. How widely used will the feature be? 2. How likely is it 3rd party developers will want to roll their own? 3. How basic to billing and client management is the feature, regardless of how many people will use it? Not that we go through a checklist, but this should give you an insight into our thought process. It's usually very apparent to us when something should be part of the core or not.

Looks like a nice RESTful API, do you know when the beta will end? To be honest, I'm not sure we would consider doing an official module until the API is out of beta.

Yes, you MUST overwrite these files when upgrading. Every single time. Also, to clarify, the hotfix can be applied to PHP 5.4 or PHP 5.5. The standard distribution will work from PHP 5.1-5.4, so it's not necessary to apply the hotfix to PHP 5.4, but you can. Also, there are 3 files, not 2 that are encoded. If you are only seeing 2, you may be looking at a patch where there was no change. Every major or minor release will have all 3 of the files.

We are going to be making use of PHP 5.3 specific features including namespaces, etc.. however to what extent and when I'll defer to Cody. That is the point really, to raising the minimum requirement.

We will be raising the minimum requirement to PHP 5.3 next year, likely in Q1 or Q2.

I'm not a fan of OpenVZ at all, if you ask me it's not really even virtualization. It's the shared hosting of VPS, but hosting providers love it because they can oversell. Each have their benefits I suppose. I prefer KVM or Xen PV personally.

Yeah, security-wise it's not a problem. Inactive users can't login. But, if you are concerned, you could change their password and email address and then de-activate.

We are intending to extend the portal plugin into a more fully featured CMS. Adding additional links to the navigation, even if they link to external content (ie your existing website) would be best suited for this plugin most likely. You could create additional pages and enter the content in a WYSIWYG editor in Blesta, or link those pages to external content.

Staff can do things that are linked to their account. Deleting a staff member entirely could cause database errors, and you would lose potentially vital information about the user, including credit card numbers they may have accessed. It's a good idea to maintain that information, especially for PCI requirements. Perhaps a 3rd status called "delete" which doesn't show them under Manage Staff under Active or Inactive but maintains this relationship would be good. Still, as soon as you deactivate a staff member they lose access.

Oh, that's part of the PHPIDS library. That rule wouldn't be executed unless you navigate to that directory in your browser. We try not to modify 3rd party libraries unless absolutely necessary.

Which rule do you mean?

Yeah it all depends on the application. Most VPS's we spin up here are very minimal on resources, especially since we gravitate to a one role per server rule. Separating each service, HTTP, SMTP, MySQL, etc into different servers means we utilize more but smaller servers. And each role has separate requirements.. a web server may require more RAM than an SMTP server for example. So, depends what your customers are doing. If you can determine that, it should be pretty easy to spec out something that will appeal to many of them.

Ok, we will leave the task open and plan to implement a fix, but it is unlikely to be in the official 3.3 release and will be fixed in a future version.

While this is rare, it is a legitimate concern and I think it should be corrected. The problem is that it's not an easy fix.

Under Packages > Options, click on the Group name and it will expand and display all the configurable options that are assigned to the group. I'm assuming all of your configurable options are assigned to the same group, and do not each have their own group. Is that right? Then, you just drag and drop them within that group. In the attached screenshot, I have a Multicraft group with 2 config options, Server Jar File, and Dedicated IP. I can sort them by drag-n-drop here.

Yes it will set a dedicated IP when provisioned automatically. You just want to make sure you have some IPs for each Daemon ID set up in the module (and available to multicraft). If they do not get a dedicated IP, it will use the shared IP and a unique port (Not the default 25565).

There's already a task for this, CORE-1287 however there's some confusion of whether this is a requirement or not. Anything you can provide that supports this requirement would be helpful, thanks!

If you email me temporary FTP details, I'll send you the beta zip.

You said you were using SMTP. Roundcube probably doesn't use SMTP.

Something must have changed someplace. No firewall issues?