Add config actions for views

Should this issue be moved to Drupal project?

Uploading patch to use in Drupal CMS for config actions on views, that need to add/remove/update filters/fields and other options of the display.

WRONG PATCH

The MR contains 3 new config actions for view entity type:

1. setDisplayOption - allows to set a display option like filters, fields, pager, etc .
Parameters:
option (required) - the name of the option to manage, can be filters, fields, pager, etc (any option that view display can have)
settings (required) - the option settings. This varies from option type.
display_id (optional) - the display id, if non is provided the default is used.
override (optional, default FALSE) - allows to override the display option (make it only for the current display)
Example usage:

view.view.my_view:
  setDisplayOption:
    display_id: default
    option: pager
    settings:
      type: mini
      options:
        offset: 0
        pagination_heading_level: h4
        items_per_page: 10
        total_pages: null
        id: 0
        tags:
          next: ››
          previous: ‹‹
        expose:
          items_per_page: false
          items_per_page_label: 'Items per page'
          items_per_page_options: '5, 10, 25, 50'
          items_per_page_options_all: false
          items_per_page_options_all_label: '- All -'
          offset: false
          offset_label: Offset

2. addItemToDisplayOption allows to add the item to views display option. The difference from setDisplayOption is that the existing option settings are preserved and only the new item is added to the option settings.
Parameters:
The same as for setDisplayOption, plus:
item (required) - for the name of the item to add.
allow_update (optional, default to FALSE) - if it is set to TRUE the existing item will be updated, if set to FALSE - the exception will be thrown with message that item already exists.
Example usage:

    views.view.drupal_cms_search:
      addItemToDisplayOption:
        display_id: default
        option: filters
        item: facets_type
        settings:
          id: facets_type
          table: search_api_index_drupal_cms
          field: facets_type
          relationship: none
          group_type: group
          admin_label: ''
          plugin_id: facets_filter
          operator: '='
          value: ''
          group: 1
          exposed: true
          expose:
            operator_id: ''
            label: 'Content type'
            description: ''
            use_operator: false
            operator: ''
            operator_limit_selection: false
            operator_list: { }
            identifier: type
            required: false
            multiple: true
            remember_roles:
              authenticated: authenticated
          is_grouped: false
          group_info:
            label: ''
            description: ''
            identifier: ''
            optional: true
            widget: select
            multiple: false
            remember: false
            default_group: All
            default_group_multiple: { }
            group_items: { }
          hierarchy: false
          label_display: visible
          facet:
            query_operator: or
            min_count: 1
            show_numbers: true
            processor_configs:
              translate_entity:
                weights:
                  build: 5
                settings: { }

3. removeItemFromDisplayOption allows to remove the item from views display option.
Parameters:
The same as for addItemToDisplayOption, minus one settings as it is not needed for item that is removed.
Example usage:

    views.view.drupal_cms_search:
      removeItemFromDisplayOption:
        display_id: default
        option: filters
        item: facets_type

I have also exposed 2 methods from view entity class: addDisplay and duplicateDisplayAsType as Action Methods to use as config actions.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

There are some tests with blocks that are failing, I assume not related to the tests form MR.

Looks like it was just a fluke. Rerunning the pipeline resolved the failing test issue.

Hi,
Please add steps to reproduce to test.

For testing you need to create a recipe and use the config actions from comment https://www.drupal.org/project/drupal/issues/3305859#comment-15847932 . The MR also contains tests, you can follow them as well.

This is a Drupal CMS stable release blocker for the search filters recipe #3488715: Add recipe for search facets, as we don't want any patch. I think that's an optional recipe, so might be just "Drupal CMS release target" instead. Feel free to recategorize.

This does not block a stable release of Drupal CMS; the MR you referenced will not be in Drupal CMS 1.0.0, because it couldn't land before the RC1 deadline due to its reliance on this patch.

