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.
I would be nice to only display certain fields in views, like city for example
Comments
Comment #1
tema CreditAttribution: tema commentedI think this should be done.
Comment #2
scottrouse CreditAttribution: scottrouse commented+1 for this
Being able to create a View just listing the First Name or City from the entire Address entity would be invaluable, IMHO.
Comment #3
rszrama CreditAttribution: rszrama commentedI'm not even sure what is technically possible, but what we're looking for I believe is to make individual address components accessibly by Views. Because of that way it interacts with the Field API, I'm not sure to what extent we can expose individual components without just depending on display formatter settings. However, I think depending on a display formatter limits our ability to filter, sort, group, etc. Will need to get a second opinion on the implementation, but I'd love for this to happen.
Comment #4
tema CreditAttribution: tema commentedTry https://github.com/solotandem/views_field. Not exactly what I need, but it works :)
Comment #5
hairyfro CreditAttribution: hairyfro commentedI was trying to do exactly this in Views. I noticed under "Rewrite Results" that these tokens are available:
[field_address] == Content: Address
[field_address-country] == Raw country
[field_address-administrative_area] == Raw administrative_area
[field_address-sub_administrative_area] == Raw sub_administrative_area
[field_address-locality] == Raw locality
[field_address-dependent_locality] == Raw dependent_locality
[field_address-postal_code] == Raw postal_code
[field_address-thoroughfare] == Raw thoroughfare
[field_address-premise] == Raw premise
[field_address-sub_premise] == Raw sub_premise
[field_address-data] == Raw data
However, if I put in [field_address-country], it just rendered literally "[field_address-country]". If I put in [field_address] it would render the complete address, but that's the default behavior anyway. Any ideas to why the sub-field tokens aren't rendering?
Comment #6
valderama CreditAttribution: valderama commentedsubscribing
Comment #7
guillaumev CreditAttribution: guillaumev commentedTo hairyfro> I had the same problem. It seems however that this a views issue that has been fixed in the dev version. So if you can update to the dev version of views, it should work. However if you can't/are reluctant to do it, go in the file views/modules/field/views_handler_field_field.inc and replace the line:
by
(it should be around line 669)
Comment #8
elly CreditAttribution: elly commentedIt seems like the sub-fields tokens issue in #5 is separate from the issue of exposing the addressfield components to views as filters, arguments, or fields.
I think this would be invaluable and enable me to use this field for a couple of projects that I'm currently (unnecessarily) depending on location module for. Is there any work underway to expose addressfield components to views, or is this a development piece that the maintainer would appreciate some help with? What's the story?
Comment #9
jhedstromI'd also like to see this module have some additional views support. While the default support provided by views is good, there are a few specific components that would benefit from having more specific handlers:
- One can expose the 'administrative area' (province) as a filter, but it is a simple text filter, rather than a drop list
- When displaying country field, the country code is output (because this is all views knows of). It would be nice to be able to output the actual name (this would also apply to provinces).
Comment #10
Hydra CreditAttribution: Hydra commentedI needed the fieldvalues of every field seperated, so I worte a patch, which provides every possible Value to display as a fieldformatter. I'm not sure if this is all right so, but it worked very well for me and extend hisself, if new fields are added to the address module.
I'm not sure if this was the right way to do this :) Wold be happy about feedback, I'm quit new in patching
Comment #11
Hydra CreditAttribution: Hydra commentedComment #12
jessicakoh CreditAttribution: jessicakoh commentedsubscribing.
Comment #13
rickmanelius CreditAttribution: rickmanelius commentedWhat exactly would we be testing for? I applied the patch in #10 but I'm not sure I notice the difference.
Comment #14
sagannotcarl CreditAttribution: sagannotcarl commented@rickmanelius: It took me a little while to figure it out too but in order to use this patch, add the address field to a view and then you will see in the Formatter drop down you will see all of the components of the address (where before it just said Default).
The patch at #10 works for me.
Comment #15
rickmanelius CreditAttribution: rickmanelius commentedOk. Tested and confirmed it works. Since this post and #14 appear to be working, setting to reviewed by community.
Comment #16
Remon CreditAttribution: Remon commentedPatch at #10 works as promised!
Comment #17
webankit CreditAttribution: webankit commented+1
Comment #18
mrfelton CreditAttribution: mrfelton commentedI agree with @jhedstrom - whist this patch is great, and a massive leap forwards, it has some problems which need to be addressed. I want to mark this as 'needs work', since IMO, it does.
Comment #19
Pas-2 CreditAttribution: Pas-2 commentedmrfelton, could you specify what the problems are that need to be addressed?
Comment #20
mrfelton CreditAttribution: mrfelton commentedComment #21
Golem07 CreditAttribution: Golem07 commentedThanks a lot for #10.
I hope this will be added sometime in the future. Making each of the elemens sortable in views would be great as well.
Comment #22
Pas-2 CreditAttribution: Pas-2 commentedNevertheless I think it is a very good start and does exactly what it says it does. I used it for one of my projects and it was giving me what i wanted so thumbs up.
The patch under #10 does what it says it will do and worked fine for me too.
Comment #23
nkschaefer CreditAttribution: nkschaefer commentedI tested the patch and it works just fine. Re: #20, this patch has nothing to do with Views filters; it just provides Field API display formatters that control visual output/display of the fields, which can be used in Views.
The filter functionality you're talking about was created in a totally different place (see http://drupal.org/node/1152760), and you do get a list of countries rather than a free-text field (maybe you're using an old version of the module).
Additionally, full country names are displayed when using the display formatter provided by the patch. It's true that province/state abbreviations are shown rather than full state names, but the way the module is currently written, province abbreviation-to-full name mappings are hidden away in arrays in plugins/format/address.inc, within a function. If we wanted those full names to be available to Views, we'd have to duplicate code by copying/pasting those definitions into a second file, and then we'd be introducing the potential for the two different definitions to fall out of sync. In short, unless/until the module maintainers decide to implement a more standard way of defining province abbreviation-name mappings (like in text files that could be parsed and stored in a cached array), it doesn't make sense to expose that information to Views.
All that other stuff aside, this patch is simple and really helpful, and it works.
Comment #24
bofrost CreditAttribution: bofrost commentedI have also tested the patch and can confirm that the patch works really fine. Thanks for the patch, it is more as useful it is just neccessary!
Please port the patch to 7.x-1.x-dev. Thanks
Comment #25
mikeytown2 CreditAttribution: mikeytown2 commentedAlso reporting that #10 does what we need.
@Drupaldise
Here is a re-roll of the patch that should apply cleanly to the latest dev.
Comment #26
mikeytown2 CreditAttribution: mikeytown2 commentedGo to
/admin/structure/types/manage/*/display/default
and change the display to City; and save. Result:I'll be reading up on http://www.metaltoad.com/blog/drupal-7-tutorial-creating-custom-formatters in terms of fixing this. Right now doing this does fix the notice but then the display type doesn't work
Comment #27
mikeytown2 CreditAttribution: mikeytown2 commentedI've pulled this code out into a custom module; but here is a patch that takes care of the notice.
Comment #28
webflo CreditAttribution: webflo commentedPatch #27 looks good. Thanks!
Comment #29
hass CreditAttribution: hass commentedI tried to add the city address field to a view as field, but I cannot find the field?! I have only found the country under filters, but this does not allow me to display the City as example!? What's wrong?
Comment #30
varshith CreditAttribution: varshith commentedPatch #27 works for me.
I wanted to display the states in US. But they are displaying as state codes(NY, ID etc)
Will it be good to have a select case for "state"(as you have for "country") in the patch and take care of the states handled in address.inc ?
Comment #31
hass CreditAttribution: hass commentedLink this field to the original piece of content is missing in the address fields. I can add the address field to a view, configure the formater, but there is no way to link to the node. Tokens are also not available :-(
Comment #32
emptyvoid CreditAttribution: emptyvoid commentedSadly displaying the administrative_area (aka states) in a filter requires specifying the Country first. Even if you could set a default of one or more countries for scope of the states that should be listed I can't find a method in the address module to directly call the collection.
The options array lives in: addressfield/plugins/format/address.inc
on line 93
The array lives in the addressfield_format_address_generate(&$format, $address, $context = array()) method. However the method returns a multi-dimensional array that is used in the FORM API only in the rendering of the address fields for the address entity. It is not structured as a data object that can be "reused" and referenced elsewhere.
I am considering writing a custom filter for views explicitly for the administrative_area field of the address entity. It is proving to be challenging to learn both the entity, views, and address api framework notation to harness everything just so to have the field filter settings appear and call the proper methods to render the list. The last element required would be a hook to modify? The where clause of the view?
Any recommendations on where I should research or example modules that attempt to accomplish the same thing?
Comment #33
emptyvoid CreditAttribution: emptyvoid commentedHmm maybe the the callback method might help?
CALLBACK_addressfield_format_callback(&$format, $address, $context = array())
So in order to use the callback method I'd have to know of formats available and have an instance of the address entity?
I see that context is totally optional..
But will the format get back what I want?
I think I can pass the target field maybe?
Oh the format is the FORM API array or maybe that depends on the intended render format?
Hmm, maybe I'm just dense but this doesn't seem all that straight forward. (hurumph)
Comment #34
emptyvoid CreditAttribution: emptyvoid commentedWelp I ended up using a custom module.
I added the address_state field to my filters for the view. It displayed a text field.
Next I built a custom module that modified the filter fields for my view and manually added the "states" by changing the textfield to a select then listing the states.
Works for now.
Comment #35
mikeytown2 CreditAttribution: mikeytown2 commented#27 same here ;)
Comment #36
mrfelton CreditAttribution: mrfelton commentedIn http://drupal.org/project/addressfield_tokens they have tokens that output countries and states as their full name, as opposed to the two letter abbreviations that we currently get in Views. Maybe something from there could be leveraged to help enhance the Views support here.
Comment #37
MXTI don't know if may help, but in Location module exists the following function:
location_country_name($country_code)
that returns the Country NAME from Country CODE passed as parameter.
I've used it to resolve this issue: http://drupal.org/node/1542404#comment-6046606
May be Address field can provide something similar?
Comment #38
iwant2fly CreditAttribution: iwant2fly commentedThis would be a great feature.
Comment #39
mrfelton CreditAttribution: mrfelton commentedHere is an updated patch that uses addressfield_generate to render the individual address components - and so the output is the same as the output of addresses elsewhere, instead of only showing the raw data.
Comment #40
mrfelton CreditAttribution: mrfelton commentedAnd here is again without all my other patches against addressfield applied.
Comment #41
mrfelton CreditAttribution: mrfelton commentedUpdated patch fixes some undefined index warnings caused by the fact that country may not always be set now, when using addressfield_generate() to output individual address components.
Comment #42
krlucas CreditAttribution: krlucas commentedTested #41 and it works. Thanks @mrfelton !
Some comments:
-- There's some completely duplicated code in the newly added "default" case that should be reconciled.
-- When adding multiple address field components to a view, it's a pain because when you click "Add" there's only one checkbox for each instance of an Addressfield. It might be friendlier to also expose each separate component of an addressfield instance as Views' field.
Comment #43
xaqroxPS: I wrote the below, worked on it for a while, then found that http://drupal.org/project/addressfield_tokens really does exactly what I was looking for.
I'm using patch #41 to display Locality and Admin. Area in their own fields in a view, and I'm getting two extra spaces prepended to the value, as an anonymous child of the
.locality-block
div (i.e. outside the component<span>
itself).Behold:
Also note that the
country-
class doesn't get a country code since a country is not passed in.I believe that using the default handler for these individual components is the wrong approach. It's made clear in the comments in
plugins/format/address.inc
that it makes the assumption that you want "a simple block format suitable for international shipping". I think a separate handler for individual components would work better.Comment #44
stevenx CreditAttribution: stevenx commented#10
works great for me. thanks!
Comment #45
hellomobe CreditAttribution: hellomobe commented#41 works.
I am getting extra whitespaces on the front of city and state using data_export. Where do we trim() the whitespace?
Comment #46
Cauliflower CreditAttribution: Cauliflower commented#41 works fine, there are indeed some whitespaces that need to be deleted.
Comment #47
kevinquillen CreditAttribution: kevinquillen commentedTo get around the whitespace issue for now, I selected Strip Tags, Remove Whitespace and Rewrite this Field (just select its token). This got rid of whitespace for me.
Comment #48
Anonymous (not verified) CreditAttribution: Anonymous commentedFor me, the patch from #41 causes Ajax errors in the views builder interface every time views tries to load the preview.
Comment #49
Anonymous (not verified) CreditAttribution: Anonymous commentedI take it back. This is happening whether or not I have the patch applied.
Comment #50
hass CreditAttribution: hass commentedCan we make this views support a beta 4 blocker, please?
Comment #51
rszrama CreditAttribution: rszrama commentedI'm currently going through the whole queue to prepare a full release of the module; that will include this, but feature requests still shouldn't be set to critical. : )
Thanks for your help cleaning up the queue, though! I see a lot of you and johnv in here, and it's making my task easier.
Comment #52
hass CreditAttribution: hass commentedThanks a lot for cleaning up and working on a new release. I'm using above patch (I guess #27, need to verify) for nearly one year without troubles. Having it in the module code is an absolutely required feature and does not require us to run DEV permanently :-(. Can you try to take a look into this major feature, please?
Comment #53
yannickooThank you rszrama!
Comment #54
rszrama CreditAttribution: rszrama commentedI don't suppose someone could update the title of this issue and give a small summary? I don't see what the last patch has to do with Views support...
Comment #55
krlucas CreditAttribution: krlucas commentedYeah, I think the problem is that the previous patches seem to provide "Views support" by declaring a field formatter for every field component as opposed to just exposing the components to Views using hook_views_data the way File field (as an example) does.
I don't think the multi-formatter approach has any advantages over the approach in the attached patch but if people want different formatters they should start another issue, not rename this one.
This patch probably needs to be re-rolled.
Comment #56
boabjohn CreditAttribution: boabjohn commented@krlucas: was that patch ready for testing?
I've just tried it on 7.x-1.0-beta4 and got failing hunks:
# patch -p1 < address-components.patch
patching file drupalroot/sites/all/modules/contrib/addressfield/views/addressfield.views.inc
Hunk #1 FAILED at 6.
Hunk #2 FAILED at 22.
2 out of 2 hunks FAILED -- saving rejects to file drupalroot/sites/all/modules/contrib/addressfield/views/addressfield.views.inc.rej
Probably needs to go against the dev version of the module...hmmm.
Comment #57
krlucas CreditAttribution: krlucas commentedHere's a patch that applies to 7.x-1.0-beta4 and the latest dev.
Comment #58
krlucas CreditAttribution: krlucas commentedComment #59
hass CreditAttribution: hass commentedHow can this patches become 1/3 of the last patches? There looks like a lot is missing compared to earlier patches. I'm not sure if this parts have been committed somewhere else.
Comment #60
krlucas CreditAttribution: krlucas commentedPer my comment in #55 this patch provides Views support. The other patches were concerned with formatters. This is a different, more Views-API oriented approach which simply exposes each component as a separate add-able field in Views.
Comment #61
hass CreditAttribution: hass commentedThis is about views support and if there is a patch this can be added together. I'm running #27 in production and don't like to see regressions.
Comment #62
rszrama CreditAttribution: rszrama commented@hass I'm confused... the patch in #27 looks more to do with a field formatter modification than Views module support for address components. Do we need to open a separate issue for whatever that patch does?
Comment #63
bdone CreditAttribution: bdone commented#57 works great. It adds views support for addressfield to filter, sort, and/or use contextual filters of individual addressfield elements, such as "postal_code" or "country". this improves existing views support, which selects only the entire address entity.
I've put together a quick test for those that want to test locally. See: http://drupal.org/sandbox/bdone/1997686 which includes a test feature to demo views support, after #57 is applied. hope it helps.
Comment #64
hass CreditAttribution: hass commentedI have this with the latest patch:
Notice: Undefined index: field_address in addressfield_field_views_data() (Zeile 27 von sites\all\modules\addressfield\views\addressfield.views.inc).
Comment #65
hass CreditAttribution: hass commented#64 may be related to the #27 patch I used in past and may required an update of all my views.
Can someone attach a screenshot of what exactly this patch changes? I don't find the difference between beta4 and this patch. Between #27 and these patch all field formatters are removed.
Comment #66
krlucas CreditAttribution: krlucas commentedHere you go
Comment #67
hass CreditAttribution: hass commentedI guess I found it now.
In a view click Add on fields and select > Fields and every addressfields component is listed. I'm fine with this approach, but need to update every view :-(.
Comment #68
hass CreditAttribution: hass commentedok, RTBC
Comment #69
yannickoo#57 works fine.
Comment #70
bdone CreditAttribution: bdone commentedMade a change that I think helps improve views UI by looking up the label property from address field data structure, versus key in views UI. This prevents the need to know xNAL key/value such as (locality = City/Town) when administering views.
before:
after:
Comment #71
bdone CreditAttribution: bdone commentedanother pass without the extra set of parenthesis
Comment #72
hass CreditAttribution: hass commentedLooks a lot better from usability side! What about data and subpremise?
Comment #73
rszrama CreditAttribution: rszrama commentedData definitely doesn't need to be in there, and as far as I know, Sub-premise isn't used. Not sure if we need it to be in there or not.
Comment #74
hass CreditAttribution: hass commentedUpdated patch fixes the #64 and removes 'sub_premise' and useless 'data' fields.
Comment #75
krlucas CreditAttribution: krlucas commentedAccording to the project page the point of this module was to support xNal. Isn't sub premise a part of that? Seems antithetical to then decide some parts of xNal are useless. In any case sounds like a separate issue that has more to do with schema than with Views.
As for the data field, we could tell Views to use the serialized field handler to make it useful and readable.
Comment #76
hass CreditAttribution: hass commentedPer rszrama this fields are not in use. Once they are - a new patch can show sub premise in views. For now it's only confusing. Name it as you like, please.
Comment #77
krlucas CreditAttribution: krlucas commented@hass please refer to xNal when discussing address field. Ryan is just a dude. Drupal Commerce is only one use case. Blame damien for the ambition :-)
Comment #78
krlucas CreditAttribution: krlucas commentedThe attached patch builds on @bdone's #71 retains all the xNal columns and exposes "data" as a serialized field. While "data" might confuse some people, IMO it's not more or less confusing than the default Views behavior of exposing deltas and what not in the UI. I think we should not make too many assumptions of what schema defined information a Views user would want to work with.
The question of whether to continue to support xNal's more esoteric fields should be put in a separate issue and patches to the schema implementation will be automatically reflected in this patch.
Comment #79
hass CreditAttribution: hass commentedWhy are you removing my fixes?
Comment #80
krlucas CreditAttribution: krlucas commented@hass sorry in the context of my previous comment I don't understand your question.
Comment #81
hass CreditAttribution: hass commentedYou removed my isset() fix. This cannot correct.
Comment #82
krlucas CreditAttribution: krlucas commentedAh. Sorry about that. I'll re-roll.
Comment #83
krlucas CreditAttribution: krlucas commented@hass let me know if this works for you
Comment #84
bdone CreditAttribution: bdone commentedNot able to apply #83 against 7.x-1.x. I've re-rolled and fixed an undefined index notice issue found in testing.
The views_handler_field_serialized did not produce data for that field in manual tests. Unsure about that bit, so leaving status as needs work.
Comment #85
badrange CreditAttribution: badrange commentedI needed to display country name from an address field in a view, and solved this by installing the addressfield_tokens module, and setting the formatter of the address field in the view to "Country".
Bingo!
Comment #86
hass CreditAttribution: hass commentedComment #87
rszrama CreditAttribution: rszrama commentedfwiw, Ryan and Damien are both just dudes, but we're the ones who together decided to "implement a subset of the address elements defined in the xNAL standard." (I'm the only one of us currently maintaining the module / project page, though.) Hence my call above to not include fields that are unused in the Views UI. There's literally no way for data to get into them right now, but as hass recommended, when we have a use case for them we can update both the addressfield widget form code and Views integration code to support them. In the meantime, they'd just be unhelpful noise. ; )
Comment #88
krlucas CreditAttribution: krlucas commentedWhy not patch the hook_schema implementation to remove the unused fields completely instead of hard coding exceptions in the Views API implementation?
Comment #89
krlucas CreditAttribution: krlucas commentedIn any case, here's a patch that "whitelists" the columns currently described on the project page except those marked as "(unused)". This was the only documentation I could find for the "/subset/" of xNal fields the module intends to support.
Note that this whitelist only affects Views' Fields. Without any patch in this queue, Views already exposes the component columns as Filters and Sorts. Should we apply the whitelist to those handlers as well?
Comment #90
krlucas CreditAttribution: krlucas commentedDoh. Here's the patch re-rolled relative to the module root against 7.x-1.x-dev.
Comment #91
hass CreditAttribution: hass commentedPatch works great for me and naming of tokens is also a *lot* better than in #27. Let's commit it now.
Comment #92
hass CreditAttribution: hass commented@rszrama: Are you able to commit this patch, please?
Comment #93
pounardThis patch exposes countries as country codes, is there a way to have full country names instead, or as another field?
Comment #94
rszrama CreditAttribution: rszrama commentedWe'd just have to have a separate handler for it. I believe there's another issue open in the queue to address that.
Comment #95
hass CreditAttribution: hass commented@rszrama: Are you able to commit this patch, please?
Comment #96
rszrama CreditAttribution: rszrama commentedI saw your request above. No need to repeat it, but the mere fact that this is in the queue to be reviewed is enough for me.
Comment #97
hass CreditAttribution: hass commentedI'd just like to get this finally done. It's really a critical missing feature that would be worth to make a release only for this.
Comment #98
Media Crumb CreditAttribution: Media Crumb commentedIm a bit confused by all this. I have a profile 2 field set called Address which is set but after applying the #57 patch i see nothing to expose the full fields to views. Am I missing something here?
Comment #99
Media Crumb CreditAttribution: Media Crumb commentedHoping for some help with a bit more detail. I have Address Field associate with Profile 2 field. I'm trying to create a search user view to help administrators search addresses of users. So I have a Users View set up and pull in profile data via RELATIONSHIPS User: Profile.
This gives me access to the Address Field associated with the user nicely. I've applied patches #84
and #90. I'd expect at this point to see the fields in the view, but nothing changes. What is it that I'm missing from these patched to finally expose these filters??? Any help would be fantastic.
Also when I run the patch agains Beta4 I get:
At this point I'm willing to pay to get this figured out. Major problem for our current clients.
Comment #100
thiago78 CreditAttribution: thiago78 commentedIm just a dude, but I also think there should be a minor release just to update this patch (and settle down the issue once and for all as well).
Comment #101
Media Crumb CreditAttribution: Media Crumb commentedDoes anyone have any clue why i cant get this patches to work? Was hoping my offer for payment would help boost interest.
Comment #102
hass CreditAttribution: hass commented#90 works well.
Comment #103
jdanthinne CreditAttribution: jdanthinne commented#103 works perfectly when applied to 7.x-1.x-dev. Please commit!
Comment #104
lpeabody CreditAttribution: lpeabody commentedThere should be a minor release that implements patch #90. As the module currently stands it's impossible to sort address fields in views by any particular sub-field like state, country, etc...
#90 worked extremely well. Thank you.
Comment #105
dob_ CreditAttribution: dob_ commentedGroup by is not working.
Comment #106
hass CreditAttribution: hass commentedCreate a followup case, please.
Comment #107
rszrama CreditAttribution: rszrama commentedI'm not sure it's irrelevant, though. How significant of a change will it be to support group by on these fields? Is it really a separate issue if there's a bug in the proposed patch?
Comment #108
yannickooI would think that grouping is a must have but I can understand other people saying that this would be a follow-up issue because the Views integration is a must have!
I (and other people) would spend more time on the patch for integrate other features like grouping into it so the commit message could be "Full Views integration" ;) What's about arguments (contextual filter)?
Comment #109
krlucas CreditAttribution: krlucas commentedThe attached patch should fix the group by issue. We were erroneously including all sibling columns in the field definition with the 'additional fields' key.
Sorts, filters and arguments work without this patch by virtue of field_views_field_default_views_data().
Comment #110
bdone CreditAttribution: bdone commented@krlucas, are you sure the unset is actually needed?
Comment #111
bdone CreditAttribution: bdone commented@dob_, were you testing patch #90?
i did a quick re-test of #90, and the following views options already work.
can someone try using this sandbox to re-test, or post a view where grouping does not work?
Comment #112
bdone CreditAttribution: bdone commentedscreenshot of grouping from #111 sandbox
Comment #113
yannickooAn interdiff would be good now ;) Cool that you are so fast!
Comment #114
bdone CreditAttribution: bdone commentedre-attaching #109 w/ its interdiff. still not sure #109 is needed though, per comments in #111
Comment #115
krlucas CreditAttribution: krlucas commented@bdone #109 fixes a problem with the "use aggregation" option in the View (under Advanced) NOT the grouping field functionality (as shown in your screenshot). When we are talking about "group by" we mean the SQL "GROUP BY" clause that the "use aggregation" option relies upon.
Comment #116
krlucas CreditAttribution: krlucas commentedHere's how to test the "Use aggregation" option between #90 and #109.
Expected results:
One and only one row for every Administrative Area. The entity (profile) id field should show the number of unique profiles sharing that Administrative Area, not the actual profile ID.
Also if you have Show Query in Preview enabled in the View settings, with #90, when you add an component Field, you'll see the SQL query SELECT's every component column even if you only selected one. With #109, it should only SELECT the component column(s) you added to Fields.
Comment #117
bdone CreditAttribution: bdone commented@krlucas: thanks for the clarification on which grouping #105 was all about. i was reading that as UI.
manual testing of #114, using aggregation, produced zero issues.
Comment #118
krlucas CreditAttribution: krlucas commentedNo problem @bdone! Sorry for being so back-end focused in my initial description! @rszrama sorry for calling you "just a dude". You're obviously "THE" dude, I just wanted the issue queue to think through the problem without some god-like input. And in the end it looks like that effort backfired! Let me know how I can help move this issue towards committal!
Comment #119
pounardI did a slightly different version, from #114 patch that adds a special field handler for country, allowing the user to display the country localized name instead of the country code (checkbox in field configuration form in views, checked per default). Aside of that, the patch is the very same and working here.
(Sorry I misnamed it, it should be -119)
Comment #120
pounardFixed a minor typo error: the field config would not export.
Comment #121
yannickooSorry but found some minor things.
We could remove that empty line.
Double space?
Please use single quotes.
Comment #122
pounardLove empty lines, they tell you to breath while reading the code :) Aside of that splendid verbal diarhea I'm if anyone wants to fix this please do, I won't, I think it's up to the module maintainer to decide.
Comment #123
xmacinfoLooks like that this is what I am looking for. I am using addressfield, and when sorting the countries, they are sorted by their country code (not full countries name). With this patch I hope to be able to sort by the countries full name.
Comment #124
xmacinfoThis patch corrects the fields name:
But the addresses sorted on countries are still sorted by their country code, not the full country name.
Comment #125
krlucas CreditAttribution: krlucas commentedIs the translated country name stored in the database? If not it would be hard and hack-ey to sort on it, if it's possible at all. I don't think it should hold up this patch. The code format issues in 121 should be fixed though IMO.
Comment #126
xmacinfoCountry names are hard coded, not in the database.
We might need to add (in a new issue, though) a sort column in the database, or add the full country name in the database, or, to keep t() available, create a sort key in the database in addition to the 2-letter code.
It's funny seeing Switzerland sorted with countries names starting with “C” while it should be with “S”. Same thing for other countries that do not share first letters in their name and code.
Comment #127
pounardTrue, for this sort it needs to be in the database, the best method would be to have a table aside for countries and names (possibly one column per language or make the language part of the key) and join onto to sort.
Another method would be to assign a "weight" identifier a (code,language,weight) table, and copy the computed weight as an int field in the field data: this would avoid to duplicate names and make the field database table size explode and cause performance troubles.
Comment #128
colanI couldn't find any extraneous blank lines, but I fixed the other two issues. Let's get this one in, and then focus on sorting or other related things in other issues.
Comment #129
Sheldon Rampton CreditAttribution: Sheldon Rampton commented@colan Your patch didn't apply cleanly on my checkout of 7.x-1.x. Here's a rerolled patch.
Comment #130
hass CreditAttribution: hass commentedLast patch IS incomplete to previous patch.
Comment #131
Sheldon Rampton CreditAttribution: Sheldon Rampton commentedOops, sorry. Here's a corrected reroll.
Comment #132
rich.3po CreditAttribution: rich.3po commentedpatch in #131 works for me(although it didn't apply cleanly)
This issue has been open for a long time - any chance of getting rolled into a release?
thanks
Comment #133
Stomper CreditAttribution: Stomper commentedIs this any different for a use case when the Address Field is a field associated with a taxonomy, which in turn is linked to nodes that are node references?
Comment #134
rszrama CreditAttribution: rszrama commentedWell, folks, this is the most number of people I've ever had to mention in a commit. : P
The last patch seems to be in a very good place, though the setting to display the name vs. the country code was being ignored. I added in a check for that so we only actually swap in the name when specified. Thanks everyone for the long effort here, and sorry it took so long to commit.
Commit: http://drupalcode.org/project/addressfield.git/commitdiff/352063e
Comment #135
yannickooFinally! <3
Comment #136
pounardGreat news, thanks.
Comment #137
Summit CreditAttribution: Summit commentedAwesome! Greetings, Martijn
Comment #139
blazey CreditAttribution: blazey commentedAdministrative areas also deserve a handler ;). Development sponsored by nargs.org.
Comment #140
colan@blazey: Please open a new issue for that (unless there's already one for it). Let's not hijack this closed/fixed one. Thanks.
Comment #141
dtamajon CreditAttribution: dtamajon commentedI have checked this patch in a commerce license view, where the customer needs to view administrative area used in billing profile. When using the patch, I get the next error:<del>SQLSTATE[42S22]: Column not found: 1054 Unknown column 'commerce_customer_profile_field_data_commerce_customer_billing__field_data_commerce_customer_address.field_address_country' in 'field list'</del>
I have ensured to remove fields, clean caches, and add fields again.I will attach this info when @blazey opens the new issue.Comment #142
dtamajon CreditAttribution: dtamajon commentedSorry... the new issue was opened here:
https://www.drupal.org/node/2421211