Many groups to many users

Hi MegaKeegMan thanks for reaching out!

You should be able to do this with access policy, this sounds like a combination of these two tutorials:

• Private content →
• Group content by department →

If you haven't tried them yet I recommend going through them.

For your use case it sounds like two roles (Content manager and Contributor) and two access policies (Public and Private)

Public content
Viewable to everyone but only editable to users in a group.
Follow the "Group content by department" tutorial above. Only change you will need to make is to grant all roles "view" access.

Private content:
Editable by original author, only viewable to users in a group OR users are are explicitly granted access.

Follow the "Private content" tutorial

Then add additional access rules with the OR validation operator. You'll also need to adjust the operation constraints. Note, in order to add these access rules you'll need to add fields to the node and user.

• Compare Group with user
• Allowed users field has reference to current user

Definitely worth giving a try. Let me know if you run into any issues.

Oh cool. I started following along the group content by department guide, and I got the sense that if one user was given the Content manager role, then they would essentially be a manager of every group for which they had the taxonomy term assigned to them, where I actually want them to be managers of some, and only members of others. Is that not the case, and is it actually just that every user should have both roles?

Making progress in understanding how to achieve my goals. Maybe this is also documented somewhere, but I am configuring the access rules for my policy:

I am concerned that if I have the validation operator set to "Any" then it could grab the first access rule that the user meets the criteria for. In my example above, would a user that meets all of the rules above always be granted access by the most permissive rules provided here?

Okay, but the main issue I think I have:
groups permissions are taxonomy based. This does not necessarily have to be an issue. But A user should be able to add or remove a group (term) from another user's term reference field on the condition that they themselves are a manager of that group.

Ideally (for me) group access would be managed centrally, and not from a user reference field. I am not sure if it will be possible to restrict what values can be added or removed from this field based on the current user's access to that group, which could be granted from a variety of sources:

• edit access to that group (user reference field on node)
• edit access to that group (term reference on their account)

To clarify, in my current implementation, I have basically followed the private tutorial, and I have one access policy (though I think I will add another later). Let's just assume the one for now though.

I have four relevant fields on my node:

• Users with edit access (user reference)
• Users with view access (user reference)
• Groups with edit access (term reference)
• Groups with view access (term reference)

And I have added 4 access rules:

• Users with edit access field has reference to current user
• Users with view access field has reference to current user
• Compare Groups with edit access with user
• Compare Groups with view access with user

And user accounts have 2 related fields:

• Groups editable
• Groups viewable

Let's say I have Group 1 in my Groups editable field. In that case, I should be able to add or remove Group 1 from anyone else's Group's editable or Group's viewable fields. If I did not have Group 1 in my Groups editable field, I should not be able to do this. Though if Group 2 was in my Groups editable field, I should be able to add or remove Group 2 from someone else's account fields. Is it possible to do this in a secure way?

If yes, then the next question would be: are there any recommendations about how I could administer group management and membership all in one place, without having to edit the term reference fields on the user? (It is okay for these fields to be used still, but I just want an interface where I can administer managers and members, such that the values in these user fields are not manipulated manually.

Ah ok I think I understand now. I hadn’t considered this use case so thanks for that!

A few suggestions:

• You only need to have one “Group” field on the node. The “Group editable” and “Group viewable” on the user should be enough because they're already controlling operations.
• Have you tried breaking up the policy into two (Group and User access policies) and putting them in a Selection set? This would allow you to toggle user/group access for each node. It's not strictly necessary but it might be nice user experience.

Ideally (for me) group access would be managed centrally, and not from a user reference field.

There’s currently nothing built into Access policy to do this. However, you could do the following:

• Create a new view that shows the Group taxonomy terms.
• When a user clicks a term it will show another view that lists the members of that group.
• Install the Views bulk operations → module and write a few custom action plugins → (e.g Add member, Remove member).

We did something similar to this on one of our projects and it worked well for us.

Thanks for all of the feedback. It is very helpful. I will play with your suggestions a bit more and put some consideration into your bulk operations idea.

Would someone performing these bulk operations on group members require the permission to change the values in the user field?

As far as whether I should reduce the two group reference fields (on the node) to one, this has highlighted some questions I need to discuss with our client, will follow up once I have clarification.

So looks like it will be a tad simpler for now. For the short term, I will just be using groups to manage read access on content, and not for any write access. All write access will be managed by the user reference fields on the node. This may change later in development. With that being said, I am very much appreciating the flexibility that this module provides.

About splitting up the access policies, I am not sure that I would do it the way you suggest exactly. Rather I was considering having 2 access policies:

• Public - All users can view, and therefore will not include fields pertaining to view access (Groups or users with view access). Will still have a field for users with edit access.
• Private - Only referenced groups and users referenced in the users with view access field can view. And of course will have the users with edit access field too.

Though I should still experiment with the selection sets of multiple access policies, as I would like to get a better idea of how that works and what it is like to implement.

I realize I am saying a lot, but if you respond to anything, I think I am most curious about the answer to my question in comment 8:

Would someone performing these bulk operations on group members require the permission to change the values in the user field?

Would someone performing these bulk operations on group members require the permission to change the values in the user field?

Apologies for the late reply, I'm currently on holiday.

In your custom action you would be using the entity_autocomplete field widget so it's up to you how you want to handle the permissioning of that action. As far as which terms are available to that user, that should automatically be filtered for you as long as you've set up access policies for the taxonomy terms.

I'm not sure yet that an access policy will be necessary for managing who can see which groups. Will there not be a way to just filter the view to only show terms that are in the current user's "group's managed" field (this is what I decided to call it).

More specifically, my thoughts are that I want to restrict who can manage a group, but not who can view it (at least in the context of the bulk operations). To clarify, I may want a group to be publicly viewable by everyone, but I only want people who have the group in their "group's managed" field to be able to see it in their group management view.

Perhaps I am mistaken, but this does not feel like something that should be handled by an access policy, but rather by a filter on the group management view. Though it is quite possible that there is yet again some nuance in configuring an access policy that I am not considering.

Thinking about how to manage who are group managers and members per group. I think the view bulk operation method you mentioned is definitely worth considering. However, I am considering that simpler approach might be to use https://www.drupal.org/project/cer → to sync the entity references between user and group. Will update once I have attempted this implementation. I am wondering how nicely this will work in a many to many situation.

I've opened a discussion thread around groups, I've received a few related requests so I thought it might be useful to consolidate ideas into something cohesive.

https://www.drupal.org/project/access_policy/issues/3419012 🌱 Discussion: Access policy group enhancements Active