News:

You may pay someone to create your store, or you visit our seminar and become a professional yourself with the silver certification

Main Menu

[vm3.2.4] Shopper information of customer is current logged in user

Started by Doeke Norg, September 12, 2017, 13:18:28 PM

Previous topic - Next topic

Doeke Norg

When I edit a customer in the backend I found that within "additional information" under "Shopper information" the info is my own, instead of the users.
So I see my own username, name and email address.

When ignoring this and saving the current information, an error is thrown "Username in use."

After checking the code, I found that the User Model uses the wrong information to fill these fields.
I did the following update, but I don't know if this will break anything else (in the frontend perhaps).


//administrator/components/com_virtuemart/models/user.php

//function getUserInfoInUserfields
//line 1044
            if ($data->address_type != 'ST') {
                $BTuid = $uid; // <-this isn't used, can be removed here

                $User = JUser::getInstance($data->virtuemart_user_id); //getting the right user according to the userinfos table (via $uid).
               
                $data->name = $User->name;
                $data->email = $User->email;
                $data->username = $User->username;
                $data->address_type = 'BT';

            }


@Milbo, can you check if this doensn't break anything in the frontend? It shouldn't, but you have a greater perspective on the complete code.
Thanks.


Milbo

This problem is solved. Your info below your avatar says you use VirtueMart Version: 3.0.12 ?
Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

Doeke Norg

Quote from: Milbo on September 12, 2017, 21:04:59 PM
This problem is solved. Your info below your avatar says you use VirtueMart Version: 3.0.12 ?

Nah, version 3.2.4 (see subject). So the latest still has this bug. Or do you mean you solved it for the future update?
Removed my info text. thnx.

erhabe


Milbo

I mean that I cannot reproduce it. I need a lot more information about. Here are the different cases, which case is yours?

a) Administrator being mainvendor edits himself.
b) Administrator being mainvendor edits someone else.
c) Administrator being no vendor edits mainvendor
d) Administrator being no vendor edits someone
e) ...

I think it is some right issue and inconsistent behaviour. What is the exact status of your user?
Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

Doeke Norg

Hi Milbo,

Have you looked at the code I send, and the location in user.php? If you read the function it becomes clear.
When a $uid is given to the function, it only ever uses the current logged in user.

I am logged in as Admin, and editing a normal shopper / user. Because i'm logged in as myself, I see my own details in that section. My code above fixes that.
Also, i've checked that it doesn't break frontend compatibilty, because the the code still checks to see if you have the manager rights, or if the current user is the same as the one being edited.

It's not a rights issue, is a reference to the current logged in User, which is only appropriate if the $uid was not given.

erhabe


Milbo

Quote
//function getUserInfoInUserfields
//line 1044

line 947 function function getUserInfoInUserfields

and line 1044 is $prepareUserFields = $userFieldsModel->getUserFields in the next function.

So I think you have some old files.
Should I fix your bug, please support the VirtueMart project and become a member
______________________________________
Extensions approved by the core team: http://extensions.virtuemart.net/

Doeke Norg

So we figured it out. I asked Milbo to help out debugging the problem. We found a small nuance that could be better, but at the end of the day it was my own damned plugin which caused the problem.

Thanks for the help Milbo! Well worth the 30 minute ticket!