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
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
QuoteTo 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.
QuoteNormally 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.
QuoteWhat 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.
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
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.
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?
are you upgraded from old vesrion with automatically upgrade (JMigrator) or manually, or is the new shop?
@pinochico
Quoteare 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.
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
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
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
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
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?
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
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.
OK, i have mixed your numbers in my head. All the autoincrement values seem ok, let alone you have a little hole in the orders table, but please check joomla user table to.
A user only creates items in the order_userinfos table. BT and sometimes also ST address entries with user_id 0.
Are you sure that there ha been only 2823 orders since 2012 and only 563 registered users ?
Have You deleted orders or users in the past ? This could maybe explain this.
Have You migrated the joomla site, with a migration tool?
Check to see if You have user entries "virtuemart_user_id" in any of the tables that do not correspond to the actual user_id table. e.g user_id == 705. This could mean that you have deleted users in the wrong way and are starting new with user_id that have been already taken.
What are the highest user id in the order_userinfo table ? and what are the latest user_id ?
I wish I could say that there is an easy way to clean up this mess, but all solutions I see involve some detective skills to see the results.
Jörgen @ Kreativ Fotografi
Such detective work is rather cumbersome.
MySQL Workbench can be a usefull tool to get an overview about dependancies of tables. It can show you which field in which table depends on which field in another table (referential integrity, 1:n, m:n and so on).
To fix such problems I would export whole DB of installation and import it to a separate local DB. With one eye on structure I would check values in related tables and make notes about how to fix it. Chance is hight to detect more errors not being visible at the moment in live system. When those fixes work local I would sync data with online system.
Be very carefull with this synchonization (double check both DBs before changing something in live system!!) and take care of new entries in live system in case you didn't set it in maintenance mode!
Be aware of the fact that autoincremented values are unique but not necessary higher than existing edit: values max value in case something has been deleted! One "hickup" of DB at deletion will break integrity without stopping deletion of an important value - you will get such "leaks" in sequence and wrong results afterwards like you have it now.
cu, diri