Currently, us_addresses provides a relationship to bring user information in uc_addresses based views.

We also need to get addresses information from based on user id - basically in user based views, or in any situation where the uid is available.

I think that it just need to implement a "uc_address" relationship of the uid to the user table.


#12 uc_addresses7-user-based-views-1908904-12.patch704 bytesMegaChriz
PASSED: [[SimpleTest]]: [MySQL] 3,387 pass(es).
[ View ]
#9 uc_addresses6-user-based-views-1908904-9.patch843 bytesMegaChriz
PASSED: [[SimpleTest]]: [MySQL] 2,331 pass(es).
[ View ]
#3 uc_addresses-user-based-views-1908904-3.patch443 bytesMegaChriz
PASSED: [[SimpleTest]]: [MySQL] 2,300 pass(es).
[ View ]


I agree this could be a great addition, but I don't know out the top of my head how to implement this. Since an user can have multiple addresses, we have a one to many relationship here. Do you know other modules with a one to many relationship with which you can set a relationship on user based views? If so, I could use that as an example and then I would be able to implement this sooner. Maybe the modules Profile 2 or Content Profile?

I just checked Organic Groups that provides to users' based views a relationship " Organic groups: Group node (member)"
A user can be part of several groups as it can have several addresses.
This relationship allows to link the users to OG nodes so it makes possible to display each user with its corresponding groups including any group/node information as we should expect for his addresses.

(OG also offers many OG data directly without making use of relationships, I think it is just about making easier to select information for some people who are not that comfortable with relationship reasoning... providing only this relationship would be sufficient as everything becomes available through a single handler.)

I think Webform does the same with a relationship to the submitted forms of the user.

Status:Active» Needs review
new443 bytes
PASSED: [[SimpleTest]]: [MySQL] 2,300 pass(es).
[ View ]

Thanks. I've looked into the Webforms code and also in Ubercart Views code and saw two possible ways to implement it.
The first implementation (example taken from Ubercart Views) exposes the fields of Ubercart Addresses directly without needing to add a relationship in Views first.
For the second implementation (example taken from Webform), a relationship needs to be added before the fields from Ubercart Addresses will become available. I didn't manage to get this implementation to work with Views 6.x-2.x, so I think it works with Views 3 only.

So, I think it's best to take implementation #1 for the 6.x-2.x version and implementation #2 for the 7.x-1.x version.

Here is a patch for the 6.x-2.x version.

Oops, forgot to post the two different implementations here.

Implementation #1:
Address fields are directly available.

['uc_addresses']['table']['join']['users'] = array(
'left_field' => 'uid',
'field' => 'uid',

Implementation #2:
A relationship needs to be added before the address field are available. Works with Views 3, but not with Views 2.

['users']['uc_addresses'] = array(
'title' => t('Ubercart addresses address'),
'help' => t('Addresses of the given user.'),
'real field' => 'uid',
'relationship' => array(
'base' => 'uc_addresses',
'base field' => 'uid',
'handler' => 'views_handler_relationship',
'label' => t('Ubercart addresses address'),

I'll try it.

The second method shall work in Views 2, it has been done both by Webform and OG - though if one method works in both situation, that's OK. Actually, it is simpler to get the fields directly than through a relationship....

True that it may be simpler to get the fields directly, but it could also possibly lead to confusion when you would make a complex View (for example with using reference fields): to which data this address belongs? I think the second implementation is more explicit.

By the way, did the patch work for you? Did you miss something? Let me know!

Status:Needs review» Reviewed & tested by the community

I agree with relationships being really useful.
This patch did the trick for me, it works as expected.
I don't know if I am entitle for pretending being the community that tested it...
It works in production.


Status:Reviewed & tested by the community» Needs work

What is missing is the country (and zone) information.
We only get the country id.

Thanks for complementing this important feature.

Status:Needs work» Needs review
new843 bytes
PASSED: [[SimpleTest]]: [MySQL] 2,331 pass(es).
[ View ]

Thanks for spotting the missing info about country and zone information! After a bit of puzzling, I manage to add them. I had to explicitly setup a new 'join' from the uc_countries table to the user table, with using 'uc_addresses' as the 'left_table'.

Let me know if this works for you or if something still misses.

Status:Needs review» Reviewed & tested by the community


Version:6.x-2.x-dev» 7.x-1.x-dev
Assigned:Unassigned» MegaChriz
Status:Reviewed & tested by the community» Patch (to be ported)

Thanks for reporting back! Committed #9.

Needs porting to the 7.x-1.x version.

Status:Patch (to be ported)» Needs review
new704 bytes
PASSED: [[SimpleTest]]: [MySQL] 3,387 pass(es).
[ View ]

Patch for the 7.x-1.x version. This implementation requires you to add a relationship in your user based View before the address fields will become available. Apparently, using this approach, the country and zone fields remain: I don't need to give Views extra instructions to expose them again as was the case in the implementation for the 6.x-2.x version (see #9). Note: the 6.x-2.x implementation is still fine as the implementation used for the 7.x-1.x version doesn't seem to work properly with Views 6.x-2.x (as noted in #4).

Status:Needs review» Fixed

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.