Referencing of User Entities via "Group Membership" using referencing entity

Thanks for reporting this problem!
I’m afraid I’m not really familiar with the Group module, though, so don’t really know what the problem could be, or what the solution would look like. I unfortunately also don’t have enough time to work on most feature requests myself.
For both these reasons, I fear we’ll have to wait until some developer becomes interested in implementing this and provides more insights, or even a patch.

PS: It seems you (like many others – it's really easy to misinterpret) are confused by the "Issue tags" field. As the guidelines state, they aren't meant for free text tags related to the issue, but only for specific categorization purposes, usually by module maintainers.
So, if you aren't sure your current usage is correct, please just leave the field empty.

I'm running into this myself. The issue is that group_content_field_data has an entity_id that's dual-purpose: For Group Content entities it refers to the node, but for Group Membership entities it refers to the member user.

This is also sort of an issue for Views. You can create a relationship to the User (content entity) from the Group Membership, but it's handled in GroupContentViewsData's getViewsData() where the entity type is figured out.

@drunken monkey do you have any advice on a direction I could take to give Search API hints on what the entity type is? I created a processor that's correctly indexing user fields by adding a nested group user property, but to actually display the user fields in a view it really looks like it needs to load the entity. I see a comment in the ReverseEntityReferences processor about a "hack-y work-around" for property extraction in Views fields, but I'm not quite sure what that code is doing.

Edit: The solution I have so far also doesn't do reverse entity references, so the Search API index still has to start with the Group Content entity. I'm not sure what to alter to get a reverse entity reference to see that it's a User instead of a Node if the group content plugin is Group Membership.

So now I've got another processor that is similar to ReverseEntityReferences except gives back the group memberships for the user, but I'm running into #3050475 where the nested properties aren't being set to multi-valued which makes the indexing process die :-(

I've got a sandbox project but it depends on the patch in #3153385 if you're using Solr.

Please take a look and let me know if it helps!

Thanks for the link to the sandbox! Yes, this looks like a good solution. However, not sure it would be useful for enough people to warrant adding this to the Search API module itself.
Thanks also for the additional insight into the problem. If group_content_field_data really does refer to two different entity types, then this seems like just a bad design decision of the Group module, which we’d have a hard time supporting in a generic way. A specific work-around for just this field really seems the only way of doing this.

So, maybe just make your sandbox a proper module for now, if it’s working well for you, and we’ll leave this issue open to point users to it, and if it gets enough users (a few dozen or so) we’ll talk again about including it in the Search API, if appropriate.

Thanks again, in any case!

Hi,

I really also need this feature. If a site depends heavily on the group module,
this possibility to make views related to group membership is cruicial.
Could be great if in the search api included.

I want to include group members of a particular group type in search API indexing and list those members in a view, what is the solution for it? Can I use https://www.drupal.org/sandbox/karlshea/3153389 for it?