🇬🇷Greece @vensires

I fell into this issue after these steps:

1. I have created a group type
2. I have created a group based on that type
3. I created a group role "User moderator" as an invidual role
4. I assigned various group permissions to this role (I assume also "individual" permissions)
5. I added members to the group
6. I created a Drupal role "User moderator" to combine this role with the group one (specs changed so I found out I also need this on Drupal level too)
7. I edited the group role and set it as "Insider" combined with the Drupal role
8. When vising /admin/group this error occurred

After all these steps, when I try to reach /admin/group I get the following:

Drupal\flexible_permissions\CalculatedPermissionsScopeException: The calculator "Drupal\group\Access\IndividualGroupPermissionCalculator" returned permissions for scopes other than "individual". in Drupal\flexible_permissions\ChainPermissionCalculator->calculatePermissions() (line 145 of modules/contrib/flexible_permissions/src/ChainPermissionCalculator.php).

Drupal\group\Access\GroupPermissionCalculator->calculateFullPermissions() (Line: 40)
Drupal\group\QueryAccess\GroupQueryAlter->doAlter() (Line: 150)
Drupal\group\QueryAccess\QueryAlterBase->alter() (Line: 336)
group_query_entity_query_alter() (Line: 552)

Thank you everyone for your work! The changes seem working so it's good to be RTBC by me. The only unresolved thread is regarding the `.gitlab-ci.yml` variables.

I just want to add some really kind and gentle pressure on this in order to say that websites using this module (32500+ currently) will not be able to upgrade to Drupal 11 without a stable version containing these changes. Drupal Lenient composer plugin won't solve the problem since we still have the dependency issue coming from the "symfony/mailer": "^5.3 || ^6.0" requirement and Lenient only fixes "drupal/core" requirements.

A possible workaround I have found is to change my composer.json's repositories property to the following, while also adding the diff from the MR as patch of course:

{
            "type": "package",
            "package": {
                "version": "1.4.2",
                "name": "drupal/symfony_mailer",
                "description": "Symfony Mailer",
                "type": "drupal-module",
                "license": "GPL-2.0-or-later",
                "require": {
                    "html2text/html2text": "^4.0.1",
                    "symfony/mailer": "^5.3 || ^6.0 || ^7.1@beta",
                    "tijsverkoyen/css-to-inline-styles": "^2.2"
                },
                "extra": {
                    "drush": {
                        "services": {
                            "drush.services.yml": "^11"
                        }
                    }
                }
            }
        },
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        }

Might this be related to ✨ Enable ajax on-demand loading of sub-trees in the Token help Needs work ?

