Paul

What version of Blesta are you running? What version is the module? (You can check the module version under Settings > Company > Modules)

I pushed this up a bit in the backlog.

Blesta stores sessions in MySQL, not on the file system. I'm not sure this is what is causing the issue you describe because I don't really understand what the problem is. Perhaps more information would be helpful.

Here is a list of items resolved for 3.5.0 - http://dev.blesta.com/browse/CORE-1715?jql=fixVersion%20%3D%20%223.5.0%22%20AND%20status%20in%20(Resolved%2C%20Closed) Nothing really critical, but it would give you an idea of what you're missing if you run with 3.5 beta 5 now. Of course we don't recommend using a beta in production, and the final release should be out within a week. (Either this week, or more likely, early next week) We don't like to release late in the week.

Sounds like you found it! I wonder if we can make that more obvious.

I'm not sure if this clarifies anything, but Blesta needs to be able to write to the /config/ directory, including the /config/blesta-new.php config file. During installation it copies the blesta-new.php file and create the blesta.php config file populating the correct database, system key, and other information to blesta.php using blesta-new.php as a sort of template. If anything is preventing those files from being written, then you'll get the error you seem to be getting. What is interfering is really the question, and if it's not related to the file permissions then it may be something else server side. (Any other security related plugins?)

Go to Packages > Groups. Click the Package Group you want to sort on your order form. Drag and drop the packages within the group to sort them.

I'm not sure that field is for that purpose, hopefully Cody or Tyson can clarify. Auto debit is determined by other factors, such as whether they have auto debit enabled, and a payment account selected for auto debit. I *think*, maybe, that field is used when auto debit fails and will be re-attempted at a later time. Will need clarification, but that's my suspicion.

I think they should probably be queued for delivery

We do our best to ensure that public betas don't have critical bugs, but it can happen. The whole point of a beta is to open things up so others can find issues we couldn't find and provide feedback so that we can make adjustments in functionality. We can't and won't recommend running a beta in production, but some people do it. It's looking like we probably won't need a beta 6. Final release imminent (In by best robotic voice).

Someone else asked recently about the possibility of having a contact being attached to one or more specific services, so when they login they only see those services and can manage only those services. Your request sounds very similar, but in terms of billing. I think there is a good possibility of having more advanced contact permissions in the future.

In the next couple months is unlikely. We need to architect out the feature assign story points, and then schedule it. There may be the possibility for sponsored development, which could speed things along but ultimately this is a fairly involved task.

There is now a task for config option conditionals (field logic), CORE-1708. No ETA at the moment

Preliminary task for config option conditionals CORE-1708. No ETA.

I'm pretty certain this functionality was intentional, though the work-around is certainly undesirable. Instead, I think, if fraud checks can be skipped for existing customers, it should only be possible if the customer has active services, or previously approved orders. A setting in the order plugin along the lines of: [x] Run fraud checks for all orders [ ] Run fraud checks for new customers only Might work... and if you opt to run checks for new customers only, then they would have to meet criteria mentioned above (existing approved orders, active services) Thoughts?

Anyone with a service on a package that is marked inactive will continue to be billed normally. You can safely mark a package inactive to prevent new people from using the package, while continuing to bill those that already have it. You can do a service search (upper right search box) for the package name if you want to get a listing of everyone using the package.

That's a lot of plus ones. I'm sure we'll do this at some point, however it's fairly complicated as there's no mechanism build in to support partial refunds and we want to maintain proper accounting of transactions. It will undoubtedly require some changes to the database schema.

I believe system is above the "1" directory. 1 is the company value, so if you have addon companies then you'd possibly have a 2, 3, etc for each company with 1 being the default. The path to your uploads directory should be set under Settings > System > General

I believe it would require the module be updated to use the regex. The module defines rule validation for fields, so that's where it would need to be. Tyson may have more information. I found this discussion while googlin regex fqdn - http://stackoverflow.com/questions/11809631/fully-qualified-domain-name-validation They discuss the issue I raised with multi-level TLDs.

A regex could be written for a rule for hostname to require something.something.something, but the issue would still exist in multi-level TLDs. For example, someone would be able to enter domain.co.uk and pass the validation. A more complex solution would be capable of identifying such cases, but I think only if compared against an exhaustive list of TLDs. Considering the list of TLDs is growing significantly, I'd be hesitant to build in such a limitation.

That is funny. I get what you're saying, and I suspect we will have a method to change the private key in the future.

How is PayPal configured? Settings > Payment Gateways > PayPal > Manage. Under "Payment Options" there are 3 options. If you select "Subscription payments only" and the invoice has some non-recurring items in it, or items that are not linked to recurring services, then PayPal will not be available because it can't set up a subscription for non-recurring items. Also make sure that the correct currencies are enabled for PayPal. As serge mentioned, if this is during checkout then the gateway and currency must both be enabled on the order form under Packages > Order Forms > Edit order form.

There are 2 emails that could be considered welcome emails, the "Account Registration" email, which they get when they create an account and the "Service Creation" email which is comprised from both the Service Creation email template, and the Package "Welcome Email" content. I'm assuming you mean the Package Welcome Email. This really depends on what module you're using. The documentation has some example welcome emails. Check out http://docs.blesta.com/display/user/cPanel#cPanel-WelcomeEmail for an example for cPanel. Some people may be willing to share their welcome emails, but it will help to know which module you're using.

Is it possible that the request originates from the server's primary IP and that it's different than your Blesta IP and SolusVM is seeing the wrong IP when making API calls?

Yeah, 2.5. Probably 1.0 also.