Daniel B

Why would you want your billing system usernames to be the same as publically visible usernames on your main site anyway? Different usernames + different passwords = good billing system protection.

so...3.3 is out now...just a little bump for an awesome looking plugin (though you are probably already working on it ).

I would be wary of using online tools to check for this vulnerability...as there is no way to tell which ones truly have your best interest in mind, and which ones are just trying to gather a list of vulnerable systems to sell to the highest bidder. It's easy enough to test for this on the server itself, without having to worry about a third party trying to exploit your server (which is what all of these tests are doing...). Just my opinion though.

Miikaa asked if Blesta can change the name of the invoice after it has been paid. I.E. Before Payment: Invoice #123 After Payment: Invoice #2014-123 This is not currently possible in Blesta is it? The advice given is simply to change the format that all invoices are created with...not to change the invoice format depending on if it has been paid or not like the OP was asking about...unless it's too early and I'm misunderstanding something, seems like we are giving some incorrect information here...

The portal template itself looks fine on both sites for me. Though the footer is messed up on the yatosha.com. http://screencast.com/t/Ex8tjRszEc The code you posted above also works just fine on my 3.2 install, don't have an upgraded beta install to test on though, my beta install is fresh.

I haven't upgraded my production install yet, if you want to paste the code you are using I can plug it into my portal and see what it looks like. Not sure if there were changes to any of the standard CSS/template files that maybe didn't take in the upgrade script but that did work for a fresh install.

Check and see if the portal plugin needs to be updated, if not...save your template code, uninstall portal plugin, reinstall it...see if that fixes it.

That is in the package creation screen. However, as I previously mentioned, this setting does not need to be set to "Any", it just needs to have server groups that are correctly setup (as in a specific reseller group that ONLY has reseller enabled servers in it).

gotcha. I haven't see anything that has been done for this specific case so far. Only thing I've seen is a VqMod script to disable the username field, and I can't seem to track that down either. I'd use it if you made it , seems like it would fit well with your Admin Tools plugin.

Once you get them added manually, and make sure their username/password is set to match interworx...all of the Blesta controlled side of it will start to work. Which means they can login from Blesta, Blesta will still be able to suspend the account for non-payment, etc.

the way I did this was with editing out the option to register with a username (posted as a contribution, I think someone posted a vqmod method of doing it as well). I think there's also a feature request floating around for it as well. Having this standard as default would be nice though. Being able to disable users registering with a username or with email (selectable in admin section) would be nice, but either one they choose, I think being able to reject duplicate emails would be a nice feature.

Features to the domain modules are on hold until the new and improved domain system comes out. Hopefully that will be a main feature of version 3.4...but nothing "firm" has been mentioned yet as far as I know. Blesta knows the domain ordering systems need some work, and they are working on it .

I don't really think this is something that we have to worry about. The Blesta team knows that they want to keep things simple and smooth. The UI Designer (Paul) prefers the less = more approach. So if they feel a feature request would add more bloat than it would be worth, I am confident that they will turn it into an optional plugin rather than a core feature. However, you also have to realize that Blesta is a billing system...and adding onto those features is going to happen and not neccesarily be added as plugins. The example you gave is a good example I think, the ability to delete a service that has been suspended for 90 days would be a main feature and directly related to the billing system...I'd see no reason at all to have that it it's own plugin, especially when all it would need is a setting in the admin panel on whether to use it or not. Blesta 3.0 is only a year old, and is not feature complete yet so I'm sure there is still plenty more "basic" features to add before we start getting into bloating the interface in my opinion.

yeah, the bottom one is just one I did for standard template, since it shows differently. All that is changed on that one is to make the sections collapsable, other than that it's exactly like it is now if you use this method with the standard template for the order form.

doesn't have the same effect. Even with the new list order form it doesn't allow you to have different package groups on it or a way to associate those groups to select different ones from a single order form...which is what the images are doing.

I think something like the simple addition of a way to link different package groups together (associations per group?) and then the ability to get to each one from an order page would be a way to get what you are looking for. For example, you can currently create an order form like this: but once you pick one of those options, there is no visibile way to choose the other one (without going back). Maybe just simply adding links to the associated packages to the order form would be nice. For Ajax/Wizard templates could look something like this: For standard template could simply make it collapsable:

+∞+1?

One of the main reasons I tend to choose Foundation in a lot of instances is because of it's integration with form verification right out of the box. I do a lot with forms, and it's a huge time saver. The pageload has never really been an issue or a thought really, neither one of them are really huge with minification done. (and I tend to strip a lot of the fluff I don't need anyway)

I think it would be nice to have, I'm all for more reports...as I'm a numbers guy and stats are always good +1

Though, the core is a stat I don't normally pay attention to, because it's normally not helpful at all. Simply saying "1 core" doesn't tell me anything. Is that a shared core? Dedicated Core (doubt it)? 1.8ghz core? 3.3ghz core? So if you are looking for advice on planning offerings...that's one thing I will say...give people details into what you mean by "core".

Nice info Paulo , I've actually been thinking about setting this up sometime soon, just haven't gotten the time...so I can start putzing around with stuff. Specifically in regards to responsive frameworks question though, I've been having a hard time choosing between Foundation and Bootstrap as well for upcoming projects. Bootstrap is definately the big player at the moment...but Foundation is very, very nice...

There is no such thing as standard, and really no way to answer this question. When I need a new VPS, it depends on what I need it for as to what I'm looking for...so it can change every single time I spin a new one up.

This is just something that I thought would be nice to have while I was testing some things out. I offer a package that is not available on monthly terms, so on the order form it is shown first (as it is the smallest package), but the price is more than the second package. While this is fine and dandy, it does sometimes lead to a client going "wait, why does the small package cost more?" because they don't realize immediately that it's a longer term. Could we add an option to allow monthly calculations into the order form for terms that are longer than a month...preferably on a package by package basis . I've created a quick mockup of what I'm talking about (mockup includes an example regarding configurable options as well to relieve a bit of possible confusion there too).

Tyson specifically mentioned the text tag for the service creation template, so I'm assuming that's what he was meaning. As far as I know, the only difference between the HTML/TEXT sections of the package is one using the {package.email_html} tag and one uses the {package.email_text} tag, Blesta uses that tag to determine what gets emailed out, it doesn't actually detect whether or not the email client is capable of either...unless I'm missing something, never thought that was a thing?

you don't need both of the tags. If you have both it's going to use both the html version and the text version.