Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Thanks
Comment | File | Size | Author |
---|---|---|---|
#12 | uc_addresses7-user-based-views-1908904-12.patch | 704 bytes | MegaChriz |
#9 | uc_addresses6-user-based-views-1908904-9.patch | 843 bytes | MegaChriz |
#3 | uc_addresses-user-based-views-1908904-3.patch | 443 bytes | MegaChriz |
Comments
Comment #1
MegaChriz CreditAttribution: MegaChriz commentedI 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?
Comment #2
jvieille CreditAttribution: jvieille commentedI 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.
Comment #3
MegaChriz CreditAttribution: MegaChriz commentedThanks. 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.
Comment #4
MegaChriz CreditAttribution: MegaChriz commentedOops, forgot to post the two different implementations here.
Implementation #1:
Address fields are directly available.
Implementation #2:
A relationship needs to be added before the address field are available. Works with Views 3, but not with Views 2.
Comment #5
jvieille CreditAttribution: jvieille commentedThanks!
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....
Comment #6
MegaChriz CreditAttribution: MegaChriz commentedTrue 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!
Comment #7
jvieille CreditAttribution: jvieille commentedI 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.
Thanks!
Comment #8
jvieille CreditAttribution: jvieille commentedWhat is missing is the country (and zone) information.
We only get the country id.
Thanks for complementing this important feature.
Comment #9
MegaChriz CreditAttribution: MegaChriz commentedThanks 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.
Comment #10
jvieille CreditAttribution: jvieille commentedPerfect!
Thanks
Comment #11
MegaChriz CreditAttribution: MegaChriz commentedThanks for reporting back! Committed #9.
Needs porting to the 7.x-1.x version.
Comment #12
MegaChriz CreditAttribution: MegaChriz commentedPatch 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).
Comment #13
MegaChriz CreditAttribution: MegaChriz commentedCommitted #12.
Comment #15
jvieille CreditAttribution: jvieille commentedResuming this old issue: extra fields do not show up in Views.
Help appreciated