Invoices sent to wrong customer

Hello all. I am a newbie, I deployed this software on a shared VPS. I have set up about 5 clients, several products and then I generated invoices for 2 of my clients. I later then got an email from a client that isn’t the intended recipient. Can anyone explain what happened, is something that we did set up wrong, because at the moment I lost confidence in this software, it is embarrassing for one but most importantly the data on the invoices of other clients has been shared which could be sensitive and confidential.

Version in use: v5.8.35-C156 - Self Hosted.

Things I did before: Had update, health check and had the 2 below cronjobs run every 5 minutes.
/usr/php82/usr/bin/php -d register_argc_argv=On /home/sites/public_html/artisan queue:work --stop-when-empty
/usr/php82/usr/bin/php -d register_argc_argv=On /home/sites/public_html/artisan schedule:run
Things I did after:
I did do a Clear Cache.

I was also considering adding a third cronjob as to my understanding the below does clear a bunch of caches.

/usr/php82/usr/bin/php -d register_argc_argv=On /home/sites/public_html/artisan optimize:clear

Carrying out some research I was only able to find this thread:

[BUG] Invoice sent to wrong client! · Issue #1278 · invoiceninja/invoiceninja · GitHub

I did tried to run the SQL queries shown in the above thread but the output was #1146 - Table ‘invoiceninja-[1333…].invitations’ doesn’t exist .

Not sure if SQL table names changed since 2017 and perhaps this is why but I am hoping to get some answers so this never happens again, this has to be reliable… Thank you!!

Invoices 0006 and 0005 went to Client with number 0006. However they were addressed to 0002 and 0003.


Have you made any manual changes to the database? That was the cause of the problem for the issue linked above.

Hi @hillel. None whatsoever, I followed the guides on the official pages to create it and that was it.

I updated this morning to v5.8.36-C156 and increased PHP memory limit to 4096M however the triangle error near it still there, maybe it would be due to older version of CLI or something. Initially I thought it’s matching the invoice ref’s to the user IDs, invoice 0006 is the same name as user’s 0006 ID that’s why it went there but also 0005 did so that didn’t make sense.


What do you see if you run php -v from the CLI?

php -v

PHP 7.1.33 (cli) (built: Oct 25 2019 01:51:40) ( NTS ) […]

This hoster allows me several versions of PHP that’s why in my cronjobs I used the PHP binaries of newest version available (8.2) at path (/usr/php82/usr/bin/php)

From the UI you can see this as well.

I’m not sure, if you’re able to reproduce the issue feel free to create an issue on GitHub.

Would looking at any logs or specific tables be of any help to troubleshoot? Would you be able to point me in the right direction of what tables should be checked? The previous issue in 2017 was mentioning some duplicate entries or is something that we could do to the database to do a cache clear or clean? Thanks very much.

Sorry, not that I’m aware of.

The previous issue was for the old version of the app, the new version is a complete rewrite.

Thanks. I had a look inside the laravel.log and the only thing I can see this entry mentioned several times:

[previous exception] [object] (PDOException(code: 23000): SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry ‘1-00-1’ for key ‘recurring_invoices_company_id_number_unique’ at /home/sites/public_html/vendor/laravel/framework/src/Illuminate/Database/Connection.php:587)

[2024-03-13 06:20:20] production.INFO: Performing Autobilling 2024-03-13 06:20:20
[2024-03-14 06:20:20] production.INFO: Auto Bill - balance remains to be paid!! - 750.000000
[2024-03-14 06:20:21] production.INFO: Auto Bill - balance remains to be paid!! - 355.680000

These invoices were not the recurring ones, just a one off invoice.

I think in order to test we would have to have some test emails and and remove all our clients/other users from the portal. I will come back with an update if I find the cause. Thanks again

@david do you have any suggestions?

I’m not sure. Without further information it would be tricky to work out what has happened here.

If you inspect the invoice_invitations table. Trace back to the contact->id and inspect that contact and see what the email address is.

Thanks for the suggestions @david .

The first 3 entries point to the email of our company, the last 2 entries appears to be the 0005 and 0006 invoices, they have the correct emails attached to them. So client_id 2 and client_id 3 are the relevant entries. and the invoice_id 15 and 16

Apologies for editing this a couple times, the other entries appear for example 0004_DELETED so they may be older tests that I did to our email. I am happy to provide any information you think would help to find the root issue and fix it as we would like to continue using this software however at this stage I don’t feel trusting enough to use the auto bill or any functionality that sends emails out :expressionless: Thank you all.

Hi @david , @hillel

