Problem/Motivation

Drupal\user\Plugin\views\filter\Name filter provides an autocomplete widget, that searches through existing users.

If this filter is exposed and has a default value, then it fails with the exception next time the settings form of this filter is rendered:
InvalidArgumentException: The #default_value property has to be an entity object or an array of entity objects. in Drupal\Core\Entity\Element\EntityAutocomplete::valueCallback() (line 114 of /var/www/docroot/core/lib/Drupal/Core/Entity/Element/EntityAutocomplete.php).

Here is the code:

$default_value = EntityAutocomplete::getEntityLabels($users);
$form['value'] = [
  '#type' => 'entity_autocomplete',
  '#title' => $this->t('Usernames'),
   '#description' => $this->t('Enter a comma separated list of user names.'),
   '#target_type' => 'user',
   '#tags' => TRUE,
   '#default_value' => $default_value,
   '#process_default_value' => $this->isExposed(),
];

If '#process_default_value' property is TRUE, then EntityAutocomplete::valueCallback() will call EntityAutocomplete::getEntityLabels(), but we don't need it because we already call EntityAutocomplete::getEntityLabels($users) right there.

#process_default_value was false before and was changed here #2718697: EntityAutocomplete element cannot handle GET input values, but I don't really see why.

Steps to reproduce

  1. Install Drupal with Standard profile;
  2. Edit default content view (/admin/structure/views/view/content);
  3. Set some default value for "Authored by" filter (e.g. admin) and click "Apply";
  4. Try open the same filter again -> face the issue;

Proposed resolution

Revert '#process_default_value' back to permanent FALSE.

Besides, Drupal\taxonomy\Plugin\views\filter\TaxonomyIndexTid already does that. See: https://git.drupalcode.org/project/drupal/-/blob/9.3.x/core/modules/taxo...

Remaining tasks

1) Make test-only patch/commit;
2) Submit one-line fix;

Issue fork drupal-3250352

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

Matroskeen created an issue. See original summary.

Matroskeen opened merge request !1429

matroskeen’s picture

matroskeen
Primary language Ukrainian
Location 🇺🇦 Ukraine, Lutsk
commented
Status: Active » Needs review
lendude’s picture

lendude
Primary language Dutch
Location Amsterdam
commented
Status: Needs review » Needs work

Nice one.

Also took a look at the issue where this got changed, and yeah I agree there doesn't seem to be a good reason for this, so changing it back sounds good, since it doesn't seem to break anything.

I would like to see the test coverage expanded a bit though because ideally we have some assertions about what we expect to see after pressing the apply button. The existing test coverage gives a bad example here, because it finishes with a negative assertion and not with a positive one about what we expect to see (i.e. the result of the first press of apply could be a WSOD and the original test would be green, this is not what we want).

So just an assertion that the page renders what we want should do here I think.

matroskeen’s picture

matroskeen
Primary language Ukrainian
Location 🇺🇦 Ukraine, Lutsk
commented
Status: Needs work » Closed (duplicate)
Related issues: +#2920039: Views' User Name exposed group filter validation

Yeah, I agree that the test here is not good enough. I noticed that tests in #2920039: Views' User Name exposed group filter validation won't pass without this change, so I suggest we fix it there. It already has better test coverage, because it makes some assertions after the default value is already set.

I'm closing this one and welcome you to take a look into #2920039: Views' User Name exposed group filter validation.
Cheers!