Reviewed. I think this is a reasonable start but I would suggest cutting back the scope ("remove" is a hard thing to get committed, and it's not clear how necessary/useful that is here) and greatly improving the documentation/examples to make it clear how to actually use these actions. Views are utterly inscrutable for many reasons, and we want to make sure it's plain as day how these actions are meant to be used.

I have removed config action that removes display option items from MR. I have also combined setDisplayOption with addItemToDisplayOption config actions. Here is the updated usage documentation:

setDisplayOption config action has following parameters:

option (required) - the name of the option to manage, can be filters, fields, pager, etc (any option that view display can have)
settings (required) - the option settings. This varies from option type.
display_id (optional) - the display id, if non is provided the default is used.
override (optional, default FALSE) - allows to override the display option (make it only for the current display)
item (optional) - in case of fields and filters, it is possible to add/update the individual field/filter providing the name of the field/filter here. The settings parameter will be applied to this individual item instead of the display option itself.
allow_update (optional, default TRUE) - this is optional parameter to forbid of field/filter (individual item of a display option) update in case the item already exists in a view.

Example usage:

1. Change the pager

view.view.my_view:
  setDisplayOption:
    display_id: default
    option: pager
    settings:
      type: mini
      options:
        offset: 0
        pagination_heading_level: h4
        items_per_page: 10
        total_pages: null
        id: 0
        tags:
          next: ››
          previous: ‹‹
        expose:
          items_per_page: false
          items_per_page_label: 'Items per page'
          items_per_page_options: '5, 10, 25, 50'
          items_per_page_options_all: false
          items_per_page_options_all_label: '- All -'
          offset: false
          offset_label: Offset

2. Add a field to a view:

  view.view.my_view:
    setDisplayOption:
      display_id: default
      option: fields
      item: my_field_id
      settings:
         alter:
            alter_text: false
            ellipsis: true
            html: false
            make_link: false
            strip_tags: false
            trim: false
            word_boundary: true
          empty_zero: false
          field: name
          hide_empty: false
          id: name
          table: entity_test
          plugin_id: standard
          entity_type: entity_test
          entity_field: name

3. Add multiple fields:

  view.view.my_view:
    setDisplayOption:
      -
        display_id: default
        option: fields
        item: my_field_id
        settings:
           alter:
              alter_text: false
              ellipsis: true
              html: false
              make_link: false
              strip_tags: false
              trim: false
              word_boundary: true
            empty_zero: false
            field: my_field_id
            hide_empty: false
            id: my_field_id
            table: entity_test
            plugin_id: standard
            entity_type: entity_test
            entity_field: my_field_id
      -
        display_id: default
        option: fields
        item: my_another_field_id
        settings:
           alter:
              alter_text: false
              ellipsis: true
              html: false
              make_link: false
              strip_tags: false
              trim: false
              word_boundary: true
            empty_zero: false
            field: my_another_field_id
            hide_empty: false
            id: my_another_field_id
            table: entity_test
            plugin_id: standard
            entity_type: entity_test
            entity_field: my_another_field_id

This is looking real good

Can issue summary be updated with what's being added. Title is pretty vague.

Also probably need a CR now for the new actions.

I have updated the description of the issue. Are there any examples of how change record for new config action should look like? What should be included? Would content of comment https://www.drupal.org/project/drupal/issues/3305859#comment-15896386 be enough?

Comment #21 is a great start for the change record. In addition, we should also document that you added and how to use addDisplay and duplicateDisplayAsType .

Here is a past example of a change record for a new config action.

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

Change record was added. I have also added the ability to place field/filter after or before defined field/filter for more flexibility

Failed test seems to be unrelated to the changes from this issue.

Attaching also patch for using in composer based projects.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

I have rebased the MR on latest 11.x changes.

Uploading re-rolled patch

Sorry to be that guy be even a task can we use the default template.

I have rebased the merge request and put the issue summary into the template.

MR appears to have problems.