🇧🇪Belgium @lobsterr

Great!

I think you are looking for this method 'loadByEntity' :

This an example how you can use it.

$group_relationships = GroupRelationship::loadByEntity($term);

foreach($group_relationships  as $group_relationship) {
   $group = $group_relationship->getGroup();
   if ($group->hasPermission('view group_term:tags entity', $account)) {
       // Do something here.
   }
}

Hi, you need to check if user has permission "view group_term:tags entity" (in this case I have tags taxonomy vocabulary enabled as a plugin in my group type). You can do it like this:

$group->hasPermission('view group_term:tags entity', $account);

The same way you can check any other permissions like edit, delete:

$group->hasPermission('update any group_term:tags entity', $account);

The problem was solved in this ticket 🐛 Last Enabled Menu Item Shows As Expandable with No Children Active . Thank you for reporting

Rollbacked changes to add li element item classes. It solves the issue. Thank you for your contribution

lobsterr → created an issue.

Thanks for info, I will set new requirements in the next release

Thank you for your contribution

lobsterr → created an issue.

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

A new release 3.0.4 also was tagged

Well, probably. it is repo cache issue. I am closing this ticket since it has been fixed in 4.0.4

I just tried to install, everything is fine, clean composer cache too:

Installing dependencies from lock file (including require-dev)
Package operations: 4 installs, 0 updates, 0 removals
  - Downloading drupal/entity (1.6.0)
  - Downloading drupal/flexible_permissions (2.0.1)
  - Downloading drupal/group (3.3.4)
  - Downloading drupal/groupmedia (4.0.4)

@chris dart everything is already fixed here: https://git.drupalcode.org/project/groupmedia/-/commit/4fc733670eeffd6ae...

A new release 4.0.3 was tagged

I have tagged a new release. Thank you for your contribution

It has been solved here 🐛 groupmedia_vbo doesn't have a proper core version requirement for drupal 11 Active

You can use this token [group_content:group:title] or [group_relationship:group:title]

Hi, @rreedy, you are right it was an accident, I haven't finished to work on it :(

This code comes from group module:

      // This could be in its own decorator, but then it would live in a module
      // of its own purely for field_ui support. So let's keep it here.
      if ($this->moduleHandler->moduleExists('field_ui')) {
        $relationship_type = $this->entityTypeManager()->getStorage('group_relationship_type')->load($relationship_type_id);
        $operations += field_ui_entity_operation($relationship_type);
      }

field_ui_entity_operation comes from field_ui module. Are you sure it is available ?

I checked also with Group 2.0 and Group media 3.0 and it works as expected

I tried to reproduce, without success.

1) When we remove the group it calls the next code:

  public static function preDelete(EntityStorageInterface $storage, array $entities) {
    // Remove all relationships from these groups as well.
    foreach ($entities as $group) {
      assert($group instanceof GroupInterface);
      foreach ($group->getRelationships() as $relationship) {
        $relationship->delete();
      }
    }
  }

It will remove all group relationships. What happens on my side and I see that the data also removed from group_relationship_field_data.
Also I noticed that GroupContentAccessControlHandler, it looks like you are using Group 2.0 and groupmedia 3.0. Right ?

Thank you for your contribution

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

I have changed this behaviour. In this ticket 🐛 According Menu Title is showing when disabled and empty Active

Thank you for your contribution. I have added a fix

Actually, now I can see

Unfortunately, I can't reproduce this issue, I understand that is a quite old issue, plus we have a lot of changes since then, I will keep it for awhile just to be sure nobody else has it.

Thank you for your contribution.

I have added a fix in drupal-superfish library, it will be available in the next release.

Thank you for your contribution

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

I will explain how expanded options are working.
1) By default no "Show as expanded" option from a menu item is taking account. It means the menu will be displayed with ALL submenus!
2) In order to take into account any expanded option we need to use "Take "Expanded" option into effect.". In this case we take into account "Show as expanded" and show children if it is checked.
3) I have fixed saving of "Expand all menu links", if this option is checked an option "Show as expanded" of any menu item will be ignored

ok, I was wrong. Ignore my previous comment, I need more time to understand, how it should work.

I have done the investigation.

This option "Take "Expanded" option into effect." is supposed to work with many other options like:
- Enable multi-column sub-menus.
- Start from depth.
- Levels.
- Add cloned parent links to the top of sub-menus.

It is very special case, I am not sure that a lot of sites actually using it, but we will keep it just in case they do and I don't want to invest my time to a feature, which used very rarely.

I have fixed saving "Expand all menu links" and I will try to implement now solution for it.

I added all "out" effects

@xenophyle 📌 Use Once method in JS behavior Active
We have added once instruction into dev branch, could you check if it fixes your bug?

Thank you for contribution

Thank you for your contribution

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

I added a fix and I will introduce a new release soon

Thank you it was fixed. I will introduce a new release soon

Thank you for your contribution

how many rows do you in the tables you are trying to join ?

Entity id can be not only int

Thank you for your contribution

A new realease is available

Thank you for your contribution

ok, I see the issue, I will introduce a new release today

No, upgrade path is required, in this case we don't change the name of the plugins. The most likely it is a cache issue.
I switched from annotations to php attributes

Thank you for contribution

Thank you for contribution

Thank you for contribution

I will take care of it soon, it is one the next module in my list

Thank you for contribution

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

Did you provide your editor roles permissions to create this Group type ?
I was able to create an example:
1) Editors can create a subgroup, because we provide rights to manage Subgroup relationships
2) Editors can edit/delete group, because we provide rights for specific group

lobsterr → created an issue.

lobsterr → created an issue.

@brad you can still assign permissions to edit/delete group on subgroup type level

More info: https://www.drupal.org/node/3279234 →

It is a group module restriction.
It doesn't allow to provide entity access for group types.

https://git.drupalcode.org/project/group/-/blame/3.3.x/src/Plugin/Group/...

I am checking it, what we can do

I tried both options with admins and without. It works for me. I wonder what version of Drupal do you use ?

I have tested it and I couldn't not reproduce. Have you tried to debug it deeper or try on the fresh instance ?

BTW You have to use a link with hash code and not with email.

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

I have updated the code with latest changes from RC branch, plus renamed the classes to keep the same naming everywhere

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

lobsterr → created an issue.

Have you read my comment, it should be optional

So, I have rerolled the latest patch and also renamed denylist to ignore. As it was suggested in here ✨ Ignore specific paths Needs work

Please use PR from this point

lobsterr → created an issue.

So, Actually, to add user to a group we are using Group::addMember and inside we have such code:

    $storage = $this->relationshipStorage();
    $relationship = $storage->createForEntityInGroup($entity, $this, $plugin_id, $values);
    $storage->save($relationship);
    return $relationship;

So, as you see the $relationship doesn't not validate the entity and that is why it allows to add user and doesn't respect cardinality settings.
it is a bug on group module :(