Group 2.0.x roadmap and general plans for the future

Just realized we can't sync Anonymous, Outsider and Member. But we can still write a more robust synchronizer for the other roles.

Re #6 I stopped supporting the D7 version when I released the full D8 version because:

• It has zero test coverage
• The architecture was massively different making backports of fixes near impossible
• D7 is EOL (and D8 will soon be too)
• I simply don't have the time :)

So by marking the D7 version as unsupported, it vanished from the main page. Usage has since been steadily declining below 1k reported installs (down to 800 now) whereas the D8 version has 10k reported installs.

At this point, I would go over all D7 issues (about 160 of them) and close them with a Closed (outdated) message along the lines of:
"We thank everyone for their collaboration on this issue, but as the D7 version is no longer supported, we will now close all D7 issues to keep the issue queue a bit tidier. This information won't go anywhere, it just won't show up on the list of open issues anymore."

Good call :)

@Soul88 I noticed, thanks a lot for that! The timeline for 2.0.x is "not anytime soon". It's something I want to kickstart over the summer and then slowly work on in parallel to 8x.-1.x until it's ready. Maybe Q4 2021, but your guess is as good as mine.

The Group module is really an access module at its core. Otherwise it would just become a glorified taxonomy as you mention :)

We already offer a lot of flexibility through the API, one example being the membership loader. Someone showed me a use case where they swapped that out with a service that talks to LDAP directly to retrieve memberships from an external service rather than Drupal entities.

By the way, GroupRelation is vastly different from Relation, they couldn't be more different.

Most is done, some got moved. Looking into a few final candidates for a 2.0.0 version.

Added the Group 2.0.0 target tag for adding small QOL issues that won't take longer than an hour to commit.

Re #18 Probably 2.1.0, it shouldn't break anything if added later on and that way 2.0.0 can focus on all the new APIs. I don't want to delay it forever, but with the new code in 2.0.x it's definitely possible.

Use 8.x-1.4, 2.0.0 will come with an upgrade path. The public API things that will drastically change are the plugins, group roles and permission calculators, internally the access queries will be significantly optimized.

So if you have any custom plugins, you will need to make a few alterations, but they should be easy to pull off. If you have any code that uses group roles, you might need to make a few very small changes and finally if you have custom calculators, they can be simplified after the upgrade.

Finally, I've started with renaming things that do not require any database maintenance. So plugins have been renamed, but GroupContent(Type) entities have not. I am keeping the CRs up to date here: https://www.drupal.org/list-changes/group

@mxr576 Already part of #3204083: Rework group roles into a scoped system and adjust permission calculation which I am in the process of fixing the last few test fails for.

I should have a solid 2.0.0 beta out during the summer. Just faced a minor setback with a developer leaving, but the major work has already been done. Updating the plugins is definitely something that needs to be documented, but it should be pretty straightforward. The change records can already help a little, but I can try to do a short video on it.

The entity type as a group thing was the whole reason I created Group, because I did not like that part about OG at all. So I don't see me going back to that architecture any time soon.

The second I'd have to research more as we need a fieldable entity for the relation. I'm slowly making Group slimmer by putting more into separate modules. 2.0.x will release with a new dependency on a module I am yet to write that takes care of the permission gathering and calculating.

So for a later (perhaps major) version, we could look into writing a more agnostic module that takes care of the fieldable relation. I am afraid, though, that Group's requirements for said relation are too specific to be able to fit in a generic module, but who knows what might come up when we actually investigate this further.

Having said all of the above, currently the remaining items for 2.0.x are cleaning up the roles rework and separating out the module I just talked about, then it's done.

I'm in the same boat, lots of ideas, not as much time to complete them in. But thanks for your kind words!

You already can override permissions on a per group basis using custom permission calculators. This will not change in 2.0.0 but should become way more performant due to the new scopes and query alters.

Oh, that's a clear no for the time being

https://www.drupal.org/project/group/releases/2.0.0-alpha1