🇧🇪Belgium @lobsterr

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 :(

The view was update, Please reload config from gvinvite config module. We don't pass any user to the view, we take the current user from the context. Previously, we could expose data by passing user id of another user.

I will check it

Guys, please provide an interdiff every time you change something, it is impossible to follow your changes. I will reroll it, but since this moment we will switch to MR

@brooke_heaton, it looks like you are using not 3.0.0-rc3,

As you can see here in this ticket I fixed the issue: fix

And the right code is there, in your error you have a call of id(), but it was removed : https://git.drupalcode.org/project/ginvite/-/blob/3.0.x/ginvite.module?ref_type=heads#L209

I believe you are still on rc2. Could you checked it

No, need to open, I will check

Thank you for your contribution. I will tag a new release

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

In this case the user will end up on Login page and then he will be redirected back to a group list. Your patch won't do the job.
I need to check what they are doing there

You can check it. I have created MR, also check my previous comment for the known issues.

Don

lobsterr → changed the visibility of the branch 3327680-outsiders-combination-of to active.

lobsterr → changed the visibility of the branch 3327680-outsiders-combination-of to hidden.

a new release was tagged with the fix

I have added a lot of new tests. We cover all the latest features

it has been fixed already Here

This was done intentionally, because in some cases we need not saved group_content (group_relationship) object.
What we can add a parameter to the method, which will allow also save the group_content (group_relationship) entity

Hi, it has been fixed in 🐛 Creating membership (accepting invite) does not contain selected role. Fixed . I just didn't have time to finish a new release.

I tried to check using many scenarios and can't reproduce it. I tried with new groups, with existing ones.
I added media item to a few nodes and still no error :(

Maybe you have more info about your config

Tried to reproduce it, but it works as expected, I think you could have accidentally used group relation changed field and since we update media, it will not be updated. Feel free to reopen it, if you have more details

Thank you, it has been fixed and will be added in the future release

@daneduijnkerke, We have this dilemma for awhile and I explained my point of view on whole this situation in comment #17. I have tried to find a better solution and believe me there were a lot of ideas, but unfortunately we have restriction on the group module level and I can't do anything about. if you have a solution feel free to reopen ticket and submit your solution. For now it will work like this for Group 2.0 and Group 3.0 versions, you need an outsider role and you need "view group invitations" for this role

I am bit confused here, to accept an invitation, you have to be a registered user and not a member of the current group. It means the user has to be an outsider! I don't see any problem here. Yes, we need an outsider role, yes, we need to provide this role "view group invitations" permission.

Thank you for your contribution

Thank you for your git commit -m 'Issue #3467342 by claudiu.cristea: Drupal 11 compaibility'contribution

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

Yes, I meant "The group creator automatically becomes a member" :(

I believe, it was a confusion, because you have several group types and probably you checked for the parent, but not for the child.
Anyway, let me know if you have any problems, we will try to find a solution!

This module doesn't not affect this functionality at all. It purely depends on this property "Group creator must complete their membership" of group module. Check Group entity postSave method.

It doesn't matter if you use different group types or the same. For a child group type this property must be checked.
I have checked again with different group types. It works as expected.

I don't know why it doesn't work on your side. Please check your code for the hooks. I use in my case the clean instance of the Drupal.

Hi, I am sorry for the delay, I have completely forgotten to check it.
So, I have checked and it works as expected on my side.
I assume you didn't check the property "The group creator automatically becomes a member" for your subgroup type.

Please check /admin/group/types/manage/[YOU_SUBGROUP_TYPE]

Update screenshots and information about multiple invitations

Add information about new options and features and update the screenshots

ok, it looks like, we don't have much progress here and I decided to implement the next solution:

1) Since we can't use "view own" permission, because the owner in our case is not current user, but the creator of group relationship and also because of the restriction in QueryAlter classes. I decided to use "view any" permission.
2) I updated the view and now we will take user id not from URL, but from the current account
3) I restricted access to group relationship, now only owner or a user with "invite users to group" permission can view group permission

It looks like we cover all cases:

1) We don't need additional field for owner
2) We still can use creator field to display invitations created by the specific user
3) We just need to provide outsiders "view group invitations"

I have tested it, it works as expected.

I have tested it. Looks ok for me!

You need to check: admin/config/regional/config-translation
For this config translation modules must be enabled.
You will not find cas settings there, if you apply changes from MR, cas settings will be available for translation

It should do it, let me check this

Thank you for your contribution

I used your code, but I had to rewrite the existing code quite drastically.
1) I move the code for sending email to a separate function. So, we can reuse it
2) We still first check email (invitee_mail field) and then invitee (entity_id field), because normally we add invitation by email.
3) If email is empty and invitee is there then we check settings and send email to the user
4) if email is not empty we again try to load a user by email, as it was before and then we check settings and send email to the user

So, I have improved a bit the code and also covered your case. Also I had to move code to presave hook because we have issue with infinite loop 🐛 Entity save() in hook_ENTITY_TYPE_insert() Fixed

Please check MR and I will include the fix to the next release

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

thank you for your contribution

Thanks for proposal. I have updated the texts for all versions

Thank you for contribution

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

Thank you for your contribution

Yes, I noticed it too, I have already fixed in ginvite 2.0 and didn't transfer changes yet.

LOBsTerr → created an issue.

One of the way is alter local actions "ginvite.invitation.bulk" and just remove it, another way is to alter the route "ginvite.invitation.bulk" and close an access to it

I have a version ggroup_role_mapper for Group 3, I need to publish it

Hi Brad, could you please check MR?
I also noticed that the wizard for subgroups actually is not used, because we were missing option for GroupRelationship plugin.
We need to reintroduce the fix in other versions too

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

A new release was tagged

Ah, sorry, completely missed, I will handle it today. I promis :)

Actually, it doesn't solve the issue, we still have permission sections and permissions translated incorrectly. Rolling it back.
It happens, because section arguments for group enabler plugins are set once and then cached and the label for entity types is set based on the current language.

@kopeboy, Could you please check the MR? I have updated the view completely

I will check it today and introduce a new release

LOBsTerr → created an issue.

Hi @msnassar,
1) After the merge _group_permissions_enabled requirement was removed, I brought it back.
2) I added entity validation as requested.

Please check 1.0.x dev branch all changes already pushed there, if everything is fine I will tag a new release.

The next step is version 2.0

Thank you for your contribution

but you have deleted it already in this commit https://git.drupalcode.org/issue/group_permissions-3360880/-/commit/08f6...

I think we good to go to merge it.

Thank you for your help with this ticket