So I did a Purge and added 4 Test clients, The same products and created them 4 user accounts on totally different mailboxes, I then scheduled 3 invoices for each test user. It appears that all the invoices are echoed to all Users that are active in the user management, they are all getting the invoices.

I created also another user account Test User 4 this is an account in the management section not as a Client, no invoice was also drafted or sent to this user, and this user also received an email when I scheduled an invoice for Test User 2. Notification is: Invoice 0005 was sent to Test User 2 and View below:

So questions are… why are all the users receiving the invoices even if its recipients are set to others, I assume this is a permissions or some kind of option on the portal that is set wrong? Thanks for your time and I hope this makes sense.

If may be of any help, this is the output after invoices were sent and the cronjob was ran:

/usr/php82/usr/bin/php -d register_argc_argv=On /home/sites/public_html/artisan queue:work --stop-when-empty

2024-03-14 15:58:50 App\Jobs\Product\UpdateOrCreateProduct … RUNNING
2024-03-14 15:58:50 App\Jobs\Product\UpdateOrCreateProduct … 75.29ms DONE
2024-03-14 15:58:50 App\Events\Invoice\InvoiceWasCreated … RUNNING
2024-03-14 15:58:50 App\Events\Invoice\InvoiceWasCreated … 15.17ms DONE
2024-03-14 15:58:50 App\Listeners\Invoice\CreateInvoiceActivity … RUNNING
2024-03-14 15:58:52 App\Listeners\Invoice\CreateInvoiceActivity … 1s DONE
2024-03-14 15:58:52 App\Listeners\Invoice\InvoiceCreatedNotification RUNNING
2024-03-14 15:58:52 App\Listeners\Invoice\InvoiceCreatedNotification 76.16ms DONE
2024-03-14 15:58:52 App\Jobs\Product\UpdateOrCreateProduct … RUNNING
2024-03-14 15:58:52 App\Jobs\Product\UpdateOrCreateProduct … 13.63ms DONE
2024-03-14 15:58:52 App\Listeners\Invoice\UpdateInvoiceActivity … RUNNING
2024-03-14 15:58:53 App\Listeners\Invoice\UpdateInvoiceActivity 977.09ms DONE
2024-03-14 15:58:53 App\Jobs\Ledger\ClientLedgerBalanceUpdate … RUNNING
2024-03-14 15:58:53 App\Jobs\Ledger\ClientLedgerBalanceUpdate 103.53ms DONE
2024-03-14 15:58:53 App\Listeners\Invoice\UpdateInvoiceActivity … RUNNING
2024-03-14 15:58:54 App\Listeners\Invoice\UpdateInvoiceActivity 954.78ms DONE
2024-03-14 15:58:54 App\Services\Email\Email … RUNNING
2024-03-14 15:58:59 App\Services\Email\Email … 4s DONE
2024-03-14 15:58:59 App\Listeners\Invoice\InvoiceEmailActivity … RUNNING
2024-03-14 15:58:59 App\Listeners\Invoice\InvoiceEmailActivity 23.85ms DONE
2024-03-14 15:58:59 App\Listeners\Invoice\InvoiceEmailedNotification RUNNING
2024-03-14 15:59:01 App\Listeners\Invoice\InvoiceEmailedNotification 2s DONE
2024-03-14 15:59:01 App\Listeners\Mail\MailSentListener … RUNNING
2024-03-14 15:59:01 App\Listeners\Mail\MailSentListener … 89.74ms DONE
2024-03-14 15:59:01 App\Listeners\Mail\MailSentListener … RUNNING
2024-03-14 15:59:01 App\Listeners\Mail\MailSentListener … 9.19ms DONE
2024-03-14 15:59:01 App\Listeners\Mail\MailSentListener … RUNNING
2024-03-14 15:59:01 App\Listeners\Mail\MailSentListener … 8.61ms DONE
2024-03-14 15:59:01 App\Listeners\Mail\MailSentListener … RUNNING
2024-03-14 15:59:01 App\Listeners\Mail\MailSentListener … 7.63ms DONE
2024-03-14 15:59:01 App\Listeners\Mail\MailSentListener … RUNNING
2024-03-14 15:59:01 App\Listeners\Mail\MailSentListener … 9.28ms DONE

Users can configure which records they receive notifications for in the settings.

Ok so … I found the issue, when you create a user account by default the user settings is set by default so that they receive all the notifications :expressionless: Why…

I think especially for beginners, for safety this should be set to Owned by user by default. Anyways, glad that’s nothing to do with the code, database or something weird. Thanks everyone, I am sure this thread will come in handy for someone new pretty soon unless that option is set by default :slight_smile: Or a Warning message should let the user know prior to creating the user. All the best!