Problem/Motivation

Views support for list fields was recently fixed. But somehow, that function still skips it for fields that define a callback function.

I just tested it, and in my field, it worked just fine with that function. The ListField filter calls options_allowed_values() that correctly considers that function.

Proposed resolution

Remove that check. Extend tests.

Remaining tasks

User interface changes

API changes

Comments

berdir’s picture

Status: Active » Needs review
StatusFileSize
new716 bytes
dawehner’s picture

+++ b/core/modules/options/options.views.inc
@@ -17,12 +17,6 @@
 
-  $function = $field->getSetting('allowed_values_function');
-  // If this field makes use of dynamic allowed options, we ignore the views
-  // setting.
-  if (!empty($function)) {
-    return $data;
-  }

yeah so now we support dynamic values ... and we just have to hope that they are written in a entity agnostic way,
I guess we don't have any kind of metadata about it.

berdir’s picture

@dawehner: That is the API yes, it must not be relied upon. This is documented in great detail at callback_allowed_values_function()

jhedstrom’s picture

Assigned: Unassigned » jhedstrom

I'll take a stab at a test.

jhedstrom’s picture

Assigned: jhedstrom » Unassigned
StatusFileSize
new2.14 KB
new2.14 KB
new2.86 KB

Here's a test. I extended the OptionsTestBase since that is a unit test rather than a full-blown web test.

The last submitted patch, 5: options-field-views-data-2418155-05-TEST-ONLY.patch, failed testing.

berdir’s picture

Hm, should we maybe use the views data service instead of calling the function directly? maybe the function is renamed or moved to some other place and that would break this test for no good reason? It's a kernel test and not a unit test :)

jhedstrom’s picture

That makes sense--how's this?

berdir’s picture

Issue tags: -Needs tests

Looks good to me, note that #2443485: Remove extension:views cache tag and other views related cache improvements should remove the need for the manual ->clear().

I guess we should wait for that to land, update it and then maybe @dawehner can confirm that it is fine like this?

The last submitted patch, 8: options-field-views-data-2418155-08-TEST-ONLY.patch, failed testing.

jhedstrom’s picture

StatusFileSize
new467 bytes
new2.86 KB
new2.13 KB

Now that #2443485: Remove extension:views cache tag and other views related cache improvements is in, here's the test w/o the manual cache clear.

Status: Needs review » Needs work

The last submitted patch, 11: options-field-views-data-2418155-11-TEST-ONLY.patch, failed testing.

berdir’s picture

Assigned: Unassigned » dawehner
Status: Needs work » Needs review

Looks good to me, but would be good to have an OK from @dawehner.

jibran’s picture

Status: Needs review » Reviewed & tested by the community

Yeah it's good to go.

alexpott’s picture

Status: Reviewed & tested by the community » Needs review

I wouldn't mind @dawehner input either :)

dawehner’s picture

Status: Needs review » Reviewed & tested by the community
+++ b/core/modules/options/options.views.inc
@@ -19,12 +19,6 @@
-  $function = $field->getSetting('allowed_values_function');
-  // If this field makes use of dynamic allowed options, we ignore the views
-  // setting.
-  if (!empty($function)) {
-    return $data;
-  }

Now that you can call options_allowed_values() this is pretty save.

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

This issue is a normal bug fix, and doesn't include any disruptive changes, so it is allowed per https://www.drupal.org/core/beta-changes. Committed 5538c44 and pushed to 8.0.x. Thanks!

  • alexpott committed 5538c44 on 8.0.x
    Issue #2418155 by jhedstrom, Berdir: options_field_views_data() excludes...

Status: Fixed » Closed (fixed)

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