Considering the fact that there are other issues related like 🐛 Unable to explore tokens Needs work and that Fast Token Browser is not usable in D8 (see #3054481: Port Fast Token Browser to Drupal 8 → ), might it be time for this issue to change to the D8 version? And if we prefer this to still exist as a separate module, then let's focus our efforts there.

I set this as "Needs work" because the patch works but... maybe it works too good. I think I have seen the same behavior in other modules too but at least let's make sure this is intentional! If it is, we can set it as RTBC!

In my scenario, I have a comment field "field_ref_comment" on the message template which targets a specific comment. Using this patch I have the option to reach the node entity targeted by the comment ([message:field_ref_comment:entity:entity]) but I can't explore further the node's tokens since the node tokens are not included anymore. I will have to use a node reference field or use patch from ✨ Allow additional token data to be added to message Needs review .

Using your patch I personally didn't have any issues.
And thank you very much for your detailed updates though it was a solo effort! I really appreciated it!
Setting it as RTBC!

It's been a year I am using the patch in various projects so - now that we have a stable release - it's time I set it as RTBC.

In my case the date format for the storage is Y-m-d (default date field) and we only required d/m/Y for display when editing the node.
If we only use "Alternative input format", the issue exists. If I also set "Date format" to "Y-m-d" the issue is fixed.
So, hiding the "Date format" by itself is not the solution; unless we also set the value behind the date format as "Y-m-d" by default.

I am tempted to change the status to "Outdated" as it really seems fixed in version 3.0 but .

If an alternative input format is used, the issue still occurs. If you also set the Date format to "Y-m-d", then the issue is fixed.
I guessed that much from your last comment and tried it and it worked.

So, do we require a code change or should we just add it to the documentation?

esmoves → credited vensires → .

Based on the previous comments of this thread, I was able to build the following URL processor.

In my case, I wanted that the values from user fields became the default values for facets when entering the page. In some other views though, the default query_string plugin is what I needed. Read the inline comments if you intend to use it. Might require some refactoring for your case.

namespace Drupal\mymodule\Plugin\facets\url_processor;

use Drupal\Core\Cache\UnchangingCacheableDependencyTrait;
use Drupal\Core\Entity\EntityTypeManagerInterface;
use Drupal\facets\Plugin\facets\url_processor\QueryString;
use Drupal\facets\Utility\FacetsUrlGenerator;
use Symfony\Component\EventDispatcher\EventDispatcherInterface;
use Symfony\Component\HttpFoundation\Request;

/**
 * Query string URL processor.
 *
 * @FacetsUrlProcessor(
 *   id = "mymodule_query_string",
 *   label = @Translation("My module query string"),
 *   description = @Translation("Extends the original query string with predefined values")
 * )
 */
class MymoduleQueryString extends QueryString {

  use UnchangingCacheableDependencyTrait;

  /**
   * {@inheritdoc}
   *
   * Since we are operating on the construct function and this gets called for
   * every facet on every page, we have to tamper the query object and then
   * restore it; otherwise facets without default values don't seem to work.
   */
  public function __construct(array $configuration, $plugin_id, $plugin_definition, Request $request, EntityTypeManagerInterface $entity_type_manager, EventDispatcherInterface $eventDispatcher, FacetsUrlGenerator $urlGenerator) {
    // Keep a clone of the original query to restore it later.
    $query = clone $request->query;
    /** @var \Drupal\facets\Entity\Facet $facet */
    $facet = $configuration['facet'];
    if ($facet->getFacetSourceConfig()->getUrlProcessorName() === $plugin_id) {
      $this->alterRequest($request);
    }
    parent::__construct($configuration, $plugin_id, $plugin_definition, $request, $entity_type_manager, $eventDispatcher, $urlGenerator);
    if ($facet->getFacetSourceConfig()->getUrlProcessorName() === $plugin_id) {
      // Restore the original query.
      $request->query = $query;
    }
  }

  /**
   * Alter the request object used by facets.
   *
   * When this function gets called, the default constructor has not yet been
   * called; thus we have to take all the variables we need as arguments instead
   * of relying on $this.
   *
   * @param \Symfony\Component\HttpFoundation\Request $request
   *   The current request object.
   */
  protected function alterRequest(Request $request) {
    // For this static variable to have any performance improvements, you must
    // have big_pipe module turned off. Otherwise, you would require another way
    // of caching due to different requests; maybe using a computed field on the
    // user entity is a possible solution.
    static $facet_parameters = [];
    /** @var \Drupal\user\UserInterface $account */
    $account = \Drupal::entityTypeManager()->getStorage('user')->load(\Drupal::currentUser()->id());
    $query = &$request->query;
    // Allow "?disable_defaults=1" for a "Clear defaults" button to be able to
    // work at this point.
    if ($query->getInt('disable_defaults', 0)) {
      return;
    }

    if (empty($facet_parameters)) {
      $original_query_parameters = $query->all()['f'] ?? [];
      if (empty($original_query_parameters)) {
        $facet_parameters = [];

        // Get user fields...
        if ($account->hasField('field_name_1') && !$account->get('field_name_1')->isEmpty()) {
          foreach ($account->get('field_name_1')->getValue() as $values) {
            $facet_parameters[] = 'facet_alias1:' . $values['target_id'];
          }
        }
        if ($account->hasField('field_name_2') && !$account->get('field_name_2')->isEmpty()) {
          foreach ($account->get('field_name_2')->getValue() as $values) {
            $facet_parameters[] = 'facet_alias2:' . $values['target_id'];
          }
        }
      }
    }

    if (!empty($facet_parameters)) {
      $query->set('f', $facet_parameters);
    }
  }

}

valthebald → credited vensires → .

Thanks for the validation @alfthecat! I'm setting it as RTBC.

Since we have so many validations that #26 works, I set it as RTBC.

I copy the text from the README.md file of the module:

### Usage with Drupal 10.2

For Drupal 10.2, the drupal/remote_stream_wrapper (issue 3437974) patch needs to be removed.
If you require this module in Drupal 10.2 you must unset the patch in your composer.json.\
You can do this with the following command:
```bash
composer config --merge --json "extra.patches-ignore.drupal/media_avportal" '{"drupal/remote_stream_wrapper": {"Drupal 10.3.x only - see media_avportal/README.md for 10.2.x - https://www.drupal.org/project/remote_stream_wrapper/issues/3437974": "https://www.drupal.org/files/issues/2024-06-21/drupal_10_3_deliver_signature_change-3437974-2_0_0-18.patch"}}'
```

Feel free to reopen the ticket if I didn't correctly understand your issue.

I just opened 💬 Offering to co-maintain Remote Stream Wrapper Active in case anyone is interested...
(@apotek, I mentioned you too)

Thank you @cmlara for your hint!

vensires → created an issue.

Count me in @apotek. I don’t know how much help I will be able to offer but I will definitely try.

@platinum1 could you also check it and if it's ok, then set it as RTBC?

Adding a patch targeting 2.0.0. Not to be used but for anyone required to use only stable versions.

I hid the MR to clarify that the patch is the one working. RTBC from me too.

vensires → changed the visibility of the branch 3366135-nulllogger-not-implements to hidden.

Patch working fine for me too!

Rebase done.

esmoves → credited vensires → .

vensires → made their first commit to this issue’s fork.

This is actually a long standing issue and other than turning in into a MR so that we can easily update it with the latest module commits, I don't think this will ever get into core. The main reason is that GROUP_CONCAT() is only valid for MySQL databases. PostreSQL has STRING_AGG() and SQL Server requires some strange stuff to accomplish it.

So, from what I understand, we have only a few options here.

Either implement a solution taking into account the database type, either invoke a hook/event/plugin/something to allow other custom or contrib modules to add their own solutions. Contrib modules are more easy to target a specific database than core.

Since this is a really big issue when first trying to install the module and the patch from #26 actually solves it I set it as "Needs review".

As for the considerations mentioned in #32, I think that it there is something more to address, it should be done in a follow-up issue.
But what do the rest of you believe?

Closing this as duplicate of ✨ Performance problem Needs work .

Both changes described above are addressed in the MR.
Drupal's guidelines also suggest updating *.api.php file but since we don't have one, it's ok as it is.

vensires → made their first commit to this issue’s fork.

@heddn, the patches, the MR and the whole issue in general targets the 2.x version.
I agree that it's not clear if and what is RTBC; I'd rather set it as "Needs review". From what I understand and remember, MR!55 and patch in #23 🐛 Ajax facet adds q and _wrapper_format to the browser URL Needs review are good candidates for committing them.

This is also useful to have in views queries when the base table is the one of Paragraphs.

Thanks for your feedback @redwan-jamous. You are right!
I am setting this as RTBC.

Closing this as working as designed since it's actually Entity Reference Revisions module's issue.
You did well to add it as an issue here though! Thanks!

Patch in #5 works great. I'm setting this as RTBC!

Extra things done:
- Updated the MR to match its changes
- Changed the info.yml file since according to the documentation → the core/once is not available before 9.2.0; this means the new version won't support Drupal 8.8.

Also attaching patch from latest MR diff.

vensires → made their first commit to this issue’s fork.

I opened the two MRs in order to better understand the changes proposed in each one.
It seems that MR!13 is actually in WIP state.
MR!12 on the other hand seems to be the one we should go on with.

(@chrisachrist Don't hesitate to correct me if I'm wrong though)

I still have to validate that MR!12 is really working..

When we first stepped on this issue, we couldn't find out why this is needed since the functionality exists in core. I edit the summary to clarify things for other people too...

Corrected the description of the OpenModalDialogCommand class.

I personally think that this last comment is not related to the issue tackled here unfortunately.

Your issue seems to be that the there are still paragraph entities having as parent ID your host entity which - from a query perspective - is correct. Maybe your solutions lies on the functionality of paragraphs to remove orphaned paragraphs.

I have created a new MR with the changes from #3431221-3: allow form elements to override Chosen library options → but for 4.0.x-dev version.
No further changes exist in my code.

PS: It seems that the tests are failing but I am not sure if they break due to this code or if they were already broken from the past; in the later case we should handle them in a different issue.

vensires → created an issue.

@thanos-ntelis what's the status of this MR? I still see some TODO comments in the code.

vensires → changed the visibility of the branch 3444143-change-webservice-urls to active.

vensires → changed the visibility of the branch 3444143-change-webservice-urls to hidden.

vensires → created an issue.

Is this still valid or is this outdated?

Keeping it as RTBC but, are we sure a composer.lock file should exist?

lauriii → credited vensires → .

From what I checked it seems the changes should break anything in older versions.

vensires → made their first commit to this issue’s fork.

Thanks you for your time on this. Setting as RTBC then, based on your feedback.

I updated the MR13 to better understand the changes from the patch. Needs further testing and review if we are going to use it instead of the patch; just to be sure I did the rebase correctly.

As for the patch provided in #15 🐛 Take the selected filters into account, support multiselect filters and make 'delete all' text translatable Needs review only the {{ options.reset_link.title|t }} troubles me. Can't we avoid it using configuration translation?

So we can hide the other MRs and only keep the MR162 as relevant and working though it's currently marked as draft?

I totally agree that we shouldn't go on with any changes in the code. Just document. And your MR succeeds in this.
So, I set it as RTBC ;)

It's a really small but working change, so if no one else has any objection, I set it as RTBC.

I personally think that if we moved this functionality away, it will be like we deprecate it since it's been here for years and developers expect it to exist by default with the Field Group module.

Unless you do want to deprecate it; that's another discussion...

Link to the slack discussions of that day: https://drupal-el.slack.com/archives/C01GLEXA7DK/p1712747499422099.

vensires → created an issue.

Works fine for me! Setting as RTBC!

Seems fine and working. Setting as RTBC.

Added as default layout plugin "layout_twocol" which is also the one used in tests in core Layout Builder module

I have created all the different issues described as children-issues of this meta.

vensires → created an issue.

vensires → created an issue.

vensires → created an issue.

vensires → created an issue.

vensires → created an issue.