Paul

Support > Staff. Your staff user must be added as a staff member for the ticket system, and assigned to all necessary departments.

Have you guys reached out to OnApp yet? I believe they built the module for our competitor, so with enough requests they may relent into doing it themselves and get it to market sooner. We do want to get an OnApp module out there, but we don't have the dev cycles with all the other things we are working on at the moment.

What you're saying is that when an invoice is manually created, it should work differently than when it's automatically created. I don't like this, because it introduces more complexity into invoice creation, which we want to be as simple as possible. If you think a special case should be made for manually created invoices being delivered immediately if they are set to email, then feel free to open a new feature request thread so we can gauge interest and discuss use cases, and in more detail. Personally I have never had an issue with a little delay in the invoice being sent. It's actually saved me a couple times when I forgot something on the invoice -- a line item, or set the due date incorrectly, etc. In the rare case I want an email to me sent immediately, I uncheck the email box, create the invoice, and then check the box to email it right away to the client on their profile page. Edit: I would actually like an option to "queue" new invoices up for say 15 minutes before they can be delivered. This way, I have a sure-window of 15 minutes (or some other number) where I can make changes to the invoice without worrying about it getting delivered.

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.