🇧🇪Belgium @LOBsTerr

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

Thank you all for your contribution

Thank for info, I appreciate it

Yes, I wonder, if we could have some info about user in EVENT_PRE_LOGIN. Is it too early and we don't have any info about user? And another probably would be too late to force 2 factor authentication ? Right?

I will introduce today a new release with this fix

Thank you for your contribution

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

Thanks for info, I have created a MR

Reroll the patch for 10.2

it looks like it was fixed. At least I see a fix in 2.10. I am closing the issue

Can you please provide steps to reproduce?
I have created a view which shows subgroups for the given group (ID from url) and it works.
Thanks

Hoi @batigolix :)

Thank you for a quick push :)

Let me check it first.

I will do it. Since we already have the 3 version, I will use to bring a version for Group 2, it will be faster like this

Thank you for your contribution

I have finished, it should work now. I need to get an access to publish it as a release

@electrokate leave it for me I will take it from this point

I can work on it when I have a bit more time

LOBsTerr → created an issue.

I have double checked the issue, I can find any issues with a cache here. So, I am not sure we need any cache tags handling here.
I will explain, since we use

\Drupal::service('ginvite.invitation_loader')->loadByProperties($properties);

This code based on group content. So, every time we delete invitation, it will correctly reset tags for group content entity and for group_content_list.

Feel free to provide more information, if you still think we should do something here

Thank you for your contribution

1) Now user can decide to keep invitations or remove them, once user joined the group
2) Now we remove invitation when user is removed from the group
3) Added Kernel tests

LOBsTerr → created an issue.

Thank you for your contribution, most of these issues have been fixed already in other tickets

1) I have added option on the plugin level
2) Also updated the tests
3) Clean up the code

@dww try the solution in the previous comment, we already have entity reference field to users, you just need to expose this field on the form and hide the email field. The result will be the same basically

We actually have the feature, but we remove only pending group membership request, let's delete any if the feature enabled.

LOBsTerr → created an issue.

So, I did a big refactoring you can review changes here https://git.drupalcode.org/project/group_permissions/-/merge_requests/27

1) I remove group_permission from all entity link template, because we need only group
2) I added a standard link template like (view, edit, add). No UI should be more clear to manage
3) I have added necessary controller handlers for it too
4) I updated the routes accordingly. From this moment we will not see any links or will not get any exceptions

@msnassar Could you please check it?

I will tag a release then

yes, you are right I will tag it correctly

Thank you for such a useful feature, it is very helpful and should be included in this module.
I have tested, for me it works perfectly

We can create a custom view showing group content (group membership requests) with "administer membership requests" access

Are you sure your user doesn't have any group membership requests ? Probably, this is a case

it doesn't work like this, we can't just change the version we need some development

Fixed, I will tag a new release

I made a tag based on 1.0.x branch :(

I have just tagged a new release

Ops, my bad, I fixed it some time ago, yes in 3.2.0 it is wrong, I will fix it today

Maybe you should use a version for group 3.0 ? There are different version of grequest module for different versions of group module.
It is written in the module description

https://git.drupalcode.org/project/grequest/-/blame/3.0.x/composer.json#L20

I decided to keep routes as they are right now, because some developers could alter they views and will miss these changes.
I just add additional check that plugin exist in our custom access check.

My fault, I will tag a new version

I have fixed a JS error from #5. A new release was tagged https://github.com/LOBsTerr/drupal-superfish/releases/tag/2.3.1

I checked he installation on the fresh instance and also tried to update. I don't have any issues.

I will check it

Patch can't be applied anymore

I see this changes applied already. So, we can closed it

I have added it here - it will be introduced in a new release

https://github.com/LOBsTerr/drupal-superfish/commit/03e8759c57ea667bd7bf6c463112416478a403b3

Thank you for your contribution

Thank you for your contribution

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

I will tag a new version this week.

LOBsTerr → created an issue.

ok, I will handle this case in a separate ticket

Can also try the latest dev version ?

I can't reproduce it, are you sure you don't have any custom code, which inserts a user ?

I think, it is ok to allow users to view a group, if we have invitation to it.

Should we think of a generic solution, we have other modules like group_term and others.

As a workaround, it is possible to hide "Invitee email" field and make "Invitee" field visible. Using autocomplete feature it is possible to create group content (invitation) for the given user.