Paul

Nice work! Very detailed.

We've had a few people request this. The data is available to the template, so it could be added by modifying the template file. The extra information could cause rows to wrap more easily. Do you want just the customer name to be listed, or the company name also? Should it be listed in its own column, or next to the Client #? Just curious what you think. We wanted to have an option in a lot of tables where you could select which fields you want to be displayed, and in what order. This is the best solution, as it could be customized to your staff account.. but it's quite a bit of work and I don't have any ETA on that.

This was fixed in 3.3.1, as part of CORE-1455. Please upgrade to 3.3.1 to resolve.

This should be possible with the system we created in 3.3 that allows a module to "share" data between services. The module would create the view to change the password, and all services would recognize the change. Of course, Multicraft has to be updated in order to take advantage of this.

Thanks for your feedback! As Mike mentioned, we are working on better domain support. A HB migrator is also planned, but migrators are very time consuming to build and most people are migrating to us from the other guys. Hopefully we'll be able to focus on a migrator once some of the bigger issues (like the domain plugin) are resolved. You should definitely be able to write the other extensions you need, or hire someone to do it if we don't have support for them. Blesta is more developer friendly than any of the other guys, and more and more developers are becoming familiar with Blesta.

This is the recommended way to do it, so that you don't have to worry about it when you upgrade. If you overwrite the file, you'll have to add it back whenever you upgrade. Setting a different logo for the theme is the best way to go.

You should be careful with removing pricing that is in use, doing so could be problematic. With price overrides being added in 3.3, it's likely that there will be a method by which to set a price-override for all affected services when removing a pricing option in the future.

I don't mind!

The order form follows the standard flow, whether there are any config options, additional prices, or addon packages that could be purchased. The argument could be made that if none of those exist, it should skip the step but it is a special circumstance. Feel free to start a feature request thread if you'd like to request a change.

Based on Mike's video, looks like there's some lag time for the approver email to appear due to the API call that it has to make with GoGetSSL. Did you give it enough time? I would use the browser inspector to see what's going on with that request also, if it can't access GoGetSSL's API, then it will never load.

If it's still a problem, I suggest confirming all of your details with Enom. Others have also reported in the past that Enom was in error when listing their IP address, and they had to request it again. Also, consider what IP address requests are actually sent from. If your website's IP address is 10.0.0.5 but the server's IP address is 10.0.0.4, then you likely want to list 10.0.0.4 instead as Enom will see the main server IP address.

So you want to include the contact type next to their name in that dropdown? The contact add/edit pages in the client interface are changing pretty significantly in 3.4, but I believe this still applies.

Looks interesting, so it doesn't need to communicate with a 3rd party service?

najahost is right, clients need to order services through the order form. You can create order forms under Packages > Order Forms. The order form handles the entire order process from start to finish.

On service status change is part of CORE-562. It doesn't belong to any of our sprints for 3.4, though it's tentatively assigned to 3.4.

A task exists for this already, CORE-737 but it's not currently scheduled for dev so I don't have an ETA for this. I suggest blocking them at your firewall for now, it's generally more effective anyway.

We don't have an ego on the matter, I'd like to support all the different domain registrars. We have limited resources though, so we are attempting to put them to the best possible use by developing the most highly requested features first. An argument can be made that not many people have requested NameSilo because of the fact that we don't offer it, and doing so would open up the market. I talk a lot about widening the funnel for Blesta. Offering more integrations widens the funnel, and increases our market reach. So yes, NameSilo would be great. Right now we have been focusing largely on core features. Shoring up the core, so that we can focus more of our efforts on extensions in future releases. Pro forma invoices, pro rata, price overrides (all part of 3.3) are considered by many to be critical features. Only we can work on the core, but other developers can build extensions to integrate with an endless number of 3rd party services and APIs. We are also working on a domain registrar plugin, that will allow for simpler set up of domain TLDs and pricing, and consolidate many of the features of domain registrars to make module development for registrars simpler going forward. It's difficult to take time away from highly requested features, to build a registrar module a few people want, that we'll have to rewrite later anyway to make it work well with the domain registrar plugin. So, we hear ya. We know we need more integrations like NameSilo, and we aren't saying no. We just have to prioritize, and it's a difficult thing when we have so many great feature and extension requests. The community has had a large impact in the direction of development since our initial alpha releases, and we consider that dialogue of vital importance.

PayPal now requires HTTP 1.1, if your server is sending HTTP 1.0 headers then they will reject it. Blesta doesn't set this header, so it is likely set by CURL. Are you running an old version?

Hey welcome! Yes, you can ask for information during checkout as it relates to the service you're selling. If there is not a provisioning module for what you're selling, you'd be using the Universal Module. You can set up a product for the Universal Module under Settings > Company > Modules > Universal Module that asks for the fields you want (service fields section). If any of the questions/options you want to ask for cost extra, then they should be set up as configurable options (Under Packages > Options).

Order #'s are listed in Blesta under Billing > Overview as part of the Orders Widget. If you don't see an "Orders" widget, click "Manage Widgets" on the left, and drag it from the right to the left in the modal box to add it.

Do you have a reference? I predicted this in one of those previous threads. Logically, your server sends the markup for stripe.js, so if your server was compromised an attacker could modify that javascript to capture the card data anyway. It was a loophole that has apparently been closed as I suspected.

Ok, I think your support department/ticket issue is related to a transaction lock, which may be because of the missing pricing option in [1] above. The first step would be to fix that and try a new fresh import, things will probably look much better at that point. The importer is trying to import a null price, which means that price is likely null in whmcs and Blesta requires a value. I'll ask Cody or Tyson to take a look at the error and see if they can provide instructions for identifying the record that's causing the issue.

1. Check that your staff account has been added under Support > Staff, and has access to all departments. If you don't have access to all departments, it's possible the tickets were imported and you just don't have access to them. 2. WHMCS allows you to create credits out of "thin air", and Blesta creates a transaction for the total amount of credit a client has in an effort to balance their account. 3. What's broken with the transaction list? 4. Revenue reports are based entirely on transactions. Since you're importing from WHMCS, if Blesta has to create transactions in place of manually entered "thin air" credits that existed in WHMCS, then this will skew revenue reports. Filter out transactions of type "In house credit" to get a more accurate picture. The error: Integrity constraint violation: 1048 Column 'option_pricing_id' cannot be null on line 124 sounds like there was a missing price in the data being imported. Cody or Tyson may be able to provide more information on how to identify any such records in WHMCS and correct them prior to performing a new, fresh import.

Just FYI, this field can be disabled in the next release, 3.4 per CORE-547 and CORE-1443

TCAdmin is likely to be the next GSP module we write, but I don't have an ETA for you at the moment.