-- HikaShop version -- : 3.2.0
-- Joomla version -- : 3.7.5
-- PHP version -- : 7.0.30
-- Browser(s) name and version -- : All Browsers - does not matter
Hello,
I have found a small bug (at least im my ‘system’) that I would loke to report.
I’m reporting in chronological order of the steps that lead to the bug so the real bug is only described in the end!
My Hikashop (currently HikaShop Business 3.2.0 [1709121646]), was migrated from Virtuemart in 2015 (I think with some import tool from Hikashop – can’t remember for sure).
I think because of this for some old (from Virtuemart) entries in table hikashop_address the id in address_user_id field is the user_cms_id and not the user_id (I’m referring to the naming convention of table hikashop_user).
This was not a big problem because:
Addresses with address_published=1 (published) - the ones showing up for selection in front office and backoffice) all had the correct id (user_id from hikashop) and not user_cms_id) in address_user_id, even the ones from that had originated from virtuemart.. I.e. from virtumeart time only some of the not published ones (address_published=0) had the wrong user information.
So I could relate addresses to the correct user according to:
- If address_published=1 relate to the correct user by interpreting hikashop_address.address_user_id as hikashop_user.user_id
- If address_published=0 relate to the correct user by using the information in hikashop_order table , assuming hikashop_order.order_user_id is hikashop_user.user_id (I have not really tested this in deep but for some orders/users with the virtuemart wrong id problem I tested and it was ok to use the order table to relate to the correct user!)
I think this is the way Hikashop does because in backoffice I was never presented with wrong information for customers addresses or orders.
It took me quite some time to understand this, and my interpretation is that for Hikashop from a functional point of view (backoffice / front office) there are two kinds of address entries.
- The ones that have to do with address from the user (published)
- the ones that have to do with addresses from the orders (not published)
I interpreted like this because when creating a new address while placing an order two entries are in fact created in the hikashop_address table:
- one (published) that belongs to the user
- one (not published) that relates to the order (this is only created when the order is finalized )
However!!! I then tried to go to an old order from virtuemart times (one with the problem of the wrong
user_id in the hikashop_address table, and edit the address for the order in the backoffice (for testing purposes I just edited the post code)
. What happened was that a published address (
address_published=1) was created for the wrong user because the new entry created is kind of a ‘duplicate’ of the old one (with the
user_cms_id value in the address_
user_id field) and with the edit made (in the backoffice) to post code. So in the backoffice (and probably in frontoffice) this new address entrey shows up as selectable for the wrong user and also associated with the edited order (for the correct user).
Why have I taken all this steps? I’m trying to clean the site of bad/spam accounts (almost 10K hikashop users and lots of them are fake/spam – before I configured recaptcha), and so I was trying to cross information that could help better identify those fake users – ad the way their boots fill in the address information is revealing). I was going crazy trying to understand why some clearly fake users had legit addresses until I understood I was a mix up because of the records converted from virtuemart and the address_user_id field some times having the wrong info (
user_cms_id and not
user_id ).
If I could correct the wrong
hikashop_address.address_user_id information (from virtuemart times) none of this would be a problem and I would have a cleaner database!
I suspect all the entries with the wrong
hikashop_address.address_user_id information have the
hikashop_address.address_vm_order_info_id filled in (not null) and the other way around, but I’m not sure (this field was surely created by the virtuemart to hikashop import tool). If you could confirm that this is so then I could make a query (very carefully) that for those entries with
hikashop_address.address_vm_order_info_id not null would replace the
hikashop_address.address_user_id value with the correct one by looking up the correct value in
hikashop_user.user_id (i.e look up
hikashop_address.address_user_id =
hikashop_user.user_cms_id and
return hikashop_user.user_id to replace the value back in
hikashop_address.address_user_id).
Could someone from Hikashop help me be sure of this?
Best regards