Allow adding indirect fields/properties in aggregate_fields processor

Created on 23 March 2016, almost 9 years ago
Updated 7 June 2024, 9 months ago

In the Aggregated fields processor the help text says:

This processor lets you define additional fields that will be added to this index. Each of these new fields will be an aggregation of one or more existing fields.

However, additional fields defined in the Fields section of the index are not available.

There are several options to achieve being able to add more properties/fields to the aggregate processor: Create a UI similar as the adding of fields so one can drill down the different entities; Create a text box to enter the field/property path (not great UX); Or add the added fields from the index to the list of options.

Adding the fields on the index to the options in the processor would probably be a good compromise.

Feature request
Status

Needs review

Version

1.0

Component

Plugins

Created by

🇨🇭Switzerland bircher 🇨🇿

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇺🇸United States potassiumchloride

    Getting this functionality into the UI would be really helpful for folks who want to aggregate entity reference field values (not IDs) for display in views or for use as facets. If editing the config file is the only way to do this, then can we get some new documentation that specifically outlines where to find the correct config file and how to edit it?

  • 🇬🇧United Kingdom alfaguru

    @drunken-monkey, I was just looking at this and most of the time I would imagine that the nested properties in question are defined as fields in their own right, so once the properties have been gathered in the first pass, something like this should do the trick:

    <?php
        foreach ($index->getFields() as $field) {
          if (!isset($form['fields'][$field->getCombinedPropertyPath()])) {
            $field_options[$field->getCombinedPropertyPath()] = $field->getLabel();
          }
        }
    
    ?>

    Then the hack to avoid removing nested fields can be dropped.

    I am sure there are some subtleties to be observed but it seems to meet the immediate needs for my project.

  • 🇬🇧United Kingdom alfaguru

    Patch attached.

  • 🇧🇾Belarus VasiliyRepin Minsk

    #31 patch works fine in my case for Product Default Variation Price & Variation Price union price (Product + Product Variation entities in one table).
    Thank u!

  • Open in Jenkins → Open on Drupal.org →
    Core: 10.1.4 + Environment: PHP 8.1 & MySQL 5.7
    last update 10 months ago
    Patch Failed to Apply
  • 🇦🇹Austria drunken monkey Vienna, Austria

    Thanks for the patch, @alfaguru, and thanks for reporting back, @VasiliyRepin!

    Adding explicit options for all indexed fields indeed seems like a relatively easy solution that might help some people. I would however doubt that most people have those properties they want to aggregate indexed as individual fields, too. In a lot of cases, this wouldn’t make much sense.
    Anyways, it’s a very small addition, so as long as it helps some people I don’t really see a reason against it. However, it’s important we don’t cause a regression here by removing the code dealing with already selected fields.

    I created an MR with your patch and added some changes by me (in a separate commit), adding comments and reverting the removal of the existing code avoiding silently deleting config.

  • Status changed to Needs review 9 months ago
  • 🇺🇸United States fskreuz

    Patch in #31 works, with one minor issue: If you're indexing a field more than once (same Path, different Machine Name and Type), since the options are keyed by path, only the label of the last duplicate is used.

    The use case I have is that we use a single index for multiple search views.
    - A location-only search:
    - A geofield field is indexed as a "Latitude/Longitude" type for proximity search.
    - The same geofield field is also indexed as "Storage Only" for rendering in Leaflet maps (Leaflet doesn't render the previous type).
    - A multi-type site search with location search in the advanced section:
    - Aggregates several geofields into one "Latitude/Longitude" type for proximity search.

    When choosing which fields to aggregate, the aggregate options only show the "Storage Only" geofield because it's the last one found.

    Could just be a presentation/help text thing. Otherwise, looks good to me.

  • 🇦🇹Austria drunken monkey Vienna, Austria

    Thanks for reporting back, good to hear!
    The problem with multiple fields for the same property seems like a very niche case, and also entirely a matter of presentation. It’s only the property that’s actually used, the field of which the label is used is irrelevant. I’d therefore not try to fix this minor detail.

    Does anyone else still want to give feedback?
    Please do use the changes in the MR for testing, though, not the patch in #31, as that is what I’d merge. If you need a patch, you can get it by clicking “plain diff” at the top.

  • 🇬🇧United Kingdom joachim

    Something that might be of interest is that I've just made a module that combined identically-named fields from different datasources. Unlike aggregation, you pick just one field name in the UI.

    The use case is that I have some content entity datasources but also some Date Recur occurrences from event nodes (another module I'm working on, based roughly on this sandbox: https://www.drupal.org/sandbox/sam/3200275 )

  • 🇬🇧United Kingdom joachim

    I've released the module I mentioned: https://www.drupal.org/project/search_api_common_field

    Same sort of idea as aggregated fields, but merges matching fields on different sources so it's a clearer UI for that use case.

Production build 0.71.5 2024