l10n_groups ships no translation group type, language field or roles, so nothing controls where groups are migrated

Problem

The Drupal 7 module defined the group content type, its group field and the language storage itself, and its OG permissions gave the site its roles. On 3.0.x the translation group type, its field_translation_language field, the displays and the group roles only exist in the site configuration of localize.drupal.org. The module code, the group migrations of l10n_migrate and the tests all assume them: the migration targets bundle translation, the language field and the role ids, the tests had to build the type, field and roles by hand, and a fresh install of the module has nothing to create a group with. The module's optional membership view also carried a formatter setting core has no schema for, hidden so far because the view was never installed in tests.

Proposed resolution

l10n_groups ships as install configuration:

• The translation group type: no creation wizard, the creator becomes a member with the community manager role, which is what "group manager full permissions" gave on Drupal 7.
• The field_translation_language field storage and field (required reference to a configurable language), with minimal form and view displays. The site keeps its own extra fields (description, welcome message, attachments) in its configuration.
• The Drupal 7 roles under their Drupal 7 names, with the role ids the migration and the site configuration already use. Drupal 7 "administer group" bypassed every group permission, so the community manager is a full group administrator here:

• The Group module creates the membership relationship type from the group type, so it is not shipped.
• l10n_migrate depends on l10n_groups, its three group migrations need the type and the roles.
• The module lists its field and language dependencies, and the invalid time_diff.description setting goes from the memberships view.

The site configuration adds its own permissions (group content) and roles (site administrators as group administrators) on top, as before, and keeps precedence on configuration import.

Remaining tasks

The membership migration maps the Drupal 7 role ids 1, 2, 10, 12 and 14 only. Memberships carrying the Drupal 7 "administrator member" role (id 3) would be skipped, if any exist on the live site. To check against the live database.

Tests

Drupal 7 already covers this: L10nGroupsTestCase creates groups through the content type the module provides. L10nGroupsDecorationTest now runs against the shipped configuration instead of building the type, field and roles in its setup, and takes the browse permission away from the non-member roles so it still has a user without any translation access.

LLM disclosure

LLM was used to find, diagnose explain and fix this issue. With human review.