Paul

I can extend or issue you a new trial, just email me at sales, PM me, or open a ticket. No kidding, you did their current site? I guess I always assumed they did it in house. I do all the design for Blesta, the current website and the admin and client UI.

Your tickets require a dev response, will try to get you one tomorrow. If you prefer, you could start a thread on each here, bug reports and feature requests are best suited for the forums so they can be confirmed, vetted, and discussed.

If the "Bill Date" is the same for the paid invoice as the proforma, then setting the "Bill Date" to the date the invoice is created (same time the proforma is paid), does anything else need to change? For example, it would be possible to have a bill date that is after the due date. How should this be handled, what is the proper way of dealing with all invoice dates?

It works with 5.3, they haven't changed the database schema. Modules for which there is a mapping file will be imported using the module in Blesta, however WHMCS's licensing system works so very differently than ours, it's not advised to map them across. You will need to update your code in your software products to work with our licensing. This makes migrating licensing more difficult because you need to: 1. Update your code, so that it works with our licensing system. 2. Issue new license keys in Blesta that can be used for your software products going forward. We have considered offering a new licensing type when adding license module products called "whmcs legacy" or similar, and emulating their licensing system. It hasn't been a high priority, and their licensing system is so bad we wouldn't want people to use it unless they have to. Feel free to give me a call if you want to discuss tomorrow. 714-398-8132 x100. I'm here M-F 8am-4:30pm pacific time. I'm curious what types of products you're licensing. I'm sure your situation is unique, and I may be able to suggest a particular approach.

The license manager is made up of 2 parts: License Manager (plugin): http://docs.blesta.com/display/user/License+Manager License Module: http://docs.blesta.com/display/user/License+Module The license plugin serves as the license server. The module creates licenses. Blesta includes an Import Manager plugin, that allows migrating from WHMCS. See http://docs.blesta.com/display/user/Migrating+to+Blesta The importer should import license services from WHMCS, however they will be imported using the Universal Module. Their method of licensing is not compatible with ours, which is not possible to circumvent without decoding and nulling. It's much better designed overall. You may find this an interesting read - http://www.blesta.com/2012/03/30/blesta-3-0-software-licensing/

All departments except "Staff". Are you sure you are authenticated with that same user? Sometimes people migrate from another system and end up with 2 similarly named staff accounts in Blesta. If the correct one is not assigned to the ticket system, then this can happen. If you are certain that the staff user you are authenticated with, has been added as a staff member for the support system with access to the proper departments.. then I would suggest deleting the staff user in the ticket system, and re-creating it. I can think of no other cases where this is an issue, in all similar reports the issue was that the staff user was not added to the support system or did not have the proper permissions for the department.

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)