🦋 Make order.number and order.reference (a new key) different to avoid competitors to know how many sales you did

[Tirodem]

Currently, orders have 2 id :

• _id : the crypto-UUID used to access /order page
• number : an incremental int32

orders.number is currently used on /order page :

Issue is : with this, as a competitor, I can know how much the shop sells.
We need to avoid that.

Crypto-UUID would be a think, but it's too heavy to be used as an order reference (for support communication, for example).

If we decide for any other chain :

• it shouldn't give any insight about shop sales performances
• full numerical is better (Prestashop, per default, use alphanumerical keys like "WPMLDKIDK" -my last 1001Hobbies order- but it's not really user-friendly), but it's not an obligation
• order.reference should not be usable to retrieve order._id in any way
• no random generation (like some prestashop plugins) should be used, as every order.reference needs to be unique

As a reminder : order.reference should be used for DISPLAY PURPOSE ONLY.
In no way it should impact the whole order process.
It's just meant to be displayed on order from this :

to this :

In that case, I used :

• an epoch unix timestamp : 1702607247
• the order.number last digit : 2 (from 2)
• a random 00-99 value : 99
  to generate 1702607247299

I have the feel that it might be :

• some kind of readable / usable order reference
• something enough related to order context to not be full random
• something with enough randomness + control with order.number last digit to avoid 2 very simultaneous orders to have the same order.reference

[coyotte508]

Do we still need order.number?

[Tirodem]

Not necessarily but can be a good indication for seller I guess.

[coyotte508]

note that there is still the invoice number that is sequential

[Tirodem]

Oh, yes, I forgot that one.
Law oblige to have a chronological numerotation.
But at least you have to pay to have this information, contrarily to the order.
Considering that, I think we can remove this ticket from MVP, as we won't be able to totally hide the information.

[coyotte508]

ok

note that for invoice numbers we can do year-month-number (with number resetting every month)

but it's more complicated to handle in the code

[Tirodem]

Yeap, let's keep that idea on the burner for 2024, with firm legal inputs (and international considerations)