Address component Views support

I think this should be done.

+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.

I'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.

Try https://github.com/solotandem/views_field. Not exactly what I need, but it works :)

I 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?

subscribing

To 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:

     if (isset($item['raw']) && is_scalar($item['raw'])) {

by

     if (isset($item['raw']) && is_scalar($item['raw'][$id])) {

(it should be around line 669)

It 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?

I'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).

I 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

subscribing.

What exactly would we be testing for? I applied the patch in #10 but I'm not sure I notice the difference.

@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.

Ok. Tested and confirmed it works. Since this post and #14 appear to be working, setting to reviewed by community.

Patch at #10 works as promised!

+1

I 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.

mrfelton, could you specify what the problems are that need to be addressed?

- 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).

Thanks 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.

Nevertheless 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.

I 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.

I 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

Also reporting that #10 does what we need.

@Drupaldise
Here is a re-roll of the patch that should apply cleanly to the latest dev.

Go to /admin/structure/types/manage/*/display/default and change the display to City; and save. Result:

Warning: Invalid argument supplied for foreach() in addressfield_field_formatter_settings_summary() (line 604 of sites/all/modules/addressfield/addressfield.module).

/**
 * Implements hook_field_formatter_settings_summary().
 */
function addressfield_field_formatter_settings_summary($field, $instance, $view_mode) {
  $display = $instance['display'][$view_mode];
  $settings = $display['settings'];

  $summary = '';

  if ($settings['use_widget_handlers']) {
    return t('Use widget configuration');
  }
  else {
    $summary = array();
    $plugins = addressfield_format_plugins();
    foreach ($settings['format_handlers'] as $handler) { // LINE 604
      $summary[] = $plugins[$handler]['title'];
    }
    return $summary ? implode(', ', $summary) : t('No handler');
  }
}

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

/**
 * Implements hook_field_formatter_info().
 */
function addressfield_field_formatter_info() {
  $data_property_info = addressfield_data_property_info();

  $field_formatter = array();
  $field_formatter['addressfield_default'] = array(
    'label' => t('Default'),
    'field types' => array('addressfield'),
    'settings' => array(
      'use_widget_handlers' => 1,
      'format_handlers' => array('address'),
    ),
  );
  foreach ($data_property_info as $delta => $item) {
    $field_formatter[$delta] = array(
      'label' => t($item['label']),
      'field types' => array('addressfield'),
      'settings' => array(
        'format_handlers' => array(str_replace('_', '-', $delta)),
      ),
    );
  }
  return $field_formatter;
}

I've pulled this code out into a custom module; but here is a patch that takes care of the notice.

Patch #27 looks good. Thanks!

I 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?

Patch #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 ?

Link 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 :-(

Sadly 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

  // A few contries have a well-known list of administrative divisions.
  if ($address['country'] == 'US') {
    $format['locality_block']['administrative_area']['#options'] = array(
      ''   => t('--'),
      'AL' => t('Alabama'),
      'AK' => t('Alaska'),
      'AZ' => t('Arizona'),
      'AR' => t('Arkansas'),
      'CA' => t('California'),
      'CO' => t('Colorado'),
      'CT' => t('Connecticut'),
      'DE' => t('Delaware'),
      'DC' => t('District Of Columbia'),
      'FL' => t('Florida'),
      'GA' => t('Georgia'),
      'HI' => t('Hawaii'),
      'ID' => t('Idaho'),
      'IL' => t('Illinois'),
      'IN' => t('Indiana'),
      'IA' => t('Iowa'),
      'KS' => t('Kansas'),
      'KY' => t('Kentucky'),
      'LA' => t('Louisiana'),
      'ME' => t('Maine'),
      'MD' => t('Maryland'),
      'MA' => t('Massachusetts'),
      'MI' => t('Michigan'),
      'MN' => t('Minnesota'),
      'MS' => t('Mississippi'),
      'MO' => t('Missouri'),
      'MT' => t('Montana'),
      'NE' => t('Nebraska'),
      'NV' => t('Nevada'),
      'NH' => t('New Hampshire'),
      'NJ' => t('New Jersey'),
      'NM' => t('New Mexico'),
      'NY' => t('New York'),
      'NC' => t('North Carolina'),
      'ND' => t('North Dakota'),
      'OH' => t('Ohio'),
      'OK' => t('Oklahoma'),
      'OR' => t('Oregon'),
      'PA' => t('Pennsylvania'),
      'RI' => t('Rhode Island'),
      'SC' => t('South Carolina'),
      'SD' => t('South Dakota'),
      'TN' => t('Tennessee'),
      'TX' => t('Texas'),
      'UT' => t('Utah'),
      'VT' => t('Vermont'),
      'VA' => t('Virginia'),
      'WA' => t('Washington'),
      'WV' => t('West Virginia'),
      'WI' => t('Wisconsin'),
      'WY' => t('Wyoming'),
      ' ' => t('--'),
      'AS' => t('American Samoa'),
      'FM' => t('Federated States of Micronesia'),
      'GU' => t('Guam'),
      'MH' => t('Marshall Islands'),
      'MP' => t('Northern Mariana Islands'),
      'PW' => t('Palau'),
      'PR' => t('Puerto Rico'),
      'VI' => t('Virgin Islands'),
    );

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?

Hmm 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)

Welp 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.

/**
* Implements hook_form_alter().
* @see http://drupal.org/node/1079826 for more information on this code.
* Extending the Products and Services Filter
*/
function HOOK_form_alter(&$form, $form_state, $form_id) {
  if ($form_id == 'views_exposed_form' && $form_state['view']->name == 'YOURVIEWMACHINENAME') {
    
    $form['YOURFILTERFIELDNAME'] = array(
        '#type' => 'select',
        '#options' => array(
              ''   => t('Any'),
              'AL' => t('Alabama'),
              'AK' => t('Alaska'),
              'AZ' => t('Arizona'),
              'AR' => t('Arkansas'),
              'CA' => t('California'),
              'CO' => t('Colorado'),
              'CT' => t('Connecticut'),
              'DE' => t('Delaware'),
              'DC' => t('District Of Columbia'),
              'FL' => t('Florida'),
              'GA' => t('Georgia'),
              'HI' => t('Hawaii'),
              'ID' => t('Idaho'),
              'IL' => t('Illinois'),
              'IN' => t('Indiana'),
              'IA' => t('Iowa'),
              'KS' => t('Kansas'),
              'KY' => t('Kentucky'),
              'LA' => t('Louisiana'),
              'ME' => t('Maine'),
              'MD' => t('Maryland'),
              'MA' => t('Massachusetts'),
              'MI' => t('Michigan'),
              'MN' => t('Minnesota'),
              'MS' => t('Mississippi'),
              'MO' => t('Missouri'),
              'MT' => t('Montana'),
              'NE' => t('Nebraska'),
              'NV' => t('Nevada'),
              'NH' => t('New Hampshire'),
              'NJ' => t('New Jersey'),
              'NM' => t('New Mexico'),
              'NY' => t('New York'),
              'NC' => t('North Carolina'),
              'ND' => t('North Dakota'),
              'OH' => t('Ohio'),
              'OK' => t('Oklahoma'),
              'OR' => t('Oregon'),
              'PA' => t('Pennsylvania'),
              'RI' => t('Rhode Island'),
              'SC' => t('South Carolina'),
              'SD' => t('South Dakota'),
              'TN' => t('Tennessee'),
              'TX' => t('Texas'),
              'UT' => t('Utah'),
              'VT' => t('Vermont'),
              'VA' => t('Virginia'),
              'WA' => t('Washington'),
              'WV' => t('West Virginia'),
              'WI' => t('Wisconsin'),
              'WY' => t('Wyoming'),
              ' ' => t('--'),
              'AS' => t('American Samoa'),
              'FM' => t('Federated States of Micronesia'),
              'GU' => t('Guam'),
              'MH' => t('Marshall Islands'),
              'MP' => t('Northern Mariana Islands'),
              'PW' => t('Palau'),
              'PR' => t('Puerto Rico'),
              'VI' => t('Virgin Islands'),
            ),
    );

  };
}

Works for now.

#27 same here ;)

In 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.

I 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?

This would be a great feature.

Here 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.

And here is again without all my other patches against addressfield applied.

Updated 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.

Tested #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.

PS: 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:

<div class="addressfield-container-inline locality-block country-">
  &nbsp;&nbsp;
  <span class="locality">New Albany</span>
</div>

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.

#10

works great for me. thanks!

#41 works.

I am getting extra whitespaces on the front of city and state using data_export. Where do we trim() the whitespace?

#41 works fine, there are indeed some whitespaces that need to be deleted.

To 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.

Can we make this views support a beta 4 blocker, please?

I'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.

Thanks 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?

Thank you rszrama!

I 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...

Yeah, 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.

@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.

Here's a patch that applies to 7.x-1.0-beta4 and the latest dev.

How 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.

Per 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.

This 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.

@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?

#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.

I 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).

#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.

Here you go

I 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 :-(.

ok, RTBC

#57 works fine.

Made 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:

another pass without the extra set of parenthesis

Looks a lot better from usability side! What about data and subpremise?

Data 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.

Updated patch fixes the #64 and removes 'sub_premise' and useless 'data' fields.

According 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.

Per 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.

@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 :-)

The 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.

Why are you removing my fixes?

@hass sorry in the context of my previous comment I don't understand your question.

You removed my isset() fix. This cannot correct.

Ah. Sorry about that. I'll re-roll.

@hass let me know if this works for you

Not 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.

I 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!

fwiw, 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. ; )

