Paul

The order system can hold an order for "review", such that even if it is paid it will not be provisioned. Services are by default set to "in-review", and the order system marks those services related to an order as "pending", once the order is approved. If maxmind or the settings prevent an order from being approved, the services ordered will never be activated. Payment is completely separate, and the order system cannot prevent a payment from being made. Some orders, even if they are assumed by Maxmind to be fraudulent may not be and the best course of action is for Staff to review the order.

Most likely they store the IP address in a different way than the user/pass/hostname so it wasn't brought over. Were you using a specific module in whmcs for the dedicated servers? If so, perhaps once we have a module specific for dedicated servers the importer could be updated to do a better job of importing IP addresses and other attributes. Unfortunately there is usually some manual work with an import, as much as we try its difficult to handle every scenario. Hopefully it's not too bad for ya!

Ah, CORE-1008. Nice find!

CORE-912 addresses this. Most orders are paid and activated same day for most people, but this is an important distinction for services that either are awaiting payment for an extended period of time or for services (such as colo or dedicated servers) that may need to be manually provisioned over the course of days.

It looks like these are the official codes for these regions: 01 - Central Signapore 02 - North East 03 - North West X1~ - Singapore - No State 04 - South East 05 - South West It's likely that Blesta could benefit from some localization rules for address formatting depending on region.

Maxmind and the order system will not prevent payments from being made. The red X simply indicates that payment has not been received, as evidence by the invoice not being marked paid. If the Bitpay payment was settled, then there may be an issue with that information being passed back to Blesta. In my experience, with the default settings, it would take about an hour for Bitpay payments to appear in Blesta but it sounds like much more time than that has passed.

I believe the company ID may be available, and a conditional could be created to display different content for different companies. I'll have to look into it, unless someone else knows?

Support Manager Pro may not be properly observing the date and time settings. A possible bug, @PauloV? I wonder if our official Support Manager properly observes the localization settings, anyone care to confirm?

Most people don't know how to write regex's, but I could see this as being useful as an "advanced" feature. We have had several discussions about how to efficiently deliver the emails, considering there could be very many. I believe we currently do some rate limiting in Swiftmailer, and for SMTP connections, limit the number of emails sent per SMTP connection so that they are sent in sort of "batches". If the email process fails, we want it to also be able to pick up where it left off. So, what we are leaning to do is to generate a CSV always and write it to disk. Then, we can store how many emails we've sent and if the process fails we can pick up where we left off. These CSV files would then would also allow a history of mass mailings to be stored, along with corresponding information in the database about each "campaign". Email will be delivered by cron, and you could view a "job" in the UI and see the status of the mailing.

Go to a clients profile page, and click the "Manage" link next to their dedicated server service. There should be a section for Module Options, which may or may not contain any options. When importing things for which a module does not exist or cannot be mapped, the Universal Module is used and a Universal Module Product is created. See Settings > Company > Modules > Universal Module. There should be a "Product" here that was created during the import. If you edit it, you'll see a Service Options section. This section defines service options, such as hostname and other items that do not alter the cost of the service. If your IP addresses cost extra, then you should have a configurable option, typically a drop-down menu that defines the allocation and price. In this case, this is for billing purposes and the actual IPs are not stored as part of this option. They could be stored manually in a service field as part of the Universal Module product. Better handling of IPs could be achieved by a "Dedicated Server" Module, as well as an IP Management plugin for Blesta, both of which are tentatively planned for a future release.

What features are you expecting in a mass mailer? Filter by criteria Compose and send email with tag replacements, or export client list to CSV In terms of criteria to filter by, here's a short list off the top of my head: Client Group, Custom Client Fields, Client Status, Language. Module, Module Row (for example, Server in case of a cPanel module), Package.

I'm in the middle of spec'ing this out. It may be a good time to revisit and discuss any "must have" features.

I'm pretty sure nothing changed with the stripe gateway from 3.3 to 3.4. Please check that curl SSL is still available to your PHP build. Blesta uses curl over https to stripe's API. Also ensure that port 443 egress is open at your firewall.

This has been assigned to CORE-1569, thanks for following up.

Preventing a module change on a package with existing services is probably the first step in a multi-step solution to improve this overall. Perhaps allowing modules to be changed and providing a process of "migrating" existing services over. CORE-1568 will prevent the module from being changed for packages with existing services. It is currently private and it has been assigned to part of an Epic for 4.0.0.

CORE-1567 thanks!

Can anyone think of a use case where you would want to allow management abilities of any kind to a client whos service is suspended? Either we have to add a setting to add backwards compatibility, or we implement a fix similar to what has been suggested. If we add a setting, modules could render or not render management views depending on the service status.

It's not likely to make it into 3.5, unfortunately.. but it is likely to be the next new feature for the support manager. We've been getting a few requests for it lately, and we appreciate the bump. I think it's CORE-450 actually, though CORE-605 will be nice as well, and simpler to implement most likely.

Just to be clear, you are saying: 1. When creating a package, you must assign or create a new package group for it. and 2. When editing a package, you can save it with no package group assigned? Packages cannot be ordered if they are not part of a group, but you may wish to have packages that don't belong to groups or to temporarily unassign them.

I've added CORE-1562 for a password strength indicator. It relates to CORE-552 which describes auto generating passwords.

CORE-1561

The alternative is that an account not be created and the order not be officially placed until payment is received. That's more complicated to do, but more than that, you could lose more orders. We follow up with orders that are placed and never paid, and in many cases that results in the order being completed.

Is there ever a case, when you wouldn't want the converted proforma invoice to be delivered? Or, are you saying that when proforma is converted to invoice, it should always be re-queued for delivery, using whatever the clients delivery method is?

An invoice is generated, and the order placed, prior to receipt of payment. The order however, will not be provisioned until payment is received.

You would just set the pricing for the configurable options as well. In order for a configurable option to be available for a 6 month package, it must have a 6 month price set. Just add all the appropriate pricing options for each config option.