Cody

Does this affect all clients, or just these two you mentioned? The migrator grabs the tbltickets.userid and maps that to the imported client ID. If it was wrong for one client I'd expect it to be wrong for all.

I mentioned a little earlier this is fixed in the next rev.

Nope, even full administrators are assigned to departments in WHMCS, so we'll maintain those settings.

Interesting. I'll look into adding "Administrators" to all departments when imported.

Have you checked the database (support_tickets) table? Only staff members imported from WHMCS are assigned to staff departments, and thus have access to tickets. The user you use to import will not be given access to those departments.

Ticket status is fixed for the next rev. We're working on adding diagnostics, and looking at ways to improve runtime.

For those having issues with ticket status values matching up, what are the results of the following query on your WHMCS db? SELECT status, COUNT(*) AS total FROM tbltickets GROUP BY status Note, the 'total' values don't really matter, but would be good to see in contrast to what's you're seeing in Blesta.

Tickets should come across with an equivalent status as in WHMCS. Here's the mapping, on the left are status values in WHMCS, on the right are their status values in Blesta. If a ticket has a status not listed on the left Blesta marks it as "open". 'Open' => 'open', 'Answered' => 'closed', 'Customer-Reply' => 'awaiting_reply', 'Closed' => 'closed', 'In Progress' => 'in_progress'

WHMCS doesn't properly account for client credits. They can be created without reference to any transactions. Blesta doesn't allow this, so when credits are imported they are inserted as transactions with today's date.

There's no link in WHMCS between the refunded transactions and the original. Refunds appear to be handled simply as negative credits, unless I'm mistaken and WHMCS only uses them for display purposes, not for accounting? I'm seeing something different. Considering the following scenario: An invoice is due for $100. The client pays $50, then $25 is refunded. The new due amount for the invoice is $75. The invoice is still considered unpaid. It would appear to me that if an invoice is "refunded" that means it's considered paid in full. The problem with that there may not be any transactions that make that a true statement. Moreover, taking my example above. If I refund the additional $25, the invoice is now considered "Refunded" even though it still has $100 due. That makes no sense to me.

The issue you have is related to custom client fields. Somehow you have a custom field assigned to a client multiple times in WHMCS (or your client_values table in Blesta is not empty). Try changing line 334 from: $this->local->insert("client_values", $vars); to: $this->local->duplicate("value", "=", $vars['value'])->insert("client_values", $vars);

Try the following. Edit /plugin/import_manager/components/migrators/whmcs/whmcs_migrator.php (line 76): From: $errors[] = $action . ": " . $e->getMessage() . " on line " . $e->getLine(); To: $errors[] = $action . ": " . $e->getMessage() . " " . $e->getTraceAsString(); That should shed a little more light on the issue.

What do you have in your users table and clients tables before running the import? SELECT * FROM users Should only have 1 record. SELECT * FROM clients Should be completely empty. I can assure you it's not a simple as you think.

How do you expect such a case to be handled? What does it mean to "refund" an invoice? Is that equivalent to voiding it?

Just disable all tasks except the apply credits task. [settings] > [Company] > [Automation]. I don't believe any emails are sent for apply open credits, but if you want to be certain, update your mail settings ([settings] > [Company] > [Emails] > [Mail Settings]) to use invalid SMTP info. To be doubly sure no emails go out, disable email templates in [settings] > [Company] > [Emails] > . Also, if you don't feel confident enabling cron tasks you can choose to explicitly run the "applyCredits" task by passing the cron key along to the cron via a GET request: https://yourdomain.com/blesta/cron/applyCredits/?cron_key=YOUR_CRON_KEY

It's supposed to redirect. But the fact that you see no success message, and you're missing data indicates an error is occurring. Make sure you have PHP error reporting enabled, and display errors on. Without an exact copy of your database, or a specific error to look at I can't do anything but guess as to what's going on.

Each password reset email is unique per the user that receives it, and expires after a certain amount of times, so no mass message can be sent and it's generally not a good idea to send such a message if a user isn't expecting to receive it. However, there's no need to change the password imported since it won't work. Instead, users can request a password reset from the login screen.

For support tickets, run the following query, if you have any results the import worked, you just need to set permissions to access the support groups for your currently logged in user (the importer can only set permissions on users it imported): SELECT * FROM `support_tickets` As for services, there won't be any if there was an issue importing packages, and no packages if there was an issue with modules. Are you sure you have PHP error reporting enabled? If you're not seeing a success message the import was definitely not a success.

The PDF invoice templates shipped with Blesta do not display transactions. This is because Blesta, unlike WHMCS, does not allow an invoice to be overpaid. So, what happened was because the transaction for 208.97 would have overpaid the invoice, Blesta prevented that transaction from being applied in full. Instead, what will happen is Blesta will apply as much of that transactions as possible to any open invoices (beginning with oldest unpaid) when the apply credit cron task runs.

It is possible to reveal the original passwords using hashcat, but not something worth even trying. It would be much much easier to update authentication in Blesta to allow WHMCS client passwords to work. /app/models/users.php (line 234) from: elseif (Configure::get("Blesta.auth_legacy_passwords") && $user->password == md5($vars['password'])) { to: elseif (Configure::get("Blesta.auth_legacy_passwords") && ($user->password == md5($vars['password']) || ($parts = explode(":", $user->password) && $parts[0] == md5($parts[1] . $vars['password'])))) {

There's already as task (CORE-468) to allow credits to be used to make purchases and manually apply payment to invoices, scheduled for version 3.2.

Latest version of the migrator is up (b5). You can get it here, direct download here. Changes include: Sets country to US if not set (clients, contacts, payment accounts). Sets first/last name for payment accounts to unknown if not set. Decodes HTML entities. Imports invoice credits as in house credits.

The importer is designed to be run only on a fresh (not previously imported) database. As per the instructions when running the importer, back up your Blesta database first, then import. If you run into errors, restore your database before attempting to run the importer again. There's no need to reinstall, just restore your database. Why are you required to import into a fresh database each time? Because the migrator must map data from WHMCS into Blesta which it does by storing references in memory. If you run the importer more than once then the references created during the first import are not available upon the second run, making it impossible to reconcile that data.

Any error that states "Invalid parameter number: number of bound variables..." is simply caused by the previous error. In your case: That sounds like you tried to import into an already populated database, where a client could not be imported due to it already existing.

You've got to be kidding... WHMCS stores HTML entities in the database?! I wonder how many fields are encoded? Invoice Lines Company Name ??? Maybe we'll just need to decode everything.