Bug: Updating user details corrupts the vendor_id

[doorknob]

This is a nasty little bug because it can cause unexpected results just about anywhere.

The problem:
From the VM menu, select Admin/Users. Select a user to edit. The Add/Update User Information form is shown. On the second tab (Shopper Information), the vendor selection control is set to select the first vendor in the list alphabetically, rather than the entry that corresponds with the current value. When the user record is saved, the vendor first in the list becomes that users default vendor (recorded in the #__{vm}_auth_user_vendor table).

The cause:
The query that populates the Add/Update User Information form does not exdtract any details from the #__{vm}_auth_user_vendor table and so when the vendor list control is created, it is not supplied with the current value.

The failure to set a default value for the vendor_id should also be regarded as a separate bug. I have modified my product.product_form program to set a default vendor_id value when adding a new product ($session default). I believe that this should also be done here when the vendor_id is null or zero.

I replaced line 361 of admin.user_form with:

Code Select Expand

        <td><?php
$vendor_id = $db->f("vendor_id");
$vendor_id = ( empty($vendor_id) ) ? $_SESSION["ps_vendor_id"] : $vendor_id;
ps_vendor::list_vendor($vendor_id);
?></td>

and now user records are saved with the default value (which is all I need)

Regards
Phil

[Milbo]

The whole system is overhauled.

The former programmers mixed multivendor with multistore.
Their thinking,.. a shopper belongs to a vendor
My thinking vendors are connected to shoppers. Best is you comment the whole thing. 1.2 will have a slightly multivendor support.

Milbo (dev for multivendor)