Subgroup role mapper

We need this functionality for the 3.x branch, I imagine it will be complicated to do. If we could sponsor work on the issue to help make it happen, we'd definitely look at that.

@brad.bulger - Yes, it would be a quite complex, taking into account that Group 3.0 have been reworked. Contact me on the slack we can discuss it.

I have a question to developers who are using this patch?

Outsider and Anonymous roles were dropped #42 📌 Subgroup role mapper Fixed and I don't see any complains about it. So, I assume nobody uses anonymous and outsider roles for mapping ?
If it is a true and we don't need it, then I will clean up the code.

if we still need it, we can make it optional to avoid performance issue on some websites.

Please, share your opinion.

I am not sure how much this applies to the Group 3+ way of doing things. Each change in the combination of factors results in a distinct single group role. So maybe it is simpler, in that you can map any source group role to any target group role. Or maybe it has to echo the same scopes as Drupal site roles: one mapping for source group role + member of target group, one for source group role + non-member of target group.

After checking the status of the current code, I found the next issues, which I want to improve to reach a stable version

1) Role mapped only to the direct ancestors. I think we want to apply permission to all subgroups. Should we add it as an option ?
2) We load group entities, but we don't need them, we just need group ids.
3) We have removed outsiders / anonymous mapping, I believe, it is still useful feature I propose to make it optional
4) Should move this patch to a contrib module or should I add already to ggroup module? For me it would easier to handle the bugs and feature requests
5) We do a lot of useless operations. I see some ways to optimize the code

Please share your opinions

#1 and #3 both seem like they'd add complexity to the current patch, which is already complex enough, so for me I'd prefer not to do this - or at least, to do it in a follow-up once there's a working version in a module somewhere.

If it still works as it did before, where it is a module that has to be enabled separately in addition to ggroup, then whatever is easier to maintain would be the way to go, I think - standalone or component of ggroup.

Being able to optionally have mapping apply to descendants would be nice.

From this moment ggroup role mapper is part of ggroup.
Please share your thoughts and ideas here 📌 Ggroup role mapper module new features and suggestions Active
All comments here will be ignored, create a separate tickets and choose "Ggroup role mapper".

Automatically closed - issue fixed for 2 weeks with no activity.