Paul

Also, Blesta has its own locking mechanism to prevent race conditions.

Invoices are always queued for delivery when created. You can use the invoice email feature to send it right away. Two points on this: Invoices can be delivered via other methods, not just email. Queuing them up for a separate process to deliver them provides consistency. If invoices that should be emailed, are emailed when an invoice is created it will complicate the invoice generation process. The extra time required to email would take invoice generation longer, and introduce more possibility of errors. We want invoice generation to be solid, and stable, and fast.

I created CORE-1556 a couple weeks ago to address this. It will ensure the billing overview widget is installed by default, on the primary staff user upon installation. It's very easy to overlook when it's not there by default.

Are you using an AJAX template? If so, no cart exists, and this may be the issue. Maybe you can provide steps to duplicate?

Are you using nginx? This is a duplicate of this thread - http://www.blesta.com/forums/index.php?/topic/3923-critical-keep-getting-call-to-undefined-function-crypt-random-when-trying-to-install-blesta/ A solution was discussed there, which has to do with the include path.

Agreed. Please see CORE-1573

A blank page isn't good, try enabling error reporting: Then, see if the page is blank, or if it's outputting an error. Also be sure that CURL SSL is available in your PHP, and port 443 egress is open at your firewall.

Yup, this is in 3.4 as part of CORE-1148.

That's good to know. Your prorata settings would help also. My initial suspicion is that it has to do with the current day (Jan 30), and that it may be a weird date calculation issue. I've seen weird date calculation issues with PHP before, but the possibility exists that it could be a bug of our own making. My guess is that it will correct itself on its own tomorrow or the day after, but looking forward to hearing what Tyson finds out.

You could include the bank in the Check/ID # field, however the client will be able to see it. There are indeed no notes option for recording a payment beyond the transaction ID. If you must store more information about a particular transaction, you could create a note on the clients account and reference the transaction, adding other details. Of course, this is an extra step.

Awesome. The other "log" exists as a matter of necessity. A CSV is constructed, and an email "job" is created and linked to it. The cron delivers the emails, and picks up where it left off if it crashes, so it's not simply stored in memory. These recipient CSV files and email job information is stored even after the email has been fully sent, and can be used to determine who received what email even without the suggested standard email logging option. Though, without the actual logging, the real contents of the email delivered to each recipient would not be deducible as that information output from the tags may have since changed. I think a "Delete" job option would be nice, to clear out any history and delete the corresponding CSV for the job.

There will effectively be a separate log from the plugin section. The plugin will contain a history of past "jobs", which will be linked to a CSV file stored on the file system in the uploads directory, and the email content will be stored in the database for the job as part of the plugin. What's different is that we will not be storing the individual email (after tag replacement) for each recipient. You will have the original email, and you will have the list of recipients. If we add a "Log Email" option, it will use the core email logging as it does for everything else and the actual email, after tag replacement, would be stored for each client.

I received your email and sent you a new trial key. If you have any trouble, please let me know!

Anyone else agree? Perhaps an option to log when sending the mass mail?

Emails will be sent out in the background via cron, through an automation task the plugin registers. You can view the status of each "job", as its in progress in the UI which will simply ajax update periodically to fetch the status. You can leave the page, come back and view the status anytime without interrupting the emails. Emails will not be logged like other emails, as this would be very resource intensive and flood the mail log. I've updated the task to mention this.

This thread does not have a link to the task, so here we go for reference - CORE-621 Some details have been updated in the task that better describes filter criteria I am proposing as well as other details. If you have any suggestions, please let us know. Also keep in mind that we want to keep the initial release relatively light, and focus largely on the most important features. (For example, later we hope to be able to export to Campaign Monitor and other email campaign softwares)

I have created CORE-1570 that suggests we disable client access to module management tabs for suspended services. While an argument exists that modules may wish to provide management features for suspended services, no such example exists. In all known cases, displaying the tabs can have negative consequences. The evidence is, at this time, overwhelmingly in favor of not displaying module tabs to clients for suspended services. If at such time a case can be made for modules rendering management features for suspended services, then it would make sense to address that at that time. Thanks for the feedback!

The 3rd party mod is working for you for the Mollie gateway?

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?