Why not patch the hook_schema implementation to remove the unused fields completely instead of hard coding exceptions in the Views API implementation?

In 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?

Doh. Here's the patch re-rolled relative to the module root against 7.x-1.x-dev.

Patch works great for me and naming of tokens is also a *lot* better than in #27. Let's commit it now.

@rszrama: Are you able to commit this patch, please?

This patch exposes countries as country codes, is there a way to have full country names instead, or as another field?

We'd just have to have a separate handler for it. I believe there's another issue open in the queue to address that.

@rszrama: Are you able to commit this patch, please?

I 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.

I'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.

Im 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?

Hoping 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:

Notice: Undefined index: commerce_customer_address in addressfield_field_views_data() (line 27 of /sites/all/modules/contrib/addressfield/views/addressfield.views.inc).
Notice: Undefined index: commerce_customer_address in addressfield_field_views_data() (line 46 of /sites/all/modules/contrib/addressfield/views/addressfield.views.inc).

At this point I'm willing to pay to get this figured out. Major problem for our current clients.

Im 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).

Does anyone have any clue why i cant get this patches to work? Was hoping my offer for payment would help boost interest.

#90 works well.

#103 works perfectly when applied to 7.x-1.x-dev. Please commit!

There 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.

Group by is not working.

Create a followup case, please.

