Account created on 26 April 2007, almost 18 years ago
#

Merge Requests

Recent comments

🇳🇱Netherlands ericmulder1980

@dydave,

Thank you so much for looking into this. I agree that there are already a few warnings in place and that it is the site maintainers responsibility to check these. For many contributed modules this doesn't have a fatal impact as removing them as a whole from the codebase is also a decision often made by or in collaboration with a site maintainer.

As this is a submodule of a very popular contrib module i do feel that this is something that could be overlooked. As you mentioned the impact on the codebase is minimal and it could prevent fatal errors for lots of users.

Not sure how much response this will get as most people will only go to the issue queue once they indeed have encountered an issue. Let's see what happens.

🇳🇱Netherlands ericmulder1980

@dewancodes i can't accept my own merge request. It needs to be reviewed by the community and the module maintainer then chooses to merge this into develop.

🇳🇱Netherlands ericmulder1980

I see this is also addressed in the patch supplied in https://www.drupal.org/project/domain_language/issues/3388388 🐛 DomainLanguageOverrider::__construct(): Argument #1 ($current_user) must be of type AccountProxyInterface Active . If that patch is committed, this issue can be closed.

🇳🇱Netherlands ericmulder1980

sometimes i wish i would have chosen another profession ..... re-uploading correct patch with changes to use statement.

🇳🇱Netherlands ericmulder1980

Forgot that PHPStorm still isn't able to produce properly formatted patch files. Uploading new file.

🇳🇱Netherlands ericmulder1980

@strkaizer Ok, thanks for your response.

I am willing to put some time into this but as i don't consider myself the best php developer out there perhaps you can give me some pointers for the general direction on how to get this started?

🇳🇱Netherlands ericmulder1980

The same thing applies to the Combine facets processor.

🇳🇱Netherlands ericmulder1980

Fixed some coding standards.

Also i have a question about the version the hook_update is targeting. Issue #3463291 📌 Deprecate the admin_toolbar_links_access_filter module Active mentions the Admin Toolbar Links Access Filter module is obsolute since the Drupal core issue has been fixed in version 10.2. Then, why do we target the update for 10.3 and above?

🇳🇱Netherlands ericmulder1980

Agree with the above, this needs to be addressed in another way. Perhaps it's even best to put this in a seperate issue.

Postponing the update by adding an early return will cause issues with upcoming update, so not really an option. I think the best way to inform site maintainers about this issue is to add a status message to the admin/reports/status page. The context would be when the installed version of Drupal Core >= 10.3 and the modules are still active.

🇳🇱Netherlands ericmulder1980

Well it took us 5 years to get to this point. I would suggest we first fix a broken system before we try to improve it. Currently the redirect Url in 3.x is based on the following logic. I really don't want to create a new issue for the 3.x branch so i changed the version of this issue.

  1. If you have view access to the Group Relationship Entity (which is configured in the Group type permissions : View individual group members) you are redirected to the Group relationship entity. This is very confusing for the actual visitors of a website that uses the Group module.
  2. If you have view access to the Entity related to the Group Relationship (which is the user that created the relationship) you will be redirected to the user page.
  3. If you have view access to the Group related to the Group Relationship (which you generally should have since you became a member) you will be redirected to the group page.
  4. If all else fails we will send you to the frontpage

So the default behaviour is that you will probably never be redirected to the group page. I can't really see a business case where you would not have the "View individual group members" permission OR where you don't have the permission to view your own user page. This logic works very well if you add a node or other entity relation to a group but not for group memberships.

We can turn this issue into a massive change with configurable redirect paths per group type but that will only further delay the solution of this issue. I think for now we need to make a special flow when we are adding a group membership relation. For all other entity types we can keep the logic as is.

Please check attached patch for the 3.x version.

Production build 0.71.5 2024