This is a real bug, that I think should not be hard to fix. Today it happened 3 times, and the only thing we can tell Accounting is to make the same invoice again (hoping this time the uppercase/lowercase id does not clash...).

Are the clashes happening so frequent because the first twenty or so characters of the receipt name are the same??

To clarify the bug:

• The pdf gets generated correctly, and is stored with the correct name in /var/www/html/crater/storage/app/Invoices.
• The correct unique_hash gets stored in the invoices table.
• When clicking on the link (https://example.com/admin/invoices/878/view) in the list of invoices on the Invoices page, the wrong pdf gets shown in the pdf-viewer, if the unique_hash of the internal URL of the correct one has one matches the unique_hash of an older invoice (except for case).
• These pdf URLs can be seen from the pdf window, when clicking on the ... and then select Copy PDF URL (https://example.com/invoices/pdf/8V1DGOqxnY1RxnjNmpYR)
• If an older pdf has the URL with the unique_hash like 8v1dgoQXNy1rXNJnMPyr (case inverted) then it will always be shown in the pdf-viewer (even if only 1 case gets flipped).
• When entering the URL https://example.com/invoices/pdf/8V1DGOqxnY1RxnjNmpYR in the browser's URL bar (or when doing a wget), the wrong pdf gets retrieved, if an older one with a matching unique_hash (except for case) exists.

The bug is where the pdf retrieval function (maybe in Vue?) ignores case, and the match then finds the oldest document that matches.

Thanks for the feedback & suggestion @chestnutbak & @pepa65.

We are using a package called laravel-hashids in order to generate unique ids for the invoices but we noticed just now that it has many repeating characters on the hashids.php file which is causing the issue.

Removing the repeating characters from the configuration should fix the problem. We will also create a new migration in order to update existing invoices with the same unique_hash to fix existing duplicates.

@radhika587 is working on creating a PR for this asap.

But how about the uppercase/lowercase issue? If you use this URL to download an invoice: https://example.com/invoices/pdf/8V1DGOqxnY1RxnjNmpYR you will get https://example.com/invoices/pdf/8V1DGOqxnY1RxnjNmpYr (see the final char) if it is the unique_hash of an earlier pdf.

You an easily confirm this bug by changing the hashid of an older invoice in the database to differ only in case from a newer invoice.

@radhika587 If I patch this by hand, is there anything else I need to do with composer/artisan to make sure it's being applied?

@pepa65 No need to do anything except patching these changes.. but please note that it will not fix or update the old invoices/estimates/payments that are already created.

In order to fix that, we will need to create a separate one-off command or something that will run a query for the duplicate records and regenerate the hash ids for it.

In our case, the accounting department had to issue the invoice, customer waiting, so they generated another one. The "bad" ones just got deleted...