I'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?

I 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)?

The 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().

@krlucas, are you sure the unset is actually needed?

@dob_, were you testing patch #90?

i did a quick re-test of #90, and the following views options already work.

• group by
• filters
• contextual filters

can someone try using this sandbox to re-test, or post a view where grouping does not work?

screenshot of grouping from #111 sandbox

An interdiff would be good now ;) Cool that you are so fast!

re-attaching #109 w/ its interdiff. still not sure #109 is needed though, per comments in #111

@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.

Here's how to test the "Use aggregation" option between #90 and #109.

1. Apply the patch and clear Drupal caches (the Views' cache in particular).
2. Create a View based on whatever entity you've attached an addressfield to (for instance Commerce Customer Profile).
3. Add two fields to the View, the entity ID (Profile ID) and the addressfield "Administrative Area" (state/province).
4. Enable "Use Aggregation".
5. Under Fields, next to the entity (profile) ID, click "Aggregation Settings". Instead of "Group results together" choose "Count".

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.

@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.

No 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!

I 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)

Fixed a minor typo error: the field config would not export.

Sorry but found some minor things.

1. +++ b/views/addressfield.views.inc
   @@ -22,5 +22,66 @@ function addressfield_field_views_data($field) {
   +
   

   We could remove that empty line.

2. +++ b/views/addressfield.views.inc
   @@ -22,5 +22,66 @@ function addressfield_field_views_data($field) {
   +      // Remove 'additional fields' from the field definition.  We don't
   

   Double space?

3. +++ b/views/addressfield_views_handler_field_country.inc
   @@ -0,0 +1,33 @@
   +      '#title' => t("Display localized human readable country name instead of country code"),
   

   Please use single quotes.

Love 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.

Looks 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.

This patch corrects the fields name:

But the addresses sorted on countries are still sorted by their country code, not the full country name.

Is 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.

Country 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.

True, 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.

I 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.

@colan Your patch didn't apply cleanly on my checkout of 7.x-1.x. Here's a rerolled patch.

Last patch IS incomplete to previous patch.

Oops, sorry. Here's a corrected reroll.

patch 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

Is 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?

Well, 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

Finally! <3

Great news, thanks.

Awesome! Greetings, Martijn

Administrative areas also deserve a handler ;). Development sponsored by nargs.org.

@blazey: Please open a new issue for that (unless there's already one for it). Let's not hijack this closed/fixed one. Thanks.

I 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.

Sorry... the new issue was opened here:

https://www.drupal.org/node/2421211