Paul

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.

mmmkay CORE-1693

It sounds like you want to add multiple package groups to the same order form. Edit your order form and add them with the multi-select box, by adding them to the left side from the right side. Different order templates display things differently in terms of groups, so you may want to play around with the templates to see which one works best for you.

So everyone likes that third option, showing the client id in the heading in place of "My Information"? Interestingly this is what we did in Blesta prior to 3.0.

Sounds like a plan!

Yes, we will be adding the ability for authenticated clients to see and order restricted packages they have access to. This will round up this feature nicely.

ACH is basically a bank transfer. When you create a payment account you can create one for credit cards or ACH. Most people do not accept ACH, so you may wish to disable ACH. If you only accept PayPal or another non-merchant gateway, you may wish to disable both Credit Card and ACH, which will prevent customers from being able to create Payment Accounts that they can't use. Payment Accounts are exclusive to merchant gateways. If you want to accept credit cards through a merchant gateway, credit card should be enabled. If you want to accept ACH through a merchant gateway, ACH should be enabled. Edit: Stripe is a merchant gateway, so you'll want credit card enabled. Our Stripe gateway does not currently support ACH (Not sure Stripe supports ACH at all) http://docs.blesta.com/display/user/Stripe

Check config/blesta.php, does it exist? Are your database credentials correct?

I would be curious to see exactly what they told you. If you're up for it, please PM me or email sales (will go to me). We are very transparent about how we do encryption. Our competitor has historically implemented custom caesar ciphers for things like client passwords (I think they changed this fortunately) which are incredibly weak. Blesta uses strong encryption, but there's nothing secret about it. All of the encrypted data can be decrypted (with the exception of passwords which are one way bcrypt hmac sha-256 hashes). I can't say I'm surprised they had trouble though.

If you have an owned license with us, open a ticket and we'll issue a dev license. If you have a monthly license, or a license through a reseller email sales or open a ticket. In that case, we'll need some more information and can issue temporary dev license (renewable every 6 months, but still free)