In recent sprints I’ve seen the collaborative nature of open source in action, specifically in the overlap between the Drupal community and the LocalGov Drupal community. A case in point is the upgrade to Group 3.x.
Using the contributed Group module gives us the power to isolate content to a given microsite, but the 1.x version we’ve been using is approaching end of life, so it is imperative that we upgrade to Group 3.x before we release a beta version of LocaGov Microsites for councils to start building sites. To do this we also needed to to consider the (not insubstantial) number of contributed modules that extend Group with the functionality we need, many of which are/were not yet ready for Group 3.x.
Luckily we are not the only people who use Group module and who need the contributed modules to work with Group 3.x, so we have the opportunity to work with other developers in the community for mutual benefit. Nikolay Lobachev (LOBsTerr) is a developer working with the European Commission and makes heavy use of the Group module and contrib ecosystem. He maintains many of the modules we rely on, including Group Permissions, Group Invite. Another key contributor in the mix is Kristiaan , the developer of Group module itself. Kristiaan has just returned from a few months’ paternity leave and has been very helpful in issue queues and the Drupal Slack channels.
Having good communication with these key developers has amplified our efforts considerably, allowing us to upgrade to Group 3.x within about half the time it might have taken otherwise and to fix bugs and see new releases happen swiftly.
This is open source in action and I love it!
I’ll summarise the work on the various areas of the group ecosystem below, for those that are interested in the specifics.
Group 3.x
The majority of Sprint 13 was focused on the upgrade to Group 3.x, which meant upgrading a number of contributed modules, our own custom code and configuration to match. Note that we were never planning to provide an upgrade path for existing sites, so we just need to get this to work on a fresh installation.
Group module
https://www.drupal.org/project/group
This is the module that underpins the permissions architecture that keeps content, users and configuration on one microsite (group) or another.
The 3.x branch is where current and future development is happening and is currently in beta. It supports assigning configuration to groups, not just content. This is important for webforms, taxonomy vocabularies and other configuration entities. It also has a nicer user interface for some parts of the configuration.
There is also a Group 2.x branch for people who are already using group 1.x and need an upgrade path to 3.x. See https://www.drupal.org/project/group/releases/3.0.0-beta1 for details of the differences. 3.x and 2.x. Note that we are not planning to provide an upgrade path (which would be a significant amount of work) as we expect to release a beta version of microsites with Group 3.x from the start. Releasing with Group 3.x will save work for developers at councils and the future maintainers of the distribution and its modules.
Domain Group
https://www.drupal.org/project/domain_group
As the name might suggest, Domain Group ties domain module to group module, allowing us to configure a default domain for each group (for example fostering.scarfolk.gov.uk). It provides the access control to assign a content entity to a specific group. Anything that can go into a group can also go into a domain. It extends the entity access query to check the domain and enforce the group. So if you are trying to access a content entity on the wrong domain, you will not be able to see it.
To start with, @ekes forked this module here: https://www.drupal.org/sandbox/ekes/3278349. We have configured our composer.json to make use of specific repositories but we are aiming to contribute this to a branch on the Drupal.org project via this issue https://www.drupal.org/project/domain_group/issues/3319678
Group Invite
https://www.drupal.org/project/ginvite
The Group Invite module extends the Group module and allows group admins to invite people into their group. The invited person can choose whether to accept or decline the invitation. Upon acceptance, the user will receive group membership. This is super handy for content designers in councils who might want to invite content designers from inside or outside the council to collaborate on a given microsite.
The work on the upgrade to Group 3.x was largely done, by our favourite maintainer, Nikolay Lobachev (LOBsTerr)! Thank you! We’ve started testing and only found one bug so far.
Group Content Menu
https://www.drupal.org/project/group_content_menu
To support setting up menus and menu items for each microsite group we need Group Content Menu.
Ekes created an updated version on this branch https://git.drupalcode.org/issue/group_content_menu-3315163/-/tree/3.x from this issue: https://www.drupal.org/node/3315163, collaborating with maintainers to set up to required branches. So far we are using this issue branch but hope to get a branch and merge request and a beta release soon.
Group term
https://www.drupal.org/project/group_term
Keeping terms just for the group / microsite they are in requires Group Term module. Again we are using an issue fork for the time being: https://git.drupalcode.org/sandbox/ekes-3319987.git
Group permissions
https://www.drupal.org/project/group_permissions
The main reason we need this module is to allow us to override permissions for a given group / microsite such that we can permit or deny access to create specific content types. Some sites will want just news and pages, other directories and blogs.
The upgrade to this module looked complicated, but LOBsteRR was already thinking about it on this issue so we commented to express our shared need and interest in helping to test. The conversation evolved and the LOBsteRR posted and alpha release on 9th November, lovely timing! We’ve now got an alpha3 release following some testing. Open source working well again!
Our custom code:
Most of our custom code that depends on Group and related APIs is altering forms / labels / UI / behaviours like adding roles. @ekes initially thought that upgrading might not be a difficult task, just tedious to go through, refactor and test. Some of our automated testing might also need updating which always takes longer than expected, but the test coverage should also help to identify things that are broken.
At the end of sprint 13, we have all of the above upgraded and the installation works. There are a few critical bugs, mostly in our custom code we think, but we are hoping to resolve these within days.
Sprint 14
This all puts us in a great position to test further and bring in some of the high value features that we have been delaying for the Group 3.x upgrade: namely contact forms and grouped media.
Meanwhile, plans are afoot to start LGD INC. the new non-profit company we need to take this collaboration to the next level. Watch this space for more on that!
