Revoke ability to customize per group roles/permissions entirely

We're reviewing the child issues of #2349443: [META] Problems found during click testing localize-7 in Amsterdam here at the DA to triage these issues and knock out what we can before DCLAX.

Looking at this issue we're inclined to go ahead and set the ability to join a group as a global permission, making all groups on localize open to be joined - unless there's a very strong use case that some groups need to be locked down.

So we'll likely proceed that way unless we hear otherwise from the community.

Postponing as per Tim's comment, and also changing to a feature request rather than a bug report.

@hestenet: @opdavies: there are several groups that are moderated when joined. I think this depends on the cultural expectations of the team setup. I don't have an easy way to see which groups have it configured to require request membership, but if that is not possible anymore that may be an issue for several teams. They have no good way to get informed when new people join to swiftly post-moderate them...

Also I don't think it would be a feature request if its about loosing features?! You should have access to the db tables of ogur in Drupal 6 to query how many groups are affected.

We were taking the issue summary at its word that 'set global permissions and everyone will be able to join' was an acceptable option for a proposed resolution.

Proposed resolution

Either we set the global permissions and everyone will be able to join a group.
Or we set per-group permissions but we still need to port the default permissions

But it sounds like that's not actually going to work.

Right, we already incur regressions with lack of email subscription on the Drupal 7 site, so I think the issue summary was written to explore if more regressions are fine, but in this case I don't think we have workaround tools for group maintainers to handle the situation, so we need to not loose this feature.

Actually https://localize.drupal.org/og shows that 11 groups are set to not allow automatic membership to those who apply, they require admin approval. That is about 10% of the groups, so I think that is good proof that loosing this feature would be problematic.

I've looked at my localize dev site, and there is already the ability to a) use the default roles and permissions or b) override the roles and permissions.

There are permissions to subscribe to group (allow non-members to request membership to a group (approval required)), and subscribe to group (no approval required) (Allow non-members to join a group without an approval from group administrators.). These can be configured per group by the group administrators as needed.

With this being the case, do we just need to change the wording on the button depending on which permission is used?

I looked into this more. The thing is, there is a global role + permission matrix we can set up. And IMHO we want to ensure that the roles and their associated permissions are in line within groups. This would be the only exception. However, in Drupal 7 OG, what seems to be the case is a group either accepts the roles + permissions 100% from the central setup OR chooses to customize them. Then the group admins can add new roles and totally change permissions within the group (ie. change the meaning of the roles). Even if we don't give out changing roles (ie. we don't give out the "Add role" permission for group admins at admin/config/group/permission/3/edit), we'd still need to give them "Manage permissions" for them to be able to change what a non-member can do in the group. (Then they can give themselves permissions to change roles, haha). (BTW the Add roles permission seems to allow changing existing roles too).

I think we need to lock up what admins can customize in terms of permissions and roles, or the site will be a HUGE MESS. HUGE MESS. I'd personally rather not let teams limit joining groups vs. letting teams customize the names, set and meaning of all roles in their teams (which makes it impossible to support teams holistically for a site admin). However I did not find a way to revoke permission from group admins to be able to change what they can do to their group permissions setup. How do I do that?

I looked if we can remove the display of the permissions widget from the group via the content type, but does not seem to be possible? Should we remove the field entirely to not let group admins fiddle with this? Looks like based on #1748354: Option to "override default roles and permissions" unavailable and cannot be enabled this should be what we need to not let admins do crazy things within their groups. We can ease the restriction later if we want but if we are launching in an eased setup, limiting later will be hard :/

Where is og_roles_permissions field added to l10n_group in the migration? I could not find it within l10n_server. Is that in the og update functions?

@sebcorbin: that patch sets a new default for the field, but it does not add the field... Is the field added already in the patched code? Should we remove the field in an update function on our own?

Turning this issue around entirely and going for the regression instead of introducing dramatic customization that would complicate site management and support way too much...

I don't think that field is required at all? I removed it on staging and nothing wrong happened. People still retained their group level roles, I can manage those, etc. I think the only thing that field allows to do is to be able to customize permissions in groups, which IMHO would be a disaster to allow on this granularity. Its sad that we need to loose the feature to keep new members moderated by admins, but if we need to allow every permission to be customized if we are to need to do that, then that is too much :/

I think this field removal should happen in the update process in l10n_groups or it needs to be part of some manual checklist we do for launching a testing site / the updated site itself.

My preference would be to hide it by restricting access to it, rather than removing it completely - just to remove any risk of it causing problems later on.

Here's a patch where I've hidden it using hook_field_access().

Let me know your thoughts.

Oliver

@opdavies: that looks like a fine solution too, if it works. Don't have time to set up a local site to test, I can take a look at the staging site if/when its there :)

I've re-added the field to staging from dev (thanks, bundle_copy) and also applied the patch to localizedrupalorg, so you can now review it on staging.

Looks fine to me.