OG Audience field selection handler resets from ‘og:default’ to ‘default:node’ on field settings save

A bit of context, and then I'll try to answer what I know :)

The reason we have the OG field, is that we could check for an existing of such a field instance, to determine if the node (or any other entity) is a group or group content.

Next, by having the OG field, we can create Selection handlers that would target only this field. That is, by knowing it's an OG reference field, then the selection handler already knows it should show only references to entities that are OG Groups.

> Investigate why og:default is being replaced by default:node.

Sounds like a bug.

> Decide whether OG should override the selection handler at runtime rather than during field creation.

It's better on field creation. We should follow as much as we can what Drupal core is doing, and avoid magic. The sin of the OG complex field is that it's trying to do that. Show both the "My groups" and the "Other groups". But if it was a "regular" ER (entity reference) field, we would achieve it by having some custom code that is as simple as creating an outgroup select list, grouped by "member" or "non-member".

> This also forces the user to select a bundle because:

Like a regular ER field, we should also let the user select a bundle. As one field could reference Group1 bundles, and another could reference Group2 bundles.

@amitaibu, thanks for the context. Just to clarify, when the field UI saves, it saves/exports the default:node selection handler, when it's created it's og:default. Although you mentioned it might be a bug, I believe it’s working as intended—that it should export and create the handler that way (currently creates the field as og:default).

The result would be that the audience field is created with a new handler that only allows selecting groups where the user is a member (with the OG admin exceptions), while default:node continues to work like the D7 og_non_member_post. This approach keeps the logic simple and ties it directly to the site builder’s explicit choice. What do you think?

joelpittet → credited ramil g → .

@amitaibu alternative I discussed with @ramil g, we can force the og:default in the field UI, and maybe strip out the option to select views or other ER entity reference selection handlers that are inherited? Then we create a separate OG specific handler for og_non_member_post.

For illustration purposes this is what I am talking about regarding this bug.

Before save:
→

After save:
→

D7
→

Yeah, it sounds like a bug.

We should only show OG-specific handlers that are valid for OG reference fields.

Thanks for the call today. I realized during the call og_non_member_post was custom in D7 on our site, so we can just implement that.

We will handle the bug (I think @ramil g did it already) in 📌 OG reference field widget update: MR #570 did not properly merge, leaving og_complex in place Active .

I will close this as works as designed.