order from different user in the list

[idor]

Hi,
I registered to my VM site creating a test user, not made an order yet, but in the list of my orders I see an order made about two months ago, of a different user.
Joomla 3.9.18 - VirtueMart 3.6.10 10211

[Jörgen]

To little information, existing user, guest checkout etc ? How long was the shop public ? Is the order paid ? Who has ordered ? Who has access ? Normall You should be able to answer this kind of question just examining users and orders. What are you actually asking for?

Normally this kind of strange posts indicates that it origins from a troll or spammer.


Jörgen

[idor]

To little information, existing user, guest checkout etc ? How long was the shop public ? Is the order paid ? Who has ordered ? Who has access ? 

The user is new created (Test User), the order is made from a guest user. The shop is public since 2012. The order is not paid (VM Standard payment, cash-on-delivery)
I have access with the Test-User and didn´t make any order. I only registered, passwrod etc. Though I see in the order list an older order from previous user(UserM) made about 2 months ago. UserM is a guest user. Has no access.

Today investigating the backend, I also found another shopper (UserS) with 2 orders, one is her´s and one made from another user(UserA) (both are registered).
Of course UserA has also the two orders in her list two.

Normally this kind of strange posts indicates that it origins from a troll or spammer.

Maybe you are right. About a month ago or so I saw some registered users with .ru emails, long names and user names about sex
Last visited Date: Never / But I deleted those users from user manager.

What are you actually asking for?

Actually I am asking for help! I am facing a security problem that has to be solved, and don´t know how? I see a miss-matching user/order.

[Jörgen]

OK, I did not really understand your problem.

1. You did a test order.
2. When You checked Your orders, you actually see another order from another user in your list, right?

What are the order id numbers, the database index not ordernumber ? Are they far from each other and are they biggger that the maximum order id in the database ?
The order You made should be at the very end of the current max id number, is it ?

This could point to a broken index in your database. Every new order should start with the max id + 1. If it doesn´t it will overwrite existing data.

Jörgen @ Kreativ Fotografi

[idor]

I created a Test User. Didn´t make an order.
but in the list instead of empty list I see an order made by another user (Guest user).

I the database table xxx_virtuemart_orders
the last virtuemart_order_id  is 623

it starts from 13 There are some missing in the middle also, maybe deleted orders, test orders?

The one I see with my Test User has 563 id.

[idor]

Hi again.
About the second case I found this usefull info:

All data are from xxx_virtuemart_orders

UserA with user id: virtuemart_user_id 2816 had made her own order (virtuemart_order_id 607)
but also sees an order from UserS (=virtuemart_user_id 2816) UserS has made this order virtuemart_order_id 556

UserS used to be registered because I see her name linkable, but cannot find her in shoppers.
I see her name linkable in the order list /backend) and the link goes to UserA´s data.

Ufff... Maybe has to do with deleting users from Joomla User Manager?

[pinochico]

are you upgraded from old vesrion with automatically upgrade (JMigrator) or manually, or is the new shop?

[idor]

@pinochico

are you upgraded from old vesrion with automatically upgrade (JMigrator) or manually, or is the new shop?

It is an Old shop
I update from Joomla 3.9.15 to 3.9.18  Joomla Extension > Manage > update
in a subfolder then I moved the updated version in root floder.

Some other time in the past I had to re-install Latest version of VM in order to update.

[Jörgen]

What is the highest order of in virtuemart_orders?
Deleting Joomla users i probably a bad ideal. I always delete spam users from VM customers. This works as expected.
I Guess that your new index Numbers maybe also are out of phase. Bet Id should always be higher than the biggest index

Jörgen

[Jörgen]

Now I see the issue.

If You say that your user id is 563, this is crazy !

You say last user id is 2816. When a new user is reusing old uses of course old orders.

virtuemart_vmusers should be autoincrement and nothing else, sort by date and by index in dbase and see what you find. You will probably find that You have new users with user id lower than 2816...
This is not good. I am not sure if the dbase tools in vm tools can fix this. Your next user should get 2817 as id. Everything lower than that will create trouble.

Jörgen

[diri]

This is a problem since day 1 of VM:

It depends solely on autoincremented indexes in some tables.

You can never know about the number will be increased in reality. I.e. every deletion in VM tables (be it user, order, category, product, ...) will cause problems in long terms. You only know it is (should be) a unique value.

This is a problem when you try to import a large number of differents products: You have to use very inefficient methods.

A simple rule of thumb at DB design:
As long as you see "select %" there must be something wrong.

cu, diri

[Jörgen]

Hello

Check Your autoincrement value, you will find it for every table in myphpadmin under structure operations. The autoincrementvalue is visible and editable. Make sur it is 1 unit higher than the last used id in the table for vm orders, vm users and joomla user etc. This is very important.

I do not now if You should delete entries that have been placed inside the already used range of ids or if you should carefully move these to safe numbers.

Moving entries will mean that you should note the the autoincrement value and increment the autoincrementvalue with as many entries you want to move. This prevents another new user overwrite your moved values while You move them. There is a short moment where a user can add a new entry and you have saved the new autoincrement value. The move the faulty entries to the new id starting with your noted autoincrementvalue.

You can not use the site as it is right now, because any new registration will srew up your database even more. You will have to analyse your data and try to delete or move entries that are faulty.

But only you can be the judge on what to save and what to delete from the database.

Fixing autoincrement values will not restore faulty entries, but it will prevent new entries from detroying any information in your database. I would check every vm table including the joomla user  tables and make sure that autoincrement values are correct.

Jörgen @ Kreativ Fotografi

[idor]

Hi,

Thank you for your response!
You mean I have to check the fields in the screenshot, right?
If I understand well, in this example the last id is 2822 so I have to change in Operations auto-increment field to 2823, right?

for vm orders, vm users and joomla user. OK I will. Any more tables?


Also I checked and repaired the database in case it can help but I get this
XXX_finder_tokens   The storage engine for the table doesn't support check   
XXX_finder_tokens_aggregate   The storage engine for the table doesn't support check   
Is there something wrong?

[Jörgen]

Hum... You told me the new user id was 563.  2827 is not a problem, you get an unused hole of a couple of id, but that is no problem. Check the joomla user table to see if it is on 564 ? The id may be somehow linked to the Joomla Id. You should not have gotten id 563, you should have gotten 2822 or similar.

Or Did you perhaps make a new Joomla user only ?
Without synchronizing with VM ?

If I was You I would check all tables with autoincremant and see if the last id corresponds to autocrement values, just to be sure.

Jörgen @ Kreativ Fotografi

[idor]

563 is the last order id, in _virtuemart_orders  with auto increment 564 (correct)

2822 is the last vmuser id in table _virtuemart_vmusers  with auto increment 2827 (incorrect but it´s OK?)
the happens for _users table.

I am checking now all tables and auto increment. As I understand its OK if I the autoincrement value is major of the last id, but in no case has to be lower, right?

I am wondering what might have caused this.
I see I have three default shopper groups (with icon star) -default-, -default2- and anonymous
Some users are assigned to default2
Two users (Super Users) are assign to "default" and all other users are not assigned to any group.
Do I have to change it and assign all somehow to one of those?

Also I noticed that when I make an order as a guest, there is no record in shoppers. Is it normal? Doesn´t have to create a shopper with email, address etc and assign it to anonymous group?
In the order list the name of a guest shopper